On Thu, Mar 25, 2010 at 12:27 PM, Richard Hughes <[email protected]> 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 _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
