Color management (UI perspective for GIMP 2.8)

hi all,

this is work in progress, mostly in analysis stage and a bit chaotic,
but there are already some conclusions which might be worth discussing.

any comments appreciated,
yahvuu



>From the product vision follows a tightly coupled workflow as default,
where each file should have a profile embedded: a few bytes overhead are
a nuisance, but wrong colors can be a quite expensive error.
Notable exception is save-for-web.

Which import/export behaviour is desired, depends more on the workflow
than on the file formats. So it's rarely the import/export plugins
which can decide properly. However, following the hi-fi attitude from
the product vision, an overall rule for export is:
if in doubt, embed a color profile.



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

Other observation: the Assign/Convert commands are correctly placed in the
Image->Mode menu [2].


Dealing with invalid profiles (in order of preference)
- do nothing: an experienced user just _sees_ that something went wrong
- red message in status bar, clicking it reveals backlog with
detailed problem description
- image overlay on top: "color space problem on import. click to see details",
like Firefoxen's popup-blocker does (or stackoverflow.com to advertise its FAQ).
- definitely not a pop-up



Bug 320447 - fast switching between "color managed display" and "softproof"
In future this can be solved very elegantly with a projection screen,
analogous to the printing press projection and index color work [3].

For 2.8, the 'display filters' seem just right for this,
so i'll second the approach taken in the bug report.

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.


Export:

There's no explicit save-for-web in 2.8, so a drop-down selector
in the export dialog should do, which defaults to 'embed profile'.

(thanks for reading)


[1] http://gui.gimp.org/index.php/User_Scenarios

[2] off-topic: and for 3.x we should be rid of that Image->Mode menu.
With floating point processing, it is very tempting to
fix the working space to some full-gamut color space, like scRGB or
betaRGB (http://www.brucelindbloom.com/index.html?BetaRGB.html).

[3] http://www.mmiworks.net/eng/publications/2009/06/gimp-squaring-cmyk-circle.html

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 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
<shirakawa.akira@gmail.com> 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.

David Gowers wrote:
> * 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 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

simpler:

Color selectors give an overview of available colors and
display a few selected colors, namely fg/bg color plus history.


The range of available colors changes with the current working color space,
and the color selectors should reflect that. E.g. the colors inside the
'triangle' should change according to current working space.

The selected colors however, should be transferable between images and
thus need to be stored in an absolute color space. Gamut warnings
indicate when they are outside the current working space.
(They may well be outside of display gamut as well..)


everything IMHO,
yahvuu

Hi,

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

While not yet a set of uses cases, i think these diagrams will
be useful when discussing the use cases.

Please let me know in case you spot errors or think i missed
an important configuration.


regards,
peter

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

hi, and thanks for the feedback


Omari Stephens wrote:
> I believe number 1 is incorrect:

First thing to note is that i should have added a legend:
- grey: device-dependent colors, plain RGB values, no profile info available.
- orange: colors from an absolute color space

Picture 1) was intended to show the situation before color management was
introduced: the RGB data gets exchanged between devices without any
conversion. The resulting colors are unknown as none of the devices
has been profiled or calibrated.


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

oh, i meant to talk about the principal configurations / UX options.
I hope that there's no conflict with implementation issues by now.
I'm working on a set of use cases to use as a decision aid...


> I
> also do not understand why 2a and 2b are separated.

the goal was to make explicit that importing unmanaged data
and creating unmanged data on export might be unrelated.

For example, 2b) might be a photographer that opens a ClayRGB file from
his archive and exports a JPG without any profile information, for web use.


regards,
yahvuu

On Fri, Feb 12, 2010 at 11:55 AM, yahvuu <yahvuu@gmail.com> 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 02/12/2010 10:12 PM, Christopher Curtis wrote:
> On Fri, Feb 12, 2010 at 11:55 AM, yahvuu<yahvuu@gmail.com> 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<yahvuu@gmail.com> 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 <jon@joncruz.org> 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 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.

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.

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.

However, in those places where color is really important,
a second monitor means additional calibration cost
and an additional potential source of error, i guess.


regards,
yahvuu

On Sat, Feb 13, 2010 at 5:39 AM, yahvuu <yahvuu@gmail.com> 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 <yahvuu@gmail.com> 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 Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz <jon@joncruz.org> 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 <ccurtis0@gmail.com> wrote:
> On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz <jon@joncruz.org> 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 <0.0, and we
must be able to differentiate those areas ,in the image and when we
are eyedropping.
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.

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