On Monday 03 January 2005 14:27, Sven Neumann wrote:


> I don't think we rejected this part. IIRC we said that it should be
> optional and that we want to allow people to disable color management
> entirely. Anyway, whatever we decide to do is just a matter of user
> interface and doesn't affect the GEGL operators involved.

I didn't think we were talking about user interface issues.  Rather 
this is about how the image data is handled while it is being 
manipulated by the GIMP.  Specifically should there be a color space 
transformation as part of loading the image and another when the image 
is saved. 

Yes the user should be able to turn color management off if they want.  
In fact I think that at install time it should be off by default.  
Color management is not for all users as it requires a lot of work to 
understand how it works,  to setup a good work flow and to get good 
device profiles (printers are particularly difficult).   So color 
management is really only for those that are graphics and photo 
professionals and hard core amateurs.  Anyone not prepared to do a lot 
of work to get this right should not bother with it.


> Sure, that's much appreciated. Perhaps you want to suggest a better
> design then?

I think I already did but not in great detail.  My main point is that 
the color space of the users image should ALWAYS be untouched unless 
the user specifically asks for a transformation.  There are a number 
of cases where the image must go through a color space transformation 
but only a limited set of these should affect the actual image data.

1. When the image is acquired.   The image may either remain in the 
device color space or be transformed to the users preferred working 
color space.  Either way that then becomes the image color space.   

As an example a scanned image might initially be tagged with the color 
space profile of the scanning device by the scanning software and then 
optionally converted to the users working color space either in the 
scanning software or the image software.  In Photoshop the user can 
setup Photoshop to do several different things when am image is opened 
and the embedded profile is not the same as the default (user 
selected) working profile.

a. If no profile is embedded in the image ask the user if one should be 
and allow the user to select the profile.  So if your scanning 
software was not "color aware" (like sane) you could embed the correct 
device profile here and then optionally convert the image to the (user 
selected) working color space.

b. Do nothing and use the embedded profile.

c. Ask the user if they want the image converted to the default (user 
selected) working color space.

d. Automatically convert all images to the default (user selected) 
working color space.  In this case the transformation is automatic but 
the user has specifically requested that this happen.

High end scanning software like VueScan Pro and SilverFast AI can also 
be configured to support conversion from the device color space to a 
user specified working color space.  This software scans the image 
then converts it to the working profile using the device profile as 
the starting point for the conversion.  As a side note Vuescan Pro is 
available for Linux for $79 and supports all scanner supported by 

This is one of the few cases where it is normal for an image to have a 
color space transformation that affects the actual image data.

2. Before sending the image to a printer the image will be optionally 
converted from the image color space to a user selected printer color 
space.  But this is only done to a copy of the image as it is being 
sent to the printer.  

This could also happen in the print driver.  I would personally prefer 
that the print driver handle this as this would allow for the printer 
to be color managed from all software not just "color aware" software.  

In Photoshop the user selects File ==> Print with preview.  In the 
dialog the user can select how the color transformation will happen by 
selecting both the from and to color profiles and the conversion 
intent (same as image(AdobeRGB1998) to Epson1280-1440 intent is 
perceptual with black point compensation - would be typical settings).

3. When the image is sent to the display device it will be converted 
from the image color space to the display color space.  Again like 
images going to a printer (#2 above) this will be done to a copy of 
the data not to the original image.

4. The user can at any time pull up a menu and force a color space 
conversion to an image. I have never used this functionality in 
Photoshop.  Others may have work flows that require this functionality 
such as those that work on images for customers that require that the 
final images be in a specific color space. 

Color work flows will vary depending on what the user is trying to do.  
But once someone has a good color work flow they will stick to it in 
every detail.  My experience is that the details of the work flow also 
depend on the tools being used.  My current work flow is designed to 
work with my current tools.  I do not have a problem changing my work 
flow for a different tool set.  But that tool set must have the tools 
needed to do the job.  At a minimum I need easy ways to do the 

1. Embed device profiles in acquired images.
2. Convert images to my working color space or between profiles.
3. Correctly display the image while working on it.
4. Convert the image to the correct printer profile while printing the 

Others may have totally different requirements.

I used Photoshop examples because most here have at least some 
knowledge of Photoshop and would be able to follow these examples.  
However I am not convinced that how it does things is the best or even 
a good way of doing things and I would like to hear from others on 
this list with color management work flow experience about how they 
would like to see this work.  Almost all of my color management 
experience is with Windows and Photoshop.

I have used command line utilities from LCMS to do 1, 2 and 4 with good 
results on a Linux box.  But I have found this to be tedious, time 
consuming and error prone.   I believe that 1 and 2 should be menu 
driven from the image acquisition and/or editing software.  Number 4 
would be best handled by the printer driver front end but could also 
happen in the image editing software which is what happens on a 
Windows box with Photoshop.  Number 3 would be best if handled by the 
xserver but next best would be if the image editing software would 
handle this - again with Windows and Photoshop this is handled by 
Photoshop not Windows.

Is there anyone here with color management experience on a Mac?  Is it 
much different there?  Does the Mac do things in ways that could be 
considered "best practices" that could help in designing how things 
are setup in The GIMP?  I for one would like to hear from a Mac person 
as they might have a totally different view of this.

I am also CC'ing the lcms list as I think there is a lot of expertise 
there on this subject.  They may be able to help the GIMP team out 
with design and implementation issues.   And I know that the lcms list 
is frequented by XOrg, CinePaint and Scribus folks who are interested 
in color management.  Both CinePaint and Scribus have successful but 
perhaps not fully mature implementations of color management.

Sorry for being so long winded but this is a complex subject and the 
above did not even scratch the surface.

Hal V. Engel

Attachment: pgpOX33PZxGII.pgp
Description: PGP signature

Reply via email to