Re: Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux