Re: Full screen color management

On 25 March 2010 13:26, Andrew Lutomirski <amluto gmail com> wrote:
> This sounds like a great idea, but if I understand it correctly, I
> think that a small change could make it even better.  In your model,
> windows are either untagged (late color binding) or tagged as
> early-bound.  If windows were instead tagged with a color space (no
> tag = sRGB, and maybe reserve a special tag "native" that does exactly
> what your early-binding tag does), then we get a few benefits:

What you describe is essentially what the net-color spec is trying to
do, and has had some success with oyranos, although the mechanism for
updating is pretty, well, complex.

> 1. Programs displaying images in a wider color space than sRGB can
> correctly span two outputs with different profiles, assuming that the
> compositor is smart enough to draw them correctly.  This would be nice
> for video on two displays.

With this, the color aware program needs to know if the compositor is
installed (and enabled) to actively avoid using lcms and doing the
conversion itself. I'm not sure we can enforce the use of a late-bound
approach as not everybody wants the performance penalty of a whole
screen correction. I guess it's about where you draw the line in the
sand. Each way of doing it has advantages and drawbacks.

> 2. Programs that are too lazy to detect when they are dragged from one
> output to another can simply tag themselves with the correct color
> space and let the compositor deal with it.

Potentially this means uploading quite a bit of data to the xserver.
Some ICC profiles can be in the megabytes, especially for CYMK
profiles. But sure, it would be an interesting way of doing things.

> 3. The compositor will probably be much faster than LCMS, since it
> ought to use a hardware shader to do color conversion.  This means
> that some program displaying, say, an AdobeRGB image (a much wider
> gamut color space than sRGB for those non-color-inclined among you)
> can just set that tag and get amazing performance.  (This is
> especially true for low-end computers, where performance is more
> likely to matter.)

Sure, I agree it would be much faster. The question remains if this is
something mutter should and can provide.


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