On Sat, Feb 13, 2010 at 5:39 AM, yahvuu <yah...@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.
Gimp-developer mailing list