[RFC 0/1] Color manager calibration protocol v1

[Erwin Burema]

On Tuesday, 16 April 2019, Pekka Paalanen wrote:
> On Tue, 16 Apr 2019 13:11:06 +0200
> Erwin Burema <e.burema at gmail.com> wrote:
> 
> > On Tue, 16 Apr 2019 at 12:45, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > >
> > > On Sun, 14 Apr 2019 12:57:47 +0200
> > > Erwin Burema <e.burema at gmail.com> wrote:
> > >  
> > > > Without a way to calibrate/profile screens an color management
> > > > protocol looses a lot of its value. So to add this missing feature I
> > > > wrote the following protocol.
> > > >
> > > > The idea is that the calibration/profiling SW only sets the RGB
> > > > triplet and then the compositor is responsible to draw a rectanglular
> > > > region on the selected output screen, since not all calibration tools
> > > > will be at the center of the screen a user should be able to modify
> > > > the placement of this rectanglular region. Unless specified the
> > > > monitor profile (if any) should not be applied but the GPU curve
> > > > should, currently to set a new curve the calibration tool should
> > > > generate a new ICC profile with the wanted curve in the VCGT tag (I
> > > > am not sure if this is the best option but would make the most
> > > > universal one). In the end after profiling the last uploaded ICC
> > > > could then be saved (although a compositor is not required to honor
> > > > the request in that case it should send the not saved error). If the
> > > > compositor doesn't save or the connection with this protocol is
> > > > broken the compositor should restore previous settings.  
> > >
> > > Hi,
> > >
> > > I only took a very quick glance, but I do like where this design is
> > > going. I'll refrain from commenting on wl_surface vs. not for now
> > > though.
> > >
> > > Forgive me my ignorance, but why is the "GPU curve" needed to be a
> > > custom curve provided by the client?
> > >  
> > 
> > Because the GPU LUT/curve is the calibration; it is mostly used to
> > smooth out non-linearity in the display (some expensive display have
> > the possibility to upload this curve to the display instead in which
> > case it is sometimes called a calibration curve)
> 
> Hi,
> 
> if you are only showing one solid color at a time, why does
> non-linearity need addressing with the "GPU curve" instead of just
> computing that into the color values the client sets?
>

You display only one color at the time since that is what the colorimeter/spectrometer can measure, to calculate the curve you would use a full gradient which had been measured over time.

 
> The possibility to load the "GPU curve" into the monitor instead of
> doing it in the display hardware is probably the reason, since inside
> the monitor the LUT output is not limited by the wire bitness.
> 
> > > My naive thinking would assume that you would like to be able to
> > > address the pixel values on the display wire as directly as possible,
> > > which means a minimum of 12 or 14 bits per channel framebuffer format
> > > and an identity "GPU curve".
> > >  
> > 
> > Not sure where you get 12 or 14 bits since most displays are still 8
> > currently (well actually a lot are 6 with dithering but you can't
> > actually drive them with 6bpc), and yes firstly an identity curve will
> > be need to applied, in practice the calibration process is iterative
> > (I believe) so over time you will need to upload/set different curve
> > (e.g. start with an identity curve, refine it, use the refined curve,
> > refine that, use the next curve, etc until it is below a certain
> > error)
> 
> 12 or 14 came from your protocol spec.
>

That is the display color depth and has no direct relation to tje cruves
 
> Ok, you start with an identity curve and iterate. Why only the "GPU
> curve" instead of a "full" color correction transformation?
>

Since we are trying to setup the "GPU curve" in this case a full transform would only get in the way. 
> > > Is the reason to use the "GPU curve" that you assume there is a 8 bits
> > > per channel framebuffer and you need to use the hardware LUT to choose
> > > which 8 bits wide range of the possibly 14 bits channel you want to
> > > address? (Currently a client cannot know if the framebuffer is 8 bits
> > > or less or more.)
> > >  
> > 
> > Currently not assuming anything about the curves bitnes, so not sure
> > where you got that from? The curve should be set with the ICC vcgt tag
> > I am pretty sure that supports higher bit depths then 8, if you have a
> > better idea to be able to set the video card LUT I would like to hear
> > that.
> 
> If you do not assume anything about bitness, why does the protocol spec
> have bitdepth? Is it the per-channel bitdepth of the framebuffer, the
> wire, the monitor, the minimum for the whole pixel pipeline, or?
>

Maximum of whole pixel pipeline

 
> Any LUT configuration that is not identity will only reduce your
> precision to program different pixel values into the monitor, which is
> why I'm wondering why the LUT is not simply identity for measurements.
> This is especially true if you do not assume that the bitness on the
> wire is higher than the framebuffer's, or that the bitness in the
> monitor is higher than the wire if the LUT is loaded into the monitor.
> 
> It's a mathematical fact, caused by having to work with integers. If
> the LUT input and output have the same bitness, and the LUT is not
> identity, then necessarily you will have some input values that do not
> differ in their output values and some output values you cannot
> reach from any input values.
>

For verification and profiling the LUT needs to be applied.
 
> > > Your protocol proposal uses the pixel encoding red/green/blue as uint
> > > (32-bit) per channel. Would it be possible to have the compositor do
> > > the LUT manipulation if it needs to avoid the intermediate rounding
> > > caused by a 8 bit per channel framebuffer or color pipeline up to the
> > > final LUT?
> > >  
> > 
> > Not sure what you mean here, the values should set should be displayed
> > as directly as possible to the screen with the exception of the
> > application of the videocard LUT, now a compositor might choose to not
> > use the videocard LUT for reasons (very simple HW that doesn't include
> > a LUT comes to mind) in which case it should apply the calibration
> > curve itself.
> 
> It is about having to use integers where the bitness limits us to
> certain precision, see above.
> 
> You have 32-bit values in the protocol. Those get mapped into a
> framebuffer which might be effectively 5, 6, 8, 10, 12, or 16 bits per
> channel. Then assuming all hardware color manipulation has been turned

I tried to specified that the with a n-bit pipeline only the n least significant bits of the uint should be used. The intent is to only send 8 bit data over an 8 bit piline and the same for 10, 12 or 14 bits 

> off except the final "GPU curve" LUT, the framebuffer value will be
> converted into a LUT input value, a LUT output value is looked up and
> maybe interpolated, then truncated back to LUT output bitness. Then it
> gets pushed into the wire which has its own bitness, before it reaches
> the monitor, which may convert that again to anything from 5 to 14 bits
> per channel for the panel and maybe dither.
> 
> The precision you will get is the lowest bitness found in that path.
> Except, depending on at which step the "GPU curve" is applied, you
> might be able to use that to address more bits than what the lowest
> bitness along the path allows, as long as the lowest bitness occurs
> before the LUT.
> 
> Do you mean that calibration measurement tools do not use nor expect
> such tricks?
>

Dithering yes most tools integrate, some of the other tricks are compensated for in software
 
> > > If such "GPU curve" manipulation is necessary, it essentially means
> > > nothing else can be shown on the output. Oh, could another reason to
> > > have the client control the "GPU curve" be that then the client can
> > > still show information on that output, since it can adjust the pixel
> > > contents to remain legible even while applying the manipulation. Is
> > > that used or desirable?
> > >  
> > 
> > Calibration/profiling is a rather time consuming process where a piece
> > of equipment will be hanging in front of your screen, so not being
> > able to display much at that time won't be to much of a problem, so no
> > doesn't have much to do with being able to display stuff.
> 
> That's the opposite of what has been said here before. Exactly because
> it takes so long, the measurement apps needs to be able to show at
> least a progress indicator. This was the objection to my past hand-wavy
> proposal of a measurement app hijacking the whole output.
>

We don't need the whole output to display the color patch so we can definitely show a progress bar as well but the display itself will be somewhat not useable during the calibration
 
> > > Btw. how would a compositor know the bit depth of a monitor and the
> > > transport (wire)? I presume there should be some KMS properties for
> > > that in addition to connector types.
> > >  
> > 
> > Huh, this surprises me a bit would have expected KMS to know something
> > about the screens attached and which bit depths are supported (10bit
> > capable screens (non-HDR) have been around for quite some time now)
> 
> We know the bitdepth of the framebuffer since the compositor picks that.
> 
> I do not recall seeing anything about the wire, but I also never really
> looked. Display hardware (in the computer) probably has at least the
> same precision as the wire, if not more, at least in identity
> transformation.
> 
> Note, that parsing EDID might tell you the bitness of the monitor
> somehow, but it will not tell you the bitness of the wire, because I
> think different transports (HDMI, DP, DVI-D, ...) each might support
> more than one bitness. Unless the monitor only supports one bitness.
> 
> But at least with YUV on the HDMI wire, I recall there being different
> pixel formats. Less bits, more fps.
>

Mmh that complicates things, although this kind of stuff should mostly be used for RGB signals. I think directly pushing YUV over the cable is mostly for HW media players.
 
> 
> Thanks,
> pq
>

Sorry for the short reply had to type this on my phone.

-- 
Sent from my Jolla