color calibration and xvideo (xv)

[Hal V. Engel]

On Wednesday 22 August 2007 12:02:00 Alex Deucher wrote:
> On 8/22/07, Hal V. Engel <hvengel at astound.net> wrote:
snip
> > The gamma setting code seems a little closer in that they appear to be
> > table based with slope and offset pairs.  But again the gamma tables are
> > hard coded so user software can not alter the values and second there is
> > no way to set the gamma tables for individual color channels (IE. there
> > is only one table for all three channels).
>
> Heh... patches welcome.  I'm not really much of an expert when it
> comes to color calibration.  I'm not sure what the best method is for
> calibrating overlays.  I think most (all?) vendors keep the graphics
> plane and the overlay plane(s) separate so they can be adjusted
> individually.  

Here is the source of the problem.  The device calibration is separate from 
adjustments that are made to the content before going to the display device.  
Calibration is to get the device into a known or defined state.  How can you 
make adjustments to the overlay plane(s) that are meaningful if the device it 
is displayed on is in an undefined state?  Sorry this horse has been beat to 
death.

> Plus the overlay can be sourced to either crtc (or 
> directly to an output in the radeon case) so you might have different
> calibrations on each output.

If the LUTs were respected then this would take care of itself since a proper 
calibration will set the LUTs for each display with custom curves.  But you 
are right if the LUTs are bypassed then the gamma/transfer curves that XV 
uses would have to be different for each physical display to compensate for 
not using the LUTs.  But how this would be done is clearly non-trivial.

snip

> All older video hardware uses an separately controlled overlay at this
> point for Xv.  Some of the newer hardware uses shaders or YUV textures
> to implement Xv.  These will respect the crtc's LUT setting because
> the the data actually gets written to the main framebuffer and scanned
> out along with the rest of the desktop.  Overlays are stored in
> separate framebuffer and the hw switches between the graphics plane
> and the overlay during scan out.

This appears to be a problem with legacy hardware and drivers and newer 
hardware/drivers such as the current Intel driver are using the LUTs so I 
think this is mostly a non-issue if users know what hardware uses the LUTs.  
The only thing I think needs to happen is to document which hardware/drivers 
have the issue so that users who wish to run calibrated displays know which 
hardware and/or drivers to avoid. 

snip

> While I can see the need for setting the 
> the overlay to match the crtc LUT, I also think users would like to be
> able to tweak the overlay separately (for example if they are viewing
> crappy source material that is too dim or bright, etc.) without
> affecting their whole desktop.  

I agree.  As a user I want video play back to use my calibrated LUTs but I 
also want to be able to make adjustments in the playback material for things 
like underexposer/overexposer/bad color balance.  These are two separate 
issues that should have different solutions.

> You guys that are working on the color 
> management stuff need to let us know what you need from the windowing
> system.
>
> Alex

I also agree about the need for better feedback to the windowing system folks 
from the color management community.  I firmly believe that if we (meaning 
the color management folks) were doing a better job in that regard that X 
would have much better CM support than it currently does.  (as a side note 
there has already been a significant amount of CM specific work done - one 
example is the gamma table code in randr 1.2).  So the lack of CM specific 
requirements is clearly the fault of the color management community.  I did 
not intend to find fault with those who are working on the windowing system 
and in fact I think that many of you are trying to do the right thing with 
respect to CM but we are not providing you with enough information.  So if my 
previous posts seemed to imply that those working on the windowing system 
were at fault please accept my apologies as that was not my intention.

For precisely this reason, ten days ago, I proposed on the OpenICC email list 
that we should be using the OpenICC wiki pages on freedesktop.org as a 
resource to start documenting these types of things.   The response was a 
little underwhelming but no one objected to the idea.  Your comments above 
make it clearer that something like this is needed and I think I will start 
working on this in the next few weeks.  It may take some time before there is 
much that is useful to you there.  I personally think that at this point the 
color management folks can do a lot more for improved support by the 
windowing system if we work on documenting our requirements then almost 
anything else we can do.

Hal