color management spec
Hal V. Engel
hvengel at astound.net
Fri May 30 19:29:17 PDT 2008
On Friday 30 May 2008 09:53:38 Tomas Carnecky wrote:
> Alex Deucher wrote:
> > I think you may want to start with a basic app to load ICC profiles
> > and properly set the LUTs per crtc using xrandr, then move onto the
> > per-window stuff. That may be part of your plan already.
> IIRC the LUTs can be incorporated into ICC profiles. And we agreed that
> that would be preferred over setting the LUTs using xrandr.
To clarify XRandR 1.2 has an API for getting LUT data (BTW is this working?)
and setting the video card LUTs but it is up to some other application to set
the LUTs correctly since XRandR is color management unware (as it should be).
There is an application named Oyranos that is intended to be a color
management configuration management system that can be used in conjuction
with xcalib (a LUT loader application) to manage both the _ICC_PROFILE X11
atom and the loading of the video card LUT using the VCGT data from the
profiles. Oryanos also allows users to configure other aspects of how they
want color managed on their systems. This combination is not mature and
works on some setups but not others. It is currently missing XRandR 1.2
support in both pieces. I think XRandR 1.2 support is on the TODO lists for
the authors of these projects. XRandR 1.2 support is only really an issue
for xcalib since it is the application that handled LUT loading which is an
important but small piece of this part of the color management puzzle.
In addition, the ArgyllCMS project has started looking at both the
configuration management issues related to the _ICC_PROFILE X11 atom and LUT
loading (actually more general LUT management issues with include LUT
loading) on XRandR 1.2 systems.
> When you set
> the LUT in hardware you have the issue of applications resetting your
> LUT (There is an application, I don't remember which, that uses the LUT
> and when it finishes it resets it to linear instead of what it was before).
This is an issue that needs to be corrected but it is outside of the scope of
As I pointed out above others are looking at _ICC_PROFILE X11 atom and LUT
loading issues and this is not part of Tomas' project. To add some
clarification LUT loading is a calibration issue, X11 atoms are a
configuration issue and Tomas' project is dealing with using charaterization
data (IE. ICC profiles) to display graphics on a correctly configured and
calibrated display and these last two things can be handled by Oryanos and/or
ArgyllCMS for many systems.
> Loading display profiles into xrandr output properties should be done by
> the session (gnome-session or whatever kde uses). There are already
> tools to load the profiles, but you have to do that by hand, it's not
> automated. And that part of desktop color management has completely
> different issues, like where and how to store the configuration etc.
There is a KDE specific OpenICC GSoC project that will likely be looking at
this set of issues in more detail. The intension is to create a generalized
framework that is based on Oryanos and xcalib with a KDE specific front end
that would serve as a model implementation. The hope is to eventually have
this integrated into KDE 4.x and that other DE's would create DE specific
front ends using the same underlaying configuration data, libraries and
utilities. This is of course broader than just how to configure display
color management since this will also have configuration settings for other
hardware types such as printers, cameras and scanners as well as color
management policy settings and defaults but these other devices and settings
are outside of the scope of this list.
In addition, I am not sure exactly what a session is since I don't run GNOME
or why that would be the correct place to be loading the video LUT or setting
the X11 _ICC_PROFILE atom. Although it could happen at that level I believe
these things should happen after X11 is running but before KDE or GNOME (or
other DEs/window manager) is started if there are valid system wide settings
More information about the xorg