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 Saturday 13 February 2010 09:15:13 am Christopher Curtis wrote:
> On Sat, Feb 13, 2010 at 5:39 AM, yahvuu <yahvuu@xxxxxxxxx> 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
_______________________________________________
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