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. -- Hal V. Engel
Attachment:
pgppOGf4cBHUX.pgp
Description: PGP signature
