[RFC 0/1] Color manager calibration protocol v1

[Erwin Burema]

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)

> 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)

> 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.

> 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.

> 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.

> 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)

>
> Thanks,
> pq

Hope this helps!