Kai-Uwe Behrmann wrote: > Am 19.06.2013 04:52, schrieb John Kåre Alsaker:
>> Calibration tools will require explicit privileges in order to do >> their job. Using the full-screen color space won't be enough since >> video card gamma correction can apply to it. I also wonder if we can >> just remove the VCGT tag from the ICC profiles to indicate that the >> client doesn't have to correct for that, but I'm not sure that anyone >> would use the tag anyway. Display profiles with a VCGT tag won't reflect the display behaviour if you disregard the VCGT, thereby making it useless. > Sending a faked "no VCGT" profile is slightly indirect, but might work out. > That needs to > be documented very well. A calibration/profiling program needs then to set > the VCGT-less > profile to the output in question and then displays its measurement patches > on a surface > without colour conversion. Things like ArgyllCMS dispcal & dispread expect to be able to read and write the VideoLUTs, and I'm not aware of too many other tools currently for creating color profiles on *nix systems. VideoLUT access is both part of the expected video display workflow, and an important mechanism for getting around frame buffer depth limitations - many systems have an 8 bpc frame buffer but a 10 or more bpc VideoLUT entry depth. Particularly with wide gamut displays, you need all the bit precision you can get when dealing with the raw device values, and such extra precision has been available for many, many years (we had it available on our X terminals circa 1990 for instance.) > To deprecate the VCGT tag is not so easy, as we have lots of legacy profiles > around from > windows / osx software and directly from vendors. Ignoring the VCGT tag is no > option, > modifying the profile by baking the VCGT tag into the ICC standard > colorimetric > descriptions might be a workaround inside a CMS. Yes, this is a possibility. It doesn't solve the bit depth issue though. OS X "solves" the VideoLUT sharing problem by using the installed display profile VCGT as the system default curves, while any application can set it's own VideoLUT values when it's running, and it's changes are undone when it terminates. (This can be rather painful when testing and setting up though, as there are times when you want to be able to simply load a set of persistent calibration curves.) I'm not sure if it does uses a last set policy, or a stack so as to undo VideoLUT changes in order. I'm wondering what consideration there are for transition and support of established systems such as X11. ie. We should be aiming for the current set of X11 color management tools to just work when X11 is running on top of Wayland, not have things such as XRandR simply stop working. Graeme Gill. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
