On 02/08/2010 07:07 PM, yahvuu wrote:

From the User Scenarios [1], i'd like to pick "Creating Original Art", short name: "create a collage". This seems to be the clearest case, and perhaps the others can be modelled after this one.

Compositing several images into one image requires that all parts have the same color space. The work is saved as XCF.

Interestingly, from this follows that the working color space is not a preference item, but a property of the image (XCF). Instead, the _default_ image's color space is a preference item. The color space should be set by choosing a template or from the Image->Mode menu.

For collage work, 'open as layers' can safely auto-convert to working color space: if a to-be-imported image requires manual color space adjustment, it can be opened as an image on its own, be converted and then just be dragged to the collage. So dragging layers between images should silently auto-convert, too.

This problem was observed in the excellent GIMP 2.6 review by Ars Technica:

"GIMP is nearly flawless in its color handling, but there is one problem. It forgets to convert copy and pasted image content."

http://arstechnica.com/features/2009/01/gimp-2-6-review.ars/2

Somewhat related, why is 'color management' available as a display filter? The name suggests it's a filter between image and monitor, so at most the monitor profile(s) may be chosen here.

As far as I know this is just an implementation detail leaking out in the UI: color managaing the viewing of an image is handled internally through a display filter.

Regards, Martin

On 02/12/2010 04:55 PM, yahvuu wrote:

Hi,

here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png

I believe number 1 is incorrect:
All images in GIMP will have a color profile. This will either be the implicit sRGB profile, or some explicit profile. Similarly, in the case where the monitor has no explicit display profile, we send it RGB on the assumption that it mostly conforms to sRGB.

More specifically, that means that everywhere we display an image will be color-managed, even if that image isn't explicitly tagged with a profile. Color-related tools (the color picker comes to mind) should always function relative to the color profile of the image, be it explicit or implicit. This may spell some interesting changes for Curves and Levels down the line; I'm not sure.

For 2, an image that, when imported, does not have any explicit color profile information will be exported without saving any explicit color profile information (unless an explicit color profile was added). I also do not understand why 2a and 2b are separated.

--xsdg

On 02/12/2010 06:27 PM, Omari Stephens wrote:

On 02/12/2010 04:55 PM, yahvuu wrote:

Hi,

here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png

I believe number 1 is incorrect:
All images in GIMP will have a color profile.

People will want to create unmanaged images without a color profile for use on the web for example, so we need to handle images with no color profile attached. I think introducing the conepts of "implicit profiles" adds unnecessary complexity.

/ Martin

On Fri, Feb 12, 2010 at 8:36 PM, Martin Nordholts wrote:

People will want to create unmanaged images without a color profile for use on the web

That is, if people want to make everyone's lives more difficult, who are we to stop them from doing so? :)

Just make web equal to sRGB as it already is.

Alexandre

On 02/12/2010 05:36 PM, Martin Nordholts wrote:

On 02/12/2010 06:27 PM, Omari Stephens wrote:

On 02/12/2010 04:55 PM, yahvuu wrote:

Hi,

here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png

I believe number 1 is incorrect:
All images in GIMP will have a color profile.

People will want to create unmanaged images without a color profile for use on the web for example, so we need to handle images with no color profile attached. I think introducing the conepts of "implicit profiles" adds unnecessary complexity.

If the user with a weird monitor (wide-gamut, AdobeRGB, or other) has a display profile and opens an image-without-profile, what do we display? We can't apply the display profile unless the image has some source color profile to link to the transform. Hence, we assume sRGB to enable this and other situations to behave as correctly as possible. The sRGB assumption is one what we already make, this change will simply make that assumption a bit more explicit.

In doing so, it allows us to stop special-casing for cases where the image may not have a color profile. We gain uniformity of display logic and a decrease in code complexity by being able to assume the presence of a color profile as an invariant.

And the code itself is trivial: just add a "give_me_color_profile" function which returns icc-profile contents if present, or the sRGB profile otherwise. (with a more-reasonable name, of course).

--xsdg

On 02/12/2010 07:18 PM, Omari Stephens wrote:

If the user with a weird monitor (wide-gamut, AdobeRGB, or other) has a display profile and opens an image-without-profile, what do we display? We can't apply the display profile unless the image has some source color profile to link to the transform.

This is where I suggest we use the working space color profile, although always using sRGB would work too in the scope of this discussion. Yes, in order to display the image we need to assume a color color profile, but the way I think this is different from thinking about the image as having an implicit color profile.

In doing so, it allows us to stop special-casing for cases where the image may not have a color profile. We gain uniformity of display logic

> and a decrease in code complexity by being able to assume the presence > of a color profile as an invariant.

We need special casing either way, it's just a matter of where we have it. With your implicit profile strategy, we need a special case in the export code and image property code:

if image.color_profile_implicit() color_profile = null
else
color_profile = image.get_color_profile()

while with my strategy it would be in the display code:

color_profile = image.get_color_profile() if (color_profile == null)
color_profile = gimp.get_working_space_color_profile()

Since we want to support working with non-color managed images it is more logical to handle images with no associated color profile than to handle images with implicit color profiles.

"Images always have an associated color profile" is by design not an invariant.

Regards,
Martin

On Fri, Feb 12, 2010 at 11:55 AM, yahvuu wrote:

here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png

What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does "monitor profile" take this into account?

I think my question is: Is X handling the colorspace or are profiles being applied on individual pixel regions? Is this even supported or is there something else I'm not understanding at a very basic level?

Thanks, Chris

On 2010-02-09 19:52, Martin Nordholts wrote:

"GIMP is nearly flawless in its color handling, but there is one problem. It forgets to convert copy and pasted image content."

Also don't forget that the various color picker/selectors aren't color managed at the moment, so selected colors (FG/BG colors) will look differently when painted on a color managed image.

On Sat, Feb 13, 2010 at 8:59 AM, SHIRAKAWA Akira wrote:

On 2010-02-09 19:52, Martin Nordholts wrote:

"GIMP is nearly flawless in its color handling, but there is one problem. It forgets to convert copy and pasted image content."

Also don't forget that the various color picker/selectors aren't color managed at the moment, so selected colors (FG/BG colors) will look differently when painted on a color managed image.

I think color management of individual colors and color selectors is a tricky subject.

* Color selector colors must be stored in a profile independent colorspace (LAB?[1]). This ensures that we can paint any color onto any image and get the right result. Otherwise, we'd have to know the profile that the color was specified in, in order to use the correct color on the image we're painting in now.. which makes color storage way too heavyweight.

* We should consider improving the color history system. MyPaint has one with the property that I think is important here: A color gets added to the history once it is 'read' (in Mypaint's case, when you paint with it;
In GIMP's case, this would also be if it was read via the PDB (ie plugins or scripts)). And the previous color is shown in the color selector side-by-side to
the color you're now adjusting. This makes it easier to do color comparisons, which are pretty important to get right when the previous color and current color are based on different color profiles.

* We should be able to a) specify colors outside of the color profile gamut and b) clip the current color to the limits of the current color profile when painting, previewing etc. b) should probably be a toggle, then it could be quite helpful in quick soft-proofing

* Some of the color selectors are already quite slow (eg. the 'scales' one). We should avoid making them slower if possible.

[1] correct me if I'm wrong here... scRGB might do the job okay, I'm not 100% sure.

On 02/12/2010 10:12 PM, Christopher Curtis wrote:

On Fri, Feb 12, 2010 at 11:55 AM, yahvuu wrote:

here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png

What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does "monitor profile" take this into account?

I think my question is: Is X handling the colorspace or are profiles being applied on individual pixel regions? Is this even supported or is there something else I'm not understanding at a very basic level?

This is an uncommon usecase that would require too much effort to support properly for the small amount of benefit.

X11 has an atom which stores one ICC display profile per screen. We would have to change the display transform depending on which screen each pixel shows up on. This would also mean that we'd have to deal with the case where an image tile is split across two screens.

Again, this would be a lot of code (and, thus, the potential for a lot of bugs). It would be infrequently used (and so the bugs would tend to not be found as quickly). And it would likely slow down our common code paths for little benefit.

--xsdg

On Feb 12, 2010, at 5:42 PM, Omari Stephens wrote:

On 02/12/2010 10:12 PM, Christopher Curtis wrote:

On Fri, Feb 12, 2010 at 11:55 AM, yahvuu wrote:

here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png

What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does "monitor profile" take this into account?

I think my question is: Is X handling the colorspace or are profiles being applied on individual pixel regions? Is this even supported or is there something else I'm not understanding at a very basic level?

This is an uncommon usecase that would require too much effort to support properly for the small amount of benefit.

X11 has an atom which stores one ICC display profile per screen. We would have to change the display transform depending on which screen each pixel shows up on. This would also mean that we'd have to deal with the case where an image tile is split across two screens.

Again, this would be a lot of code (and, thus, the potential for a lot of bugs). It would be infrequently used (and so the bugs would tend to not be found as quickly). And it would likely slow down our common code paths for little benefit.

However, the answer to the base question is "Yes, X and Gtk support that to a very good degree, and all the low-level API's support delivering all the required information".

and "No, X does nothing with the colorspaces. It is left to the application to implement"

It also is more of a per-monitor issue, rather than per-pixel. So one generally will have to deal with a small set of rectangles (two being the most common) to adjust. So it's not *quite* up to the complexity of a purely per-pixel problem.

I also would question the assertion that it is an uncommon use case. Those most likely to be working seriously with images are generally much likely to have two (or more) monitors. They also have a higher chance of caring about color fidelity. And given the direction GIMP is taking in regards to dropping support for the casual users (or whichever wording best describes the current directive on this) I would expect this to be even more in line with GIMP's targeted user base and use cases.

Of course, I've not delved down into the details of GIMP's display code and where to best hook in such display transformations. On the other hand, when I added the initial XICC X11 profile support to Inkscape I had researched this a fair bit, and for Inkscape's display code the extra needed for multi-monitor support is actually rather trivial.

Then again the main consideration does need to go to the pragmatic factors. Given the constraints of that situation (including being the sole engineer doing any and all color work), per-monitor simultaneous profile support was deferred. However, switching profiles as the window moved mainly from one monitor to the next went in, along with dynamic detection and reloading of the profile as they get set or cleared on the current monitor also went in quite easily.

On Sat, Feb 13, 2010 at 5:22 PM, Jon Cruz wrote:

However, the answer to the base question is "Yes, X and Gtk support that to a very good degree, and all the low-level API's support delivering all the required information".
and "No, X does nothing with the colorspaces. It is left to the application to implement"
It also is more of a per-monitor issue, rather than per-pixel. So one generally will have to deal with a small set of rectangles (two being the most common) to adjust. So it's not *quite* up to the complexity of a purely per-pixel problem.
I also would question the assertion that it is an uncommon use case. Those most likely to be working seriously with images are generally much likely to have two (or more) monitors. They also have a higher chance of caring about color fidelity.

I agree; GIMP windows should support color management for individual image windows according to these atoms, absolutely; What it would be of little use to do, is to support showing the SAME image in a single window spanning multiple monitors, with different colormanagement for each monitor-segment of that Single window. As I understand, that is what Christopher was requesting and yahvuu was accurately describing as an uncommon use case, rather than the general case of one image window on this monitor, one on that, and they are color managed differently because of it.

On Sat, Feb 13, 2010 at 5:39 AM, yahvuu wrote:

Christopher Curtis wrote:

What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD?  Does "monitor profile" take this into account?

Following the logic of the diagram, i'd say yes: your case is equivalent to cutting an image into two pieces and printing one piece with an ink jet and the other one with a laser printer.

I don't know that I'd agree with that; the example was not meant as a use-case, just a demonstration of a potential problem. One could argue that you'd need to print exactly this way to take advantage of the specific gamuts (or materials) of each device.

But that's not my point. I would rather suggest this: that GIMP not do colorspace management of the display profile at all, and rely on X to do the right thing even if it does not do so today.

Imagine you are editing some image on one screen and trying to match another image opened in another program on a different head. This other program is not colorspace aware because it's scientific modeling data or whatever so you have this dichotomy. In reality, you may never be able to match the colors because of the different display device gamuts. Maybe you can work around this with 'Acquire Image -> Screen Shot' but isn't that really too burdensome?

You could push colorspace management into GTK, which would be better, but at the end of the day only one thing should be transforming gamuts and I think that thing is X. Perhaps GTK and X can negotiate who's in control so it becomes optional at the GTK level, but then you have the possibility that the transformations are implemented differently and slightly incompatibly. I think it's better to fix the problem once and to do so in a way that all applications can take advantage of it.

It is X's job to render the final display, whether it's local, remote, DPS, Xprt, or whatever else X can render to.

$0.02 Chris

On Saturday 13 February 2010 09:15:13 am Christopher Curtis wrote:

On Sat, Feb 13, 2010 at 5:39 AM, yahvuu wrote:

Christopher Curtis wrote:

What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does "monitor profile" take this into account?

Following the logic of the diagram, i'd say yes: your case is equivalent to cutting an image into two pieces and printing one piece with an ink jet and the other one with a laser printer.

I don't know that I'd agree with that; the example was not meant as a use-case, just a demonstration of a potential problem. One could argue that you'd need to print exactly this way to take advantage of the specific gamuts (or materials) of each device.

But that's not my point. I would rather suggest this: that GIMP not do colorspace management of the display profile at all, and rely on X to do the right thing even if it does not do so today.

Imagine you are editing some image on one screen and trying to match another image opened in another program on a different head. This other program is not colorspace aware because it's scientific modeling data or whatever so you have this dichotomy. In reality, you may never be able to match the colors because of the different display device gamuts. Maybe you can work around this with 'Acquire Image -> Screen Shot' but isn't that really too burdensome?

You could push colorspace management into GTK, which would be better, but at the end of the day only one thing should be transforming gamuts and I think that thing is X. Perhaps GTK and X can negotiate who's in control so it becomes optional at the GTK level, but then you have the possibility that the transformations are implemented differently and slightly incompatibly. I think it's better to fix the problem once and to do so in a way that all applications can take advantage of it.

It is X's job to render the final display, whether it's local, remote, DPS, Xprt, or whatever else X can render to.

$0.02 Chris

I some ways I agree with Chris but the X.Org developers have insisted on an ongoing basis that it is NOT their responsibility to handle color management of the display. If we wait for X.Org to implement CM it will likely never happen.

Hal

On Feb 13, 2010, at 9:42 AM, Hal V. Engel wrote:

I some ways I agree with Chris but the X.Org developers have insisted on an ongoing basis that it is NOT their responsibility to handle color management of the display. If we wait for X.Org to implement CM it will likely never happen.

I'd definitely second this point. I've been in many discussions with several key players in this arena, and when all technical details are explored it does seem to come down to the points that X11 does not and should not deal with color management in these regards and needs to leave it to the individual apps. To get a fully usable system, X11 would require some major reworking, and thus won't be seen any time soon.

Of course, to end up with an optimal workflow for end users, GTK could be adapted to handle a fair bit by itself (and, yes, there is work happening on this at the moment). Toolbars, icons, menus, color selectors, etc., ideally would be color managed by GTK. But whatever "automatic" color management is added to GTK needs to be done in such a way as to allow the "smart" programs (such as GIMP) to hook in and control/override as needed.

On Feb 13, 2010, at 2:39 AM, yahvuu wrote:

In reality, the wall of monitors probably won't work like that as long as GIMP has to manage the windows' colors. As others have said, it is unreasonable to manage split windows at application level.

Well, personally I don't consider it unmanageable at all to have an application manage split windows. Especially with all the detail being presented via GTK on the geometry and positioning of the monitors, this is a fairly trivial matter. That's trivial in the abstract case, of course. The main complication will be in the details of hooking GIMP's display code at the very last moment (since among other things color management adjustments need to be done once and only once and on the final result just before it gets sent to the display).

On Feb 13, 2010, at 12:08 AM, David Gowers wrote:

I agree; GIMP windows should support color management for individual image windows according to these atoms, absolutely; What it would be of little use to do, is to support showing the SAME image in a single window spanning multiple monitors, with different colormanagement for each monitor-segment of that Single window. As I understand, that is what Christopher was requesting and yahvuu was accurately describing as an uncommon use case, rather than the general case of one image window on this monitor, one on that, and they are color managed differently because of it.

Ah, but that is exactly what I was thinking. I know the ancient-of-days workflow was to have one "good" color monitor for the actual images, and a monochrome "control" monitor with the buttons and interfaces to control the software. Over the years I've seen more and more users with two or three good monitors, including gamers and programmers in addition to artists. And I have seen such users have windows with images spanning those monitors very often.

I'd also point out that this single-window-across-multiple-monitors use case is exactly one of the main ones that artists using Macintoshes had been quite fond of pointing out to their "poor cousins" on Windows (when I've seen them do such, it reminds me very much how "real programmers" use Linux). It highlights the fact that MacOS has had good color management built in to the OS for years and years.

On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz wrote:

[...]

does seem to come down to the points that X11 does not and should not deal with color management in these regards and needs to leave it to the individual apps. To get a fully usable system, X11 would require some major reworking, and thus won't be seen any time soon.

Do you have a reference to these discussions? It seems like X *should*, accepting that it may be difficult.

Of course, to end up with an optimal workflow for end users, GTK could be adapted to handle a fair bit by itself (and, yes, there is work happening on this at the moment). Toolbars, icons, menus, color selectors, [...]

I was just going to say here that putting it in GTK could also 'fix' the color selector issues; let me just emphasize that point here.

On a more philosophical note, how does one represent a color that does not exist on a display but does on an output device? Do we make the assumption that the display always has the widest gamut? (I.e: GIMP will never run on a mono/CGA device and print to a CMYK printer.) Is that a concern?

Chris

On Sun, Feb 14, 2010 at 10:03 AM, Christopher Curtis wrote:

On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz wrote:

[...]

does seem to come down to the points that X11 does not and should not deal with color management in these regards and needs to leave it to the individual apps. To get a fully usable system, X11 would require some major reworking, and thus won't be seen any time soon.

Do you have a reference to these discussions?  It seems like X *should*, accepting that it may be difficult.

Imo the video card is the correct handler of these issues. X should just upload an appropriate lookup table (which is functionality already available in X, but doesn't happen automatically). Presumably a multihead video card allows multiple LUTs. From that point of view, it might make most sense for the desktop environment to do the uploading of the LUT(s), since you would probably use it to select and test the profile.

Of course, to end up with an optimal workflow for end users, GTK could be adapted to handle a fair bit by itself (and, yes, there is work happening on this at the moment). Toolbars, icons, menus, color selectors, [...]

I was just going to say here that putting it in GTK could also 'fix' the color selector issues; let me just emphasize that point here.

On a more philosophical note, how does one represent a color that does not exist on a display but does on an output device? Do we make the
assumption that the display always has the widest gamut?

That's tempting but ultimately incorrect, IMO, since most displays approximate sRGB, which only has what ..56% coverage of the visible spectrum? We should only make that assumption when the coverage becomes close to a superset of all other important mediums of reproduction (eg. when scRGB or whatever displays with 90% coverage of visible gamut are common).

Looking at GEGL, the intermediate result of a computation (like mathematically a + b where a,b are layers) may be >1.0 or
I guess we need some way of depicting exposure stops independently for the R,G,B levels and also of setting them.

To clarify: I mean that the color RGB 1.0, 1.0, 1.0 would have exposure 0,0,0; the color RGB -1.,0.,-2. would have exposure -1, 0, -2; RGB 2,2.5,2.8 would have exposure 1, 2, 2 etc.

David Gowers wrote:

Imo the video card is the correct handler of these issues. X should just upload an appropriate lookup table (which is functionality already available in X, but doesn't happen automatically). Presumably a multihead video card allows multiple LUTs. From that point of view, it might make most sense for the desktop environment to do the uploading of the LUT(s), since you would probably use it to select and test the profile.

Calibration != Profiling

While most cards have per channel Luts, none will have per rendering context 3D color transforms (although it can be simulated using 3D texture lookups). Rendering context is usually somewhere up the rendering stack though, not something the hardware will be directly aware of. (It's rendering context because the transform depends on the source colorspace & intent as well as the display profile. In general it's not a 3x3 matrix transform either.)

Graeme Gill.

Christopher Curtis wrote:

On a more philosophical note, how does one represent a color that does not exist on a display but does on an output device? Do we make the assumption that the display always has the widest gamut? (I.e: GIMP will never run on a mono/CGA device and print to a CMYK printer.) Is that a concern?

There's nothing special about this. In general any transformation from one colorspace to another has to cope with different gamuts. You simply choose how to handle it (ie. clip, perceptually map, etc.) by choosing an intent.

It's not unknown to have a mode in an image editor that compresses the gamut of the source so that a very large gamut image can be viewed on a limited gamut display without loosing the ability to be able to see all its color variations. Naturally it will look a lot duller than it will when displayed on the intended device.

Graeme Gill.