When do domain concepts become application constructs?

Question

I recently posted a question regarding recovering a DDD architecture that became an anemic domain model into a multitier architecture and this question is a follow-on of sorts.

My question is when do domain concepts become application constructs.

My application is a local client C# 4/WPF with the following architecture:

Presentation Layer

• Views
• ViewModels

Business Layer

• ???

Domain Layer

• Classes that take the POCOs with primitive types and create domain concepts (e.g. image, layer, etc)
• Sanity checks values (e.g. image width > 0)
• Interfaces for DTOs
• Interface for a repository that abstracts the filesystem

Data Access Layer

• Classes that parse the proprietary binary files into POCOs with primitive types by explicit knowledge of the file format
• Implementation of domain DTOs
• Implementation of domain repository class

Local Filesystem

• Proprietary binary files

When does the MyImageType domain class with Int32 width, height, and Int32[] pixels become a System.Windows.Media.ImageDrawing? If I put it in the domain layer, it seems like implemenation details are being leaked (what if I didn't want to use WPF?). If I put it in the presentation layer, it seems like it's doing too much. If I create a business layer, it seems like it would be doing too little since there are few "rules" given the CRUD nature of the application.

I think all of my reading has lead to analysis paralysis, so I thought fresh eyes might lend some perspective.

Update 1:

To clarify that the application is not a strictly CRUD, the domain layer would also contain signal processing functions and image transform settings. The signal processing functions must be applied on the raw pixel values directly from the DAL, while the image transform settings are stored with the domain objects to be applied by WPF as part of the presentation.