I remember the color management work flow being talked about on this list in the past. I think there are still some misconceptions about how this should work. I see that Øyvind shows a work flow that converts from the images input color space to some apparently arbitrary color space (rgb8) when the image is loaded and then converted back to the input color space when the image is saved. That means that every time the image is opened and saved it will go through two color space transformations. My experience is that other tools such a Photoshop do not do this and I believe that this is a flawed design. The image should always remain in its original color space unless the user has requested that the image be converted to a new color space (from an input device space to a working space for example). So the correct flow would look like this.

1) loading the image
.-----------------------. .---.
|load_tif | |foo|
| resource = "in.tif" => gimp drawable ('CMYK') `-----------------------' `---'

2) saving the image

.---. .---------------------. |bar| |save_tif | gimpdrawable-=> resource='out.tif' | `---' `-----------------------'
3) displaying the image

.---. .-----------------------. .---. |bar| |lcms | |foo| gimp drawable -=> | |-->| in_profile='CMYK' |-->| | -=> gimp drawable
| | | out_profile='crt.icc'| | | `---' `-----------------------' `---'

There is simply no reason for the extra color space conversions and there are many reasons not to do it. Specifically the repeated conversions as the image is opened and saved would introduce changes to the color space of the image that would result in increased color errors as the image was worked on over time.

Once an image is in the working color space it should remain in that space. The only time a color space conversion should happen after that is when the image is being sent to another device such as the display or a printer. Even then the image itself is not converted but rather a temporary copy is converted and sent to the device.

On Friday 31 December 2004 11:42, Øyvind Kolås wrote:

After some discussions it seems that using GEGL for display filters,. and other color management issues involving lcms might be a good

idea.

Does the people with code checked into GEGL have any opinon on this approach?

/Øyvind K.

--- Ramblings follow:

We will work on a sample color image, called in.tif, the color

management

directly touching the image are the following operations:

1) loading the image 2) displaying the image
3) saving/exporting image

lcms should be used for the actual transformations,. some

transformations we

do manually, for instance conversion between guchar8, guint16 and

gfloat.

.----> lcms ---> display
/ / in.tif -> lcms -> gimp does foo --<
\ \ `----> lcms ---> out.tif

The three operations again, as GEGL graphs, having the actual file savers/loaders
and the lcms operation as GEGL ops.

1) loading the image
.-----------------------. .---------------------. .---. |load_tif | |lcms | |foo| | resource = "in.tif" |-->| in_profile='CMYK' |-->| | -=> gimp

drawable

| | | out_profile='rgb8' | | | `-----------------------' `---------------------' `---'

2) saving the image

.---. .-----------------------. .---------------------. |bar| |lcms | |save_tif

|

gimpdrawable-=>| |-->| in_profile='rgb8' |-->|

resource='out.tif' |

| | | out_profile='cieLAB' | |

|

`---' `-----------------------'

`---------------------'

3) displaying the image

.---. .-----------------------. .---. |bar| |lcms | |foo| gimp drawable -=> | |-->| in_profile='rgb8' |-->| | -=> gimp

drawable

| | | out_profile='crt.icc'| | | `---' `-----------------------' `---'

bar is to transform from gimps image representation to GEGLs, and foo is the opposite.

Choosing a gimp image representation to work with: ==================================================

To ease the process, using an as simple as possible gimp image representation as the inputs
and outputs of foo and bar would be needed, using tiles directly, means we deal with a linear
buffer. This will cause som extra code in gimp, but it means we can happily coexist with
exsisting tile based code. This only works well for point operations, and not for area
operations like blur. Thus:

gimptile_read

and

gimptile_write

are would be the initial point of contact between gimp and gegl.

Special code to apply a processing graph to all tiles in an image would be needed then,
a convenience function should be made. An ideal property interface to lcms needs to be
found.

Hi,

"Hal V. Engel" writes:

I remember the color management work flow being talked about on this list in the past. I think there are still some misconceptions about how this should work. I see that Øyvind shows a work flow that converts from the images input color space to some apparently arbitrary color space (rgb8) when the image is loaded and then converted back to the input color space when the image is saved. That means that every time the image is opened and saved it will go through two color space transformations.

Did you read the earlier discussions on this topic? If not, I suggest that you do that now.

Sven

On Saturday 01 January 2005 18:39, Sven Neumann writes:

Hi,

snip

Did you read the earlier discussions on this topic? If not, I suggest that you do that now.

Sven

Sven,

Yes I did read the earlier discussion several times but that was a few months ago. That is why I was surprised that a proposal surfaced here that involved doing color transformations as part of loading and saving images. This was a major part of the earlier discussions and it appeared to me that this approach had been rejected, or at least discredited, at that time. At the very least there were sound reasons put forward that called this approach into question and the only arguments on the other side were that it made programming the color management stuff a little easier. But I am also aware that there were many involved in the earlier thread on this subject that did not seem to think there was an issue with this approach.

Perhaps I misinterpreted the earlier discussion and the approach was accepted or perhaps no concensus was reached. Which leaves me in what is probably a confused state of mind on this. So at this point I do not know if a consensus was reached earlier and if so what it was.

I think I should point out that color management in GIMP is a major point of interest for me as it is the only thing at this point in time that keeps me from using The GIMP. I have been using a full, end to end, color managed work flow in my digital dark room for some time now and I consider it to be an essential element. So I have been following this in some detail for a while. I subscribed to this list specificly so that I could track progress on the color management sub-system and to perhaps participate in the discussion if it appeared that I had something to offer. When I saw the same flawed assumptions as in the earlier discussion I thought that I should point out the flaw now rather then wait. After all it is much easier and less costly to fix a design flaw early in the process than it is later on.

Hi,

"Hal V. Engel" writes:

Yes I did read the earlier discussion several times but that was a few months ago. That is why I was surprised that a proposal surfaced here that involved doing color transformations as part of loading and saving images. This was a major part of the earlier discussions and it appeared to me that this approach had been rejected, or at least discredited, at that time. At the very least there were sound reasons put forward that called this approach into question and the only arguments on the other side were that it made programming the color management stuff a little easier. But I am also aware that there were many involved in the earlier thread on this subject that did not seem to think there was an issue with this approach.

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 think I should point out that color management in GIMP is a major point of interest for me as it is the only thing at this point in time that keeps me from using The GIMP. I have been using a full, end to end, color managed work flow in my digital dark room for some time now and I consider it to be an essential element. So I have been following this in some detail for a while. I subscribed to this list specificly so that I could track progress on the color management sub-system and to perhaps participate in the discussion if it appeared that I had something to offer. When I saw the same flawed assumptions as in the earlier discussion I thought that I should point out the flaw now rather then wait. After all it is much easier and less costly to fix a design flaw early in the process than it is later on.

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

Sven

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.

Hi,

"Hal V. Engel" writes:

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.

Well, at this point we are rather talking about preparing the framework that we will need to implement color management. How exactly this is all wired up and presented to the user remains to be seen. Your feedback will certainly help with this.

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.

If we don't convert the image at load time, all plug-ins that change colors would have to be aware of the color-space the image is in. Since this is not the case for the time being, it would probably be a bad idea to not convert the image. As soon as we go further down the road and have all plug-ins as GEGL ops, this will change. But for the time being, I don't see much choice but to convert everything to sRGB. Note that we are just talking about the first step here. Something that we can achieve in the next few months, without changing each and every piece of code in GIMP and it's plug-ins.

Sven

Hi Sven,

Selon Sven Neumann :

"Hal V. Engel" writes:

it appeared to me that this approach had been rejected, or at least discredited, at that time. At the very least there were sound reasons put forward that called this approach into question and the only arguments on the other side were that it made programming the color management stuff a little easier. But I am also aware that there were many involved in the earlier thread on this subject that did not seem to think there was an issue with this approach.

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.

The short summary of the entire discussion is something like this:

We should allow a colour profile to be associated with an image if possible, and only apply it (that is, change the colorspace of an image) if explicitly requested. There will be issues with things which aren't colorspace dependent (like the color picker) as well as copying and pasting between images, which will cause problems, but for the moment the damage caused by these would be less than applying color profiles on load.

However, we should have a default working colourspace, and the user should be able to convert to that colourspace on load. This should be configurable.

There should also be an option to disable colour management altogether - in which case, we work in the default colourspace, don't do any conversion at all, and simply load and save the colour profile as a parasite attached to the image.

My understanding was that the solution which Alastair Robinson was working on was to have a plug-in to apply a color profile, but also to have the idea of a (per-image) working colourspace, and a configurable (global) display colour profile and default working colourspace. That is, every image loaded which doesn't have an attached profile will be assumed to be in that default colourspace. If it has an attached profile, the user will be offered the choice of (1) applying the profile to get to the default colorspace, (2) working in the embedded profile's colorspace or (3) disabling color management for the image, in which case we work in the default colorspace, but don't apply the profile.

Again, this is a synthesis of my understanding of that discussion, the archives are the best reference for what was said, though.

Cheers, Dave.

--
Dave Neary
Lyon, France

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.

Sven Neumann wrote:

If we don't convert the image at load time, all plug-ins that change colors would have to be aware of the color-space the image is in. Since this is not the case for the time being, it would probably be a bad idea to not convert the image. As soon as we go further down the road and have all plug-ins as GEGL ops, this will change. But for the time being, I don't see much choice but to convert everything to sRGB. Note that we are just talking about the first step here. Something that we can achieve in the next few months, without changing each and every piece of code in GIMP and it's plug-ins.

Hello Sven,

Sorry for breaking the thread, but I was not able to find this message as mbox-archiv.

I think that the suggestions made by Hal V. Engel and Jan-Peter Homann (a well known color management consultant in Germany, afair also a member of the eci.org maillist, a very good resource for cms knowledge)are very important for a professional color management in the GIMP.

I'm not a Programmer, but isn't it possible to make a plug-in which load's the icc information at a first step, to offer the user the ability to decide in which way he wants to handle the file regarding it's color space?

After this step the file will be converted into the choosed colorspace[*] and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a "color proof view" with a selectable icc profile for the soft proof.

Please, correct me if I'm wrong.

[*] a. no colormanagement
b. working colorspace (imho don't offer the user the ability to preselect the working color space in the preferences and instead convert all files into sRGB is the worst we can do)
c. apply an icc profile and then as a suboption c1. convert it into the working color space.

For Gimp-print we can handle the icc like Jan-Peter Homann suggested.

I agree, that this behavior would be very close to the behavior of adobe photoshop regarding color-management, which got imho a very good implementation of a colormanagement for professional needs.

There are good starting points by Alastair M.Robinson .

He made a good start of such a plugin with it's 'separate' plugin: http://www.blackfiveservices.co.uk/separate.shtml He send me a copy of an improved version for gimp 2.x .

Please see this thread in gimp user: http://article.gmane.org/gmane.comp.video.gimp.user/6008

He also works on a programm called photoprint: http://www.blackfiveservices.co.uk/photoprint.shtml based on guten print for gimp. (GIMP-Print/GutenPrint version 5 (beta 2))

for example photoprint..

o Can apply ICC colour profiles, with selectable rendering intent.
o Can generate rough-cast ICC colour profiles, given RGB Primary chromaticity coordinates (x,y), Gamma values and White Point.
o Can read and use an embedded colour profile (currently TIFF only).

He's working on CMYK support implemented with Argyll:

Coming soon: Support for CMYK images and profiles (useful in combination with Argyll), and widgets for dealing with physical dimensions. [...]
CMYK images are not yet properly supported, but I intend to support these in future.

I think it's very important for the future of the gimp, to handle color management in a proper and professional way, to get it on a professional level also for pre-press image processing.

Is there an existing roadmap for this issue?

Thank you

Gerhard Gaussling

Hi Gerhard,

Gerhard Gaußling wrote:

I'm not a Programmer, but isn't it possible to make a plug-in which load's the icc information at a first step, to offer the user the ability to decide in which way he wants to handle the file regarding it's color space?

It would be possible to do the following:

- load image's raw data, and ICC profile - During display, convert from source colorspace to display colorspace
- During saving, save the originally loaded ICC profile back to file, if the format supports it, or convert to sRGB if it doesnt.

The problems with that approach are

- Lots of elements in the GIMP are not colorspace aware - for example, you would have to modify the paint tools to detect whether there was an ICC profile associated with a display they were painting to, and color convert the (sRGB) data that they are painting. This is not possible currently, and Sven has expressed a desire that color management be kept out of the core in the past.
- Data which enters the image from other sources (copy & paste from another image, for example) may have been in a different colorspace, requiring convertion or some other funkiness to keep things coherent inside the image

After this step the file will be converted into the choosed colorspace[*] and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a "color proof view" with a selectable icc profile for the soft proof.

We currently have the ability to do color proofs with external ICC profiles. THe interface to the loading of the profiles isn't perfect yet, but it's there.

Cheers, Dave.

Hi,

Gerhard Gaußling writes:

I think that the suggestions made by Hal V. Engel and Jan-Peter Homann (a well known color management consultant in Germany, afair also a member of the eci.org maillist, a very good resource for cms knowledge) are very important for a professional color management in the GIMP.

Sure, noone questioned that.

I think it's very important for the future of the gimp, to handle color management in a proper and professional way, to get it on a professional level also for pre-press image processing.

Ditto.

Is there an existing roadmap for this issue?

No, we are only just in the process of making one.

Sven

Hi,

David Neary writes:

...Sven has expressed a desire that color management be kept out of the core in the past.

You misunderstood me then. Managing colors does of course belong into the core but I would like to keep the implementation out of the core. The idea is to be able to use different color management systems and not to restrict ourselves to lcms. GEGL seems to offer just the right level of abstraction that would be needed here. That's why it seems like a nice idea to use it.

Sven

Hello David,

BTW: Using the gmane.org newsserver and a news client seems to be a good alternative to the mbox archive ;-).

David Neary wrote:

[...]
Gerhard Gaußling wrote:

I'm not a Programmer, but isn't it possible to make a plug-in which load's the icc information at a first step, to offer the user the ability to decide in which way he wants to handle the file regarding it's color space?

It would be possible to do the following:

- load image's raw data, and ICC profile - During display, convert from source colorspace to display colorspace

If you apply a conversion to the file there will be a loss of color information, so it's necessary, that we avoid unneeded conversions to the original file.

For example, if you convert from adobeRGB into sRGB and viceversa several times, you wouldn't receive the original color impression never more, it's lost, and there for in poor quality (comparable with the jpeg lossy compression, keep that in mind).

So, we have to convert only the displayed version of the data, not the original data (Jan-Peter, Hal and others, please correct me if I'm wrong).

This is important, to get a display color as closed to the original scene in nature as possible, adjusted to the display hardware by the measured or proofed monitor profile.

While rendering the data for the display this way, the data itselves stays in working color space, or original color space (as choosen by the user while opening the file).

It should be saved with the working color space e.g. as device independant suggested by ECI.org eciRGB.icc, which is comparable with widegammut and adobeRGB, or the original color space (as choosen by the user while opening the file), to avoid unneeded conversions while saving the data.

eciRGB.icc offers a wider range of colors compared to sRGB, which got a very limited color space, so it avoids clipping, when converting e.g. from scanner profiles to the working color space.

The user should archive the data in the recommended device independent colorspace (e.g. for Europe according to the suggestion of the ECI in eciRGB color space [1]).

To Print the data it should be converted to the printer profile (This should happen in the service bureau or the printer service, maybe the printer offers you the printer-device profile to do the conversion by yourself. At home you can measure your inkjet profile for example, and apply that.)

If you want to save your work for web you should do that by using the conversion from (the wider) working color space to sRGB the default for webpublishing.

- During saving, save the originally loaded ICC profile back to file, if the format supports it, or convert to sRGB if it doesnt.

This all should be flexible and interactive (there could be an easy mode coosen in the preferences to disable colormanagement at all), and it's important to retain as much original color informations than possible.

The problems with that approach are

- Lots of elements in the GIMP are not colorspace aware - for example, you would have to modify the paint tools to detect whether there was an ICC profile associated with a display they were painting to, and color convert the (sRGB) data that they are painting. This is not possible currently, and Sven has expressed a desire that color management be kept out of the core in the past.

Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions have to wait for the release after GEGL? For a new rendering-engine further to GEGL? GIMP 3.0?

I want only remember the developers that there is already a state of the art color-management used by the printing industry, which the GIMP-developers can't ignore while implementing colormanagement and CMYK or multichannel/DeviceN mode for the GIMP. Just avoid to go into the wrong direction when going further with the implementation of colormanagement.

- Data which enters the image from other sources (copy & paste from another image, for example) may have been in a different colorspace, requiring convertion or some other funkiness to keep things coherent inside the image

Photoshop lets pop up a dialog where the user can decide the kind of conversion he will do for the pasted/dragged image.

After this step the file will be converted into the choosed colorspace[*] and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a "color proof view" with a selectable icc profile for the soft proof.

We currently have the ability to do color proofs with external ICC profiles. THe interface to the loading of the profiles isn't perfect yet, but it's there.

Desired is a 'On the fly' Softproof.

I admit, that this is a very complex subject, and it is much work to implement all this color stuff into the GIMP, but I'm shure it's worth it.

Thank you

Gerhard

[1]http://www.eci.org/eci/en/044_working_colour_spaces.php http://www.eci.org/eci/en/021_goals.php http://lists.transmedia.de/mailman/listinfo/eci-en http://www.eci.org/eci/en/070_links.php

On Saturday 15 January 2005 13:21, David Neary wrote:

Hi Gerhard,

Gerhard Gaußling wrote:

I'm not a Programmer, but isn't it possible to make a plug-in which

load's

the icc information at a first step, to offer the user the ability

to

decide in which way he wants to handle the file regarding it's

color space?

It would be possible to do the following:

- load image's raw data, and ICC profile - During display, convert from source colorspace to display colorspace
- During saving, save the originally loaded ICC profile back to file, if the format supports it, or convert to sRGB if it doesnt.

I am not sure that the image should be converted to sRGB if the file format does not support embedded profiles. For one thing how likely is it that someone would open an image in a file format that had an embedded profile would then save the file in a format that did not support an embedded profile. The other reason that I have for this reservation is that many of us have printers that have more gamut than sRGB supports. sRGB is OK, even preferred, for web work and for those that are working with low gamut printers, such as CMYK offset printers, but my feeling is that it is too limited for those that have wider gamut printers like the 6 and 7 color Epson or HP printers for example. That is one of the reasons that Photoshop defaults to the AdobeRGB color space, which is a medium wide gamut color space, as this has enough gamut to fully support these wider gamut printers. If the GIMP is going to use a default color space this should not be a low gamut color space like sRGB.

On the other hand anyone working with image file formats that do not support embedded profiles should have color management turned off. So perhaps someone can convince me that this is the correct thing to do. I think it would be useful for this list to talk about how The GIMP will work with color management turned on and with it turned off. As these 2 configurations will be used by users that are working at very different levels of expertise and with significantly different expectations.

The problems with that approach are

- Lots of elements in the GIMP are not colorspace aware - for example, you would have to modify the paint tools to detect whether there was an ICC profile associated with a display they were painting to, and color convert the (sRGB) data that they are painting. This is not possible currently, and Sven has expressed a desire that color management be kept out of the core in the past.

At this point nothing in The GIMP is color aware other than the proofing plugin. So should every plugin need to do color conversions to the display color space or should this be handled in one place? Since current plugins know nothing about color management and color spaces should we be making assumptions about what color space these are working in (some plugin authors may have assumed sRGB but have all of them)?

Since I have not looked at the code I do not know what should and should not be in the core. But perhaps some color management functionality belongs in the core. But I will let those that know how the application is structured work this out. But it seems to me that the core could have a high level color management interface that abstracts this to hide the specific implementation details. Then the core could map these to a specific implementation using LCMS, Argyll or some other CMS library. Perhaps this is what Sven had in mind.

- Data which enters the image from other sources (copy & paste from another image, for example) may have been in a different colorspace, requiring convertion or some other funkiness to keep things coherent inside the image

Yes is is exactly correct. When we copy from image A in color space X to image B in color space Y the image data coming from A must be converted from color space X to color space Y. To do anything else would not be correct.

After this step the file will be converted into the choosed

colorspace[*]

and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a

"color

proof view" with a selectable icc profile for the soft proof.

We currently have the ability to do color proofs with external ICC profiles. THe interface to the loading of the profiles isn't perfect yet, but it's there.

Cheers, Dave.

Hi,

Gerhard Gaußling writes:

Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions have to wait for the release after GEGL? For a new rendering-engine further to GEGL? GIMP 3.0?

Why? Almost everything you listed can already be done in GIMP. It's just a bit akward to do it from a user interface point of view and that's what we want to improve for GIMP 2.4.

Desired is a 'On the fly' Softproof.

Could you explain what you mean by "on the fly softproof" and how that is any different to the softproof that's available?

Sven

Sven Neumann wrote:

You misunderstood me then. Managing colors does of course belong into the core but I would like to keep the implementation out of the core. The idea is to be able to use different color management systems and not to restrict ourselves to lcms. GEGL seems to offer just the right level of abstraction that would be needed here. That's why it seems like a nice idea to use it.

That's a good point, also because in the lcms-user maillist there was a thread about "Fast colour managed preview, how?" , where Gerhard Fuernkranz pointed out, that "Argyll's IMDI routines are _very fast_ with 8bpp input": http://sourceforge.net/mailarchive/forum.php?thread_id=6213268&forum_id=1912 .

regards

Gerhard

On Saturday 15 January 2005 14:42, Gerhard Gaußling wrote: snip

For example, if you convert from adobeRGB into sRGB and viceversa

several

times, you wouldn't receive the original color impression never more,

it's

lost, and there for in poor quality (comparable with the jpeg lossy compression, keep that in mind).

So, we have to convert only the displayed version of the data, not

the

original data (Jan-Peter, Hal and others, please correct me if I'm

wrong).

This is exactly correct. The conversion between color spaces will always introduce quantization errors. If only one conversion is done these have a minimal effect on the image assuming the the gamut of the original fits into the new color space with minimal loses. This is not likely to be the case when converting from a wider space such as AdobeRGB to a narrow space like sRGB. But if this happens many times the image will suffer significant degradation. In other words the color space conversion is NEVER lossless.

Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions

have to

wait for the release after GEGL? For a new rendering-engine further

to

GEGL? GIMP 3.0?

I am not sure that I want to wait that long but if it will take that long to get it right then so be it. I would rather wait and get a correct implementation then get an incorrect one sooner. But I think that it should be possible to do at least some of this sooner. For example perhaps a color aware printer interface could be added sooner by leveraging Alastair M.Robinson work on PhotoPrint.

We currently have the ability to do color proofs with external ICC profiles. THe interface to the loading of the profiles isn't perfect yet, but it's there.

Desired is a 'On the fly' Softproof.

I have little use for soft proofs since my custom profiled printer gives results that are almost identical to what I see on the screen in Photoshop. But for those that are working with low gamut printers this is likely more useful.

I admit, that this is a very complex subject, and it is much work to implement all this color stuff into the GIMP, but I'm shure it's

worth it.

I would also like to add that although I am not a color management professional I did struggle with color issues in my digital darkroom and as a result I have spent many hours setting up a proper (but perhaps somewhat basic) color management work flow. In the process I studied many sources and learned a lot. Gerard is correct this is not going to be trivial and it will take a lot of effort to get this in place.

For those that are new to color management and would like to understand this better from a CM users perspective I would like to recommend that a good starting point is
http://www.normankoren.com/color_management_2.html#Implementation%3C/A%3EHere, %20you%20helped%20me,
%20again!%20%20I%20am%20learning%20how%20to%20do%20the This web site is from a color management users perspective and it starts out with a basic overview of how color management works and what all of the pieces are and how they all work together. He give examples of how to setup things in both Photoshop and Picture Window Pro. So this has lots of info about how two different apps have set up the user interface for this.

Also one of the interesting things on this site is that he has the GretagMacbeth ColorChecker test pattern in both SMPTE-240M (same as AdobeRGB 1998) and sRGB color spaces. One of the patches (out of 24) is out of gamut in the sRGB version of the image but is in gamut in the SMPTE-240M image.

Hello Sven,

thank you for your reply!

Sven Neumann wrote:

Gerhard Gaußling writes:

Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions have to wait for the release after GEGL? For a new rendering-engine further to GEGL? GIMP 3.0?

Why? Almost everything you listed can already be done in GIMP.  It's just a bit akward to do it from a user interface point of view and that's what we want to improve for GIMP 2.4.

This is good to hear!

Desired is a 'On the fly' Softproof.

Could you explain what you mean by "on the fly softproof" and how that is any different to the softproof that's available?

What kind of softproof is available? Hmm.. I can nothing similar find here.

I got under Image > Separate > Proof the possibility of an Softproof (plug in 'separate' by Alistair M. Robinson). It shows up a dialog which asks me the Source Profile "/usr/lib/scribus/profiles/AdobeRGB1998.icc" and the Destination Profile
"/usr/lib/scribus/profiles/USWebCoatedSWOP.icc" (defaults, should be eciRGB.icc and isocoated.icc according to eci.org [1]) and the checkboxes "Preserve Pure Black" and "Overprint Pure Black". If I press OK I got the message-dialog "PROOF IMAGE Image is not separated...". So I have to separate the image first into cmyk mode by the plugin 'separate'. That's not a Softproof 'on the fly'.

So I have to seperate the image first. I do it with the default profiles. A new image with the CMYK separated RGB shows up (5 layers, 4 layers CMYK mode 'darken only' 1 Background, Image in RGB Mode, if I save that it will be saved as cmyk tif). The 3rd step is to proof that image with the CMYK profile. A 3rd image pops up (RGB, 1 Layer)... That's Not a "on the fly preview" at all.

Please, I'm sorry for my sad english, and I hope this all doesn't sounds to rude. I wanted only spend some Information of an user point of view, that's all...

regards

Gerhard

[1] http://www.eci.org/eci/en/044_working_colour_spaces.php
More information about the European Color Initiative and their work on standardisation of a color workflow:

http://www.eci.org/eci/en/021_goals.php http://www.eci.org/eci/en/035_digital_photography.php http://www.eci.org/eci/en/050_news.php

Here is some Information for download:

http://www.eci.org/eci/downloads/ECI-en/eci_general_downloads/eci_whitepaper_1_1_ENG.pdf
46 page (~ 500 kB)

Guidelines for device-independent color data processing in accordance with the ICC-Standard

(Preview) Table of Content:

Foreword
1. Objectives of the »European Color Initiative« 2. Objectives and Contents of the ECI-Guidelines 3. Commitment to Supporting the ICC-Standard 4. Establishing the Proof
4.1 »Idealized ICC-Proof«
4.2 »ICC-Proof« (»ICC Contract Proof«) 4.3 »ICC-Proof with Generic Profiles« (»ICC Contract Proof«) 4.4 »ICC-Soft Proof« 4.5 Proprietary Digital Proof Methods 5. Administrative Communication between »Data Supplier« and »Data Receiver« 6. Basic Workflow for Digital Processing of Printed Material 7. Technical Specifications for the Exchange of Advertisement Files 7.1 Exchange Format
7.2 Exchange Color Spaces
7.3 Overprinting and Trapping
7.4 Process and Data Control
7.5 Proofs
7.6 Data Exchange Media
8. Technical Specifications for the Exchange of Files for Catalogue Production
8.1 to 8.x
9. Technical Specifications&
9.1 to 9.x
Appendix 1: Recommendations for the Adaptaion of ICC-Workflows in Advertising Production
Appendix 2: Recommendations for the Adaptation of ICC-Workflows in Catalogue Production
Appendix 3: Recommendations for the Adaptation of ICC-Workflows in General Offset Production
Appendix 4: Recommendations for the Adaptation of ICC-Workflows in Editorial and Publishing Techniques
Appendix 5: Process Control The Ugra/FOGRA Media Wedge Appendix 6: »MediaStandardPrint« (not included) Appendix 7: The Corner Points of the ICC-Standard Appendix 8: »The 10 Commandments of Color Managements« Appendix 9: Example of a Measuring File in Accordance with the Color Chart ISO 12642 (IT8.7-3)

Hi Gerhard,

Gerhard Gaußling wrote:

What kind of softproof is available? Hmm.. I can nothing similar find here.

It took me a while to find it too - it's under the View -> Display Filters.

In the resulting dialog you can choose from a number of filters, including Colour Proof.

When we were discussing colour management a few months back, I hacked the Colour Proof filter to do a normal working-profile -> monitor-profile transform, and it worked pretty well.

The sticking point with the display filters is that there's currently no way of getting a reference to the current image into them. Without that, using a specific profile for individual images is next to impossible, and while we're restricted to 8-bit precision internally, that's pretty much a vital capability.

All the best, --
Alastair M. Robinson

Hal V. Engel wrote:

snip

For those that are new to color management and would like to understand this better from a CM users perspective I would like to recommend that a good starting point is

http://www.normankoren.com/color_management_2.html#Implementation%3C/A%3EHere,

%20you%20helped%20me,
%20again!%20%20I%20am%20learning%20how%20to%20do%20the

Hello Hal, thanks for the link! This is a shorter one of the same site ;-) http://www.normankoren.com/color_management.html or the same uri like you used in a more shorter way: http://Implementing-cms.notlong.com

This web site
is from a color management users perspective and it starts out with a basic overview of how color management works and what all of the pieces are and how they all work together. He give examples of how to setup things in both Photoshop and Picture Window Pro. So this has lots of info about how two different apps have set up the user interface for this.

Also one of the interesting things on this site is that he has the GretagMacbeth ColorChecker test pattern in both SMPTE-240M (same as AdobeRGB 1998) and sRGB color spaces. One of the patches (out of 24) is out of gamut in the sRGB version of the image but is in gamut in the SMPTE-240M image.

good night

Gerhard

Hi,

Gerhard Gaußling writes:

What kind of softproof is available? Hmm.. I can nothing similar find here.

Go to View->Display Filters and enable the Display Proof filter.

Please, I'm sorry for my sad english, and I hope this all doesn't sounds to rude. I wanted only spend some Information of an user point of view, that's all...

Your feedback is very much appreciated.

Sven

Sven Neumann wrote:

Go to View->Display Filters and enable the Display Proof filter.

Thanks to you and Alastair to pointing that out, I'm quite impressed! Even the rendering intends are there! So I'm pleased that there is some work going on in this direction. In the GEGL TODO there is shown 0% progress for the color models and cms, that might be not related to reality! (even if this display filter is not part of GEGL)

Please, I'm sorry for my sad english, and I hope this all doesn't sounds to rude. I wanted only spend some Information of an user point of view, that's all...

Your feedback is very much appreciated.

You're welcome! (Hope this english fits!)

Kind regards

Gerhard

Hi,

"Alastair M. Robinson" writes:

When we were discussing colour management a few months back, I hacked the Colour Proof filter to do a normal working-profile -> monitor-profile transform, and it worked pretty well.

Yes, it's a shame that you never submitted this for inclusion. It could have become part of the 2.2 release.

The sticking point with the display filters is that there's currently no way of getting a reference to the current image into them. Without that, using a specific profile for individual images is next to impossible, and while we're restricted to 8-bit precision internally, that's pretty much a vital capability.

Let's try to implement this in small steps then. As a first step I would like to add a couple of options to the preferences to allow users to define default locations for color profiles, to enable/disable color management and to set a number of default settings. Stefan Döhla sent me a patch last year that implements this and I will probably base the changes on that. The settings he suggested are:

- use CM or not - display profile
- default workspace profile
- default rendering intent for color conversion + from workspace to display (default set in display profile) + from workspace to printer (should default to * perceptual for pictures
* relative colorimetric for most other work) - default cmyk-profile (is later used to convert RGB->CMYK) - default profile path (/usr/share/color/icc/ and ~/.color/icc/)

As soon as we have such settings, we need to figure out a way to make them available to plug-ins and modules. We also need an API to access the color-profile attached to an image.

Sven

Am Samstag 15 Januar 2005 23:42 schrieb Gerhard Gaußling:

Photoshop lets pop up a dialog where the user can decide the kind of conversion he will do for the pasted/dragged image

Of course only if the source color space of the imported (pasted/dragged) image is different from the working color space. As I mentioned before the working color space is also meant as 'device independent' like recommended by eci.org, and there for suitable for archives. (The recommendations might be different for the US and other non-european states: there it might be recommend to use AdobeRGB as wotrking color space - and WebCoatedSWOPv2v as printing profile ).

If the archived files are saved in (the recommended wide working color space such as eciRGB or AdobeRGB, or WideGammut) the appropriate color space, then it can be imported without flaws (w.o. popup window with the selection dialog) into theGIMP.

regards

Gerhard

Sven Neumann wrote:

- display profile

should be adjusted _once_ systemwide (every time changeble by systemwide color preferences indepenant from the GIMP, as used by (e.g.)scribus [1], inkscape [2], sodipodi[3] wine e.g. for Photoshop and maaybeee by commercial apps available for *nix like Page Stream [4], Cenon [5], Viva Designer [6]) with an monitor profile (like the one of l-prof or adobe-gamma etc.), there for it would be overwhelming to have this choice again in the opening file dialog, if the profile doesn't fits the working color space.

regards

Gerhard

[1] http://www.scribus.org.uk/ [2] http://www.inkscape.org
[3] http://www.sodipodi.com/
[4] http://www.grasshopperllc.com/
[5]
[6] http://www.vivaip.de/

Hello Sven,

Sven Neumann wrote:

- display profile

should be adjusted _once_ systemwide (every time changeable by systemwide color preferences independant from the GIMP, as used by (e.g.)scribus [1], inkscape [2], sodipodi[3] wine e.g. for Photoshop and maaybeee by commercial apps available for *nix like Page Stream [4], Cenon [5], Viva Designer [6]) with an monitor profile (like the one of l-prof or adobe-gamma etc.), there for it would be a little overwhelming to have this choice again in the opening file dialog, if the profile doesn't fits the working color space.

regards

Gerhard

[1] http://www.scribus.org.uk/ [2] http://www.inkscape.org
[3] http://www.sodipodi.com/
[4] http://www.grasshopperllc.com/
[5] http://www.cenon.info/frame_gb.html [6] http://www.vivaip.de/

Sven Neumann wrote:

Stefan Döhla sent me a patch last year that implements this and I will probably base the changes on that. The settings he suggested are:

- use CM or not - display profile
- default workspace profile
- default rendering intent for color conversion + from workspace to display (default set in display profile)

monitor/display profile

+ from workspace to printer (should default to

us: webcoatedSWOP for ads (coated paper) and europe: isocoated.icc (also coated paper)

* perceptual for pictures
* relative colorimetric for most other work)

agreed, but flexible enough to set it to saturation or absolute rendering intend.

- default cmyk-profile (is later used to convert RGB->CMYK)

see above europe: isocoated.icc

- default profile path (/usr/share/color/icc/ and ~/.color/icc/)

agreed

As soon as we have such settings, we need to figure out a way to make them available to plug-ins and modules. We also need an API to access the color-profile attached to an image.

I like the idea of an abstract API, which can be managed by different cmm e.g. lcms or argyll

This seems to be all over viewed a reasonable practice to use CMS on image manipulation.

regards

Gerhard

Gerhard Gaußling wrote:

+ from workspace to printer (should default to

us: webcoatedSWOP for ads (coated paper) and europe: isocoated.icc (also coated paper)

Only as a suggestion, please keep it flexible!

* perceptual for pictures
* relative colorimetric for most other work)

agreed, but flexible enough to set it to saturation or absolute rendering intend.

- default cmyk-profile (is later used to convert RGB->CMYK)

see above europe: isocoated.icc

see above, keep it flexible! You have to have the access to choose the printer profile of the device, which is used actually !

regards

Gerhard

On Saturday 15 January 2005 17:37, Sven Neumann wrote: snip

Let's try to implement this in small steps then. As a first step I would like to add a couple of options to the preferences to allow users to define default locations for color profiles, to enable/disable color management and to set a number of default settings. Stefan Döhla sent me a patch last year that implements this and I will probably base the changes on that. The settings he suggested are:

- use CM or not - display profile
- default workspace profile
- default rendering intent for color conversion + from workspace to display (default set in display profile) + from workspace to printer (should default to * perceptual for pictures
* relative colorimetric for most other work) - default cmyk-profile (is later used to convert RGB->CMYK)

I guess that this is for the printer? Since all of my printers are logically RGB devices (the drivers expect RGB input) I am not sure how useful this is to me but for others it might have it's uses. But perhaps we need to understand what this will be used for before including it.

Also printer profiles are very specific to the printer hardware (not just the printer model but the specific printer you are using), the paper, ink and all of the driver setting (resolution, dither....). So I have more than one printer profile for each printer (typically 5 or 6).

When you are in the printer dialog in GIMP you have the ability to add a new logical printer and use that to "name a collection of settings you wish to remember for future use." This is the ideal place for printer profiles to be specified. So the user should be able to set the default profile and rendering intents for each logical printer along with all of the other settings for the driver. This would be a way better setup than how this is handled in photoshop and would be a great way to simplify and facilitate the management this part of a CM work flow.

- default profile path (/usr/share/color/icc/ and ~/.color/icc/)

All of the other stuff looks fine to me.

Hi,

Gerhard Gaußling writes:

Sven Neumann wrote:

- display profile

should be adjusted _once_ systemwide (every time changeable by systemwide color preferences independant from the GIMP, as used by (e.g.)scribus [1], inkscape [2], sodipodi[3] wine e.g. for Photoshop and maaybeee by commercial apps available for *nix like Page Stream [4], Cenon [5], Viva Designer [6]) with an monitor profile (like the one of l-prof or adobe-gamma etc.), there for it would be a little overwhelming to have this choice again in the opening file dialog, if the profile doesn't fits the working color space.

Yes, ideally it would be configured systemwide. Not once, but once per monitor. But unless a standard exists for system-wide color management configuration, we don't have much choice but to implement our own configuration. If you can point me to such a standard, we will of course consider to adopt it.

Sven

Hi,

"Hal V. Engel" writes:

- default cmyk-profile (is later used to convert RGB->CMYK)

I guess that this is for the printer? Since all of my printers are logically RGB devices (the drivers expect RGB input) I am not sure how useful this is to me but for others it might have it's uses. But perhaps we need to understand what this will be used for before including it.

I am not sure what Stefan added this for in the first place but we will need a CMYK profile to be able to implement a useful CMYK color selector. We already have such a color selector but at the moment it uses a rather naive approach of converting between CMYK and RGB.

When you are in the printer dialog in GIMP you have the ability to add a new logical printer and use that to "name a collection of settings you wish to remember for future use." This is the ideal place for printer profiles to be specified. So the user should be able to set the default profile and rendering intents for each logical printer along with all of the other settings for the driver. This would be a way better setup than how this is handled in photoshop and would be a great way to simplify and facilitate the management this part of a CM work flow.

We will let the print plug-in deal with this. Ideally the print plug-in would not be part of GIMP. Instead give the user the choice to pick his/her preferred print plug-in.

Sven

The idea is to be able to use different color management systems and not to restrict ourselves to lcms.

Yes !! Please. We should have the possibility to decide if use one or other CMS.

/*--------------------------------------*/ Francisco Bernal Rosso
Webpage at:
http://www.geocities.com/pacorosso
http://www.fotoforum.net/socios/b/b_f/fotos.htm http://www.michelle7.com/contributors/r/paco_rosso.htm

On Saturday 15 January 2005 05:37 pm, Sven Neumann wrote:

snip

Let's try to implement this in small steps then. As a first step I would like to add a couple of options to the preferences to allow users to define default locations for color profiles, to enable/disable color management and to set a number of default settings. Stefan Döhla sent me a patch last year that implements this and I will probably base the changes on that. The settings he suggested are:

- use CM or not - display profile
- default workspace profile
- default rendering intent for color conversion + from workspace to display (default set in display profile) + from workspace to printer (should default to * perceptual for pictures
* relative colorimetric for most other work) - default cmyk-profile (is later used to convert RGB->CMYK) - default profile path (/usr/share/color/icc/ and ~/.color/icc/)

As soon as we have such settings, we need to figure out a way to make them available to plug-ins and modules. We also need an API to access the color-profile attached to an image.

Sven

Sorry for such a long note.

I have been playing around with the 2.3.2 snap shot and it looks like much of the above is working. It also gave me some ideas about what needs to be done and also how the menus for this could be structured.

I thought that perhaps some of this is allready underway and in CVS. So I got a copy of CVS and tested it. I did not see any noticeable changes.

Things that need to be implemented:

1. Currently embedded profiles are not used. This needs to be implemented. The gimp-color-management plug-in (by Jordi Canton ) looks like it has the code needed to read in an embedded profile and could be leveraged to get this functionality. Highest priority of any CM work.

2. Default Profile Paths need to be implemented. This should be user modifiable. On open source systems it should be set to ~/.color/icc:/usr/share/color/icc by default and the user should only be able to add additional locations to this path (not sure about the last part). On open source systems The GIMP installation should create these directories if they do not exist (? not sure about this). On closed source systems the system default locations should be used. On Windows XP this would normally be C:\windows\system32\spool\drivers\color. I don't know what it is on a Mac. Medium to low priority.

3. Menu items to assign profiles to images and to convert images between color spaces needs to be implemented. There is already a plug-in available that sort of does this (gimp-color-manager). It is on the rough side and has a more complex UI than is really needed and the UI confusing. This either needs to be simplified and cleaned up or just used to pull out needed functionality for implementing a cleaner UI. High priority.

4. Some (image acquisition) plug-ins will need a way to pass profile information into GIMP. For example UFRAW (recommended) is a RAW conversion utility that runs both stand alone and as a GIMP plug-in. It is CM aware and it can embed user specified profiles and optionally convert images from that device profile to a working space profile. In standalone mode it can save the image file with an embedded profile. Currently it has no way to pass the profile information to GIMP when running as a plug-in. Medium priority.

Here is a proposal for how the color management related menus could be structured. It leverages what is allready there but tries to make the intent of each item clearer and easier to understand if possible. It also implies certain functionality that needs to be implemented.

Global CM configuration menus located in:

File ==> Preferences ==> Color Management

Color Management on (check box) (global flag to turn CM on or off. Default is off. If off all CM options, global or image specific, have no affect. This is currently missing.)

Profiles Path dialog (see #2 above)

Display (This could also be located in File ==> Preferences ==> Display)

Try to obtain the monitor profile from the X server (check box) Monitor profile (drop down use profile path to get list of profiles) Rendering Intent (drop down)
Desaturate monitor colors by ??? % (new - low priority) (This does not need the current Mode of operation drop down. see Color Management on item above and Print Simulation item below.)

Color Management Policies

Working Color Spaces (These are the RGB and CMYK profiles in the current GIMP preferences menu)

RGB (drop down use profile path to get list) CMYK (drop down use profile path to get list) Grey (drop down use profile path to get list) (new)

Profile Mismatches On Opening
ask or always convert to working space (radio button) When Pasting
ask or always convert to destination color space (radio button)

Missing Profiles ask when opening (check box)

Default (Global?) Conversion Options

Rendering Intent (drop down) Use Black Point Comp (check box)
Use dithering on 8 bit/ch images (check box) (new - low priority)

Image specific CM menu items (located in the Image and View menus):

Image ==> Mode (current plug-in, see #3 above, uses Filters ==> Colors ==> Apply ICC Profile Using Image ==> Mode would make this exactly like that other image editor)

Assign Profile ==> dialog (use profile path to get list) Convert to Profile ==> dialog (use profile path to get list)

View ==> Print Simulation (or SoftProof or Proof Setup?) (currently is located in View ==> Display Filters which is confusing)

Simulation (SoftProof or Proof?) Mode on or off (radio button or check box) Printer Profile (drop down use profile path to get list) Rendering Intent (drop down)
Black Point comp (check box)
Use Paper White (check box) (new - low priority) Use Ink Black (check box) (new - low priority)

It would be great if it were possible to somehow make the Print Simulation settings for an image persitant so that it did not have to be reset every time an image was opened. I don't know of any tools that currently do this (Photoshop does not) so I don't know if it is feasible. PhotoShop allows users to save a named SoftProof configuration that is then available in the View ==> Proof Setup menu. Low priority.

Printer CM stuff belongs in the gimp-print (guten-print) plug-in and I will save my thoughts about how that should be structured for later.

Just wanted to add that what is there now, with in its limits, is a big step forward and works well. Good job everyone. Now it needs to be kicked up to the next level.

Hal

Hi,

interesting how much effort is being spent lately on reiterating what still needs to be done on color management. I think we have made a rather detailed list of required changes for GIMP 2.4 and obviously it's not quite there yet. I will get back to color management as soon as the new foreground select tool is working good enough. Then, as soon as the missing infrastructure for plug-ins and modules is added, I could need some help with implementing the missing bits in plug-ins and modules.

Sven

I reiter my desire to work in that modules. But do not have time to play the game of the bugs to learn the basis of the gimp programming.

/*--------------------------------------*/ "If quality is important, sRGB is not an option" (From the European Color Initiative web page www.eci.org)

Francisco Bernal Rosso

Luz-color-fotografia Redacción y traducción

Webpage at: http://pacorosso.blogspot.com
http://www.geocities.com/pacorosso
http://www.fotoforum.net/socios/b/b_f/fotos.htm http://www.michelle7.com/contributors/r/paco_rosso.htm

Hi,

interesting how much effort is being spent lately on reiterating what still needs to be done on color management. I think we have made a rather detailed list of required changes for GIMP 2.4 and obviously it's not quite there yet. I will get back to color management as soon as the new foreground select tool is working good enough. Then, as soon as the missing infrastructure for plug-ins and modules is added, I could need some help with implementing the missing bits in plug-ins and modules.

On Mon, 2005-08-08 at 23:31 -0700, Hal V. Engel wrote:

View ==> Print Simulation (or SoftProof or Proof Setup?) (currently is located in View ==> Display Filters which is

confusing)

Simulation (SoftProof or Proof?) Mode on or off (radio button or

check box)

Printer Profile (drop down use profile path to get list) Rendering Intent (drop down)
Black Point comp (check box)
Use Paper White (check box) (new - low priority) Use Ink Black (check box) (new - low priority)

Just some notes for anyone thinking about implementing some of this:

Black point compensation is not a part of the ICC specification and is not currently available in any icc library that I know of.

Use paper white: requires ink black to be on also. Use an absolute colorimetric transform.

Use ink black: I belive this option would be pretty simular to using an absolute colorimetric transform for the shadow, and a relative colorimetric transform for the highlight. I know this is possible with the argyll cms library, but I'm not sure about any others. (see the -w option to icclink)

Neither ink black or paper white is on: Use a relative colorimetric transform.

IMHO: Rather than trying to duplicate adobe's black point compensation, I think our time would be better spent exploiting argyll's device link profiles and image specific gamut mapping capabilities.

more info on argyll at http://www.argyllcms.com

Jay Cox jay@gimp.org

Hi,

Jay Cox wrote:

Black point compensation is not a part of the ICC specification and is not currently available in any icc library that I know of.

For the record: Black Point Compensation is supported by LCMS - you just supply a flag when building the transform...

All the best, --
Alastair M. Robinson