[Openicc] Re: [Lcms-user] Re: [Gimp-developer] Color Management was GEGL development/gimp integration

[Jan-Peter Homann]

Hello Hal and List
As an colormanagement consultant, I mostly read only the lcms-list to 
see what is going on in the open source-scene.

You described following steps as minimum:

 > 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
 > image.

This is a very good description, what colormanagement should do for most 
of the users.

1 and 2 should be handled by image-aquisation applications. For GIMP it 
would be fine to have the option to assign a profile and to do an 
explicit tconversion from an assigned profile to an destination profile, 
if the image aquisition can´t handle the this stuff.

3 should be handled by GIMP, but the monitorprofile should be defined on 
system-level-

4 should be handled by the printer driver. Here GIMP-Print has an 
opportunity which is far better then standard-drivers for MacOSX or 
Windows. GIMP-Print can drive Printers in CMYK, which allows 
high-quality profiling. The printer-profile should be connected with the 
media/driver settings. So if the uses is chhosing a media/diver setting 
the corresponding profile (standard or individual made) should be used.

I also want to ad the point

5 systemwide colorsettings
If colorsettings are defined on systemlevel, it is much easier to get 
consistent color over differnt applications. On system-level should be 
defined:

standard setting
- RGB working space
- CMYK working space
(Rendering Intent relativ colorimetric with blackpoint compensation is 
always used)

In this scenario colormanagement could be completly hided from the 
standard user, if image aquisation applications are coming with 
standard-device-profiles and transform to the standard working space 
defined at systemlevel (eg. sRGB or AdobeRGB) GIMP uses the standard 
workingspace-profile and the monitor-profile on systemlevel. The 
printer-driver is converting from the actual working space to the 
profile for the media-settings


Advanced features:
- Setting rendering Intents for converting into and from the working space.
- CMYK-softproof for working in RGB and displaying transformation to 
CMYK working space


Making colormanagement easy is mainly a task of coordinating the 
implemtation for
- CM on System level
- CM at image aquisition
- CM at application
- CM at printer drivers


The complexity is mostly a problem that programmers in this field don´t 
coordinate their work, and the user can´t understand were 
colortransformations are applied during daily working

Greetings from berlin
:-) Jan-Peter






Hal V. Engel schrieb:
> On Monday 03 January 2005 14:27, Sven Neumann wrote:
> 
> snip
> 
> 
>>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.
> 
> snip
> 
> 
>>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 
> sane.
> 
> 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 
> following:
> 
> 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 
> image.
> 
> 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.
> 
> 


-- 
--

homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann at colormanagement.de