Re: Full screen color management

[Pascal de Bruijn <pmjdebruijn pcode nl>]

On Thu, Mar 25, 2010 at 12:27 PM, Richard Hughes <hughsient gmail com> wrote:
> First a little introduction if I may. if you're easily bored please
> skip to the last paragraph.
>
> An image is usually generated with a source profile of the devices
> used to generate it, that's a lump of data that describes what kind of
> "red" is actually red. This is encoded in the ICC profile, which is
> normally in the image metadata. Images without metadata are usually
> assumed to be sRGB.
>
> A color server usually runs at session start and sets the _ICC_PROFILE
> atom on the XRandR output (or root window) of the screen. This is
> either the manufacturer generated profile, or the profile that the
> user has lovingly created. The color server also sets up the color
> lookup tables (gamma tables) if required.
>
> An application that does "early color binding" takes the source
> profile (e.g. "Hughsie's Nikon D60") and the destination profile ("T61
> IBM Internal Panel") and converts one color gamut to another using
> something like LCMS on Linux, or ColorSync on OSX. This means the
> "red" that you saw in the viewfinder matches pretty much what you see
> on the screen, modulo how crappy your laptop LCD panel is. It then
> tags the Window which is displaying the image with an atom so that the
> next part works (read on...). This only works for applications that
> care about color, and only works if the window is entirely on one
> output (as different outputs might have different output profiles).
>
> A "whole screen" color manager is normally an optional plugin to a
> compositing window manager. There is a pretty hacky proof of concept
> plugin written for compiz, but that's doing far more stuff than I'm
> proposing here. It tries to convert the whole screen to the
> destination gamut, without affecting windows that have already been
> early-bound. It can detect windows that should be ignored using the
> atom that has been set on some windows (possibly none, or typically
> one) and assumes the rest is sRGB and converts this to the destination
> (monitor) profile.
>
> Now, you might be wondering why the last part is required, as most
> people say that LCD's are supposed to be sRGB anyway. Well, I would
> disagree, and will disagree more as the years pass. More and more LCD
> panels are being sold that are "wide gamut" and therefore can display
> colors well outside of sRGB. Panels (like this T61) are also very much
> smaller than sRGB and need to be corrected as best we can. On a wide
> gamut monitor 100% red is piercing red (the sort of piecing red that
> hurts your eyes) and needs to be controlled. Of course, we want to be
> able to use the wide gamut features for photographs and HD movies, but
> we really don't want to be color correcting window borders and [x]
> controls.

Yes, this is very true...

sRGB is really a one-size fits none solution :)

> If you've read this far, I'm impressed, and you're probably in the
> minority. Well done.
>
> What I'm proposing is a plugin for mutter that uses lcms to color
> convert the whole screen, masking out the color-corrected regions.
> Using mutter allows this to work with GNOME 2 and GNOME 3, and mutter
> also seems to be the sweet-spot for this kind of display correction
> without putting ICC profile decoding and gamut mapping into the X
> server.
>
> Is full screen color correction something that you think is a good
> idea, and also would you allow me to create the required hooks in
> mutter-plugin.h to make this possible?

It's probably a good idea, however I do wonder how this will affect
slow machines... netbooks anybody? Not that most folks will be doing
graphics work on a netbook...

<ignorant>What's mutter?</ignorant>

Regards,
Pascal de Bruijn