[Lcms-user] Color management architecture

[<ma...@li...>]

> Hi Marti,
> I am trying to determine the most appropriate architecture for performing
> color management in my application. Currently it does not deal with ICM
> profiles, but I am adding support for profiles embedded in JPEG, PNG, PSD,
> and TIFF images, and will be supporting add-in profiles for scanners and
> other digital input devices.
>
> Ideally I would like to keep all the input image bits in their own color
> space and  perform the Input Color Space (ICS) -> PCS -> Output Color Space
> (OCS) transformation when generating the bits for the display or printer
> device. The problem with this approach is when image manipulations are to be
> performed. Say, for example, that an adjustment to the white point of the
> input image is to be performed. The method would be to perform the
> manipulations on the input bits, then do the ICS -> PCS -> OCS
> transformation again. The problem with this approach is the time to perform
> the final color space conversions. Many of the operations in my application
> can be performed interactively with very good performance. Using a slider
> control to adjust RGB balance, for example, adjusts the visible image almost
> in real-time. Adding a color space conversion to this operation will
> significantly affect the performance .
>
> Another approach might be to immediately perform the ICS -> PCS -> OCS
> transformation, where OCS is the display device color space, then perform
> all subsequent operations in that color space. This restores the performance
> lost with the first approach, but implies a conversion from display device
> space to printer space for printing, and a conversion back to input device
> color space for saving any image edits. It seems to me that the accuracy
> lost with these conversions might be significant in some cases, particularly
> if the conversions are done using perceptual intent.
>
> Can you offer some opinions on this? Don't feel bad about informing me that
> I have it completely wrong. I may have reached conclusions because of
> ignorance about some aspects of color management and color space
> conversions.

This is really a hard question. I can tell how I'm handing this stuff
in VDA (a imaging library) but I'm sure there are other solutions
as good if not better.

I am forwarding this to ML because I'm pretty confident
there is a lot of capable people arround here :-). Perhaps
sombody has a better idea on how to do this.

I do use an hybrid approach, based on size of images. If image is
"small" (up to 10Mb) then I convert to destination space and
perform manipulation in this space. If image is "big", then I do
all processing in source space, and then apply monitor profile
just on the portion being displayed. That is, I keep one bitmap
of screen (window) size, while the image is stored in a tile caché.
When I need to display a portion, I do retrive the necessay
tiles, fill the screen bitmap, apply color managent and do a Blt on
screen. This approach is also very usefull to operate in colorspaces
that cannot directly be displayed, like CMYK or Lab. Lab is very
good to do image processing, I do almost all processing in Lab,
filtered zoom, for example, works impressive.

I suspect this is the main reason many programs does use the
concept of "Working space". Otherwise, working space is
not needed in profile to profile color management.

A copuple of thoughts: Color conversion is ALWAYS lossy.
If you apply a profile chain you will loose information. Then the
method of operating in source space and convert only to display
is better, since it doesn't change colorspace, but this can be less
than optimal on processing, since some operations doesn't work
well if space is not perceptually uniform.
Another solution would be to convert to monitor space, operate
in monitor space and then change the embedded profile to
monitor one. This is fast, does minimize information loss and
don't mess up things. In the other hand, it could destroy dark
tones out of monitor gamut.

Best regards,
Marti.