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

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 

Gimp-developer mailing list

Reply via email to