[RFC 0/1] Color manager calibration protocol v1

[Sebastian Wick]

On 2019-04-16 12:45, Pekka Paalanen 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?

I had pretty much the same question. The key point here is that an ICC
profile only describes the color space of the output which means that
white is whatever the code value 1,1,1 is and black is whatever the code
value 0,0,0 is. If you want/need to have a specific white-point the
profile on it's own is not enough, you have to calibrate the monitor (or
anything else in the chain really, a plane's or connector's
gamma/degamma/ctm, a shader) in a way that the code values correspond to
the specific color. That's typically done automatically in the
calibration/profiling software by modifying the vcgt and measuring the
result.

The resulting curve is saved in the ICC profile in the vcgt tag which is
officially not part of the standard but you basically have to support
it. The compositor is supposed to set the vcgt (in KMS terminology the
gamma LUT of the connector) to the value in the ICC profile.

I think the real question here is if we actually want to modify the vcgt
or if we want to ensure it's set to identify and then let the client
apply the LUT on its own to the color triplet.

Generally I would prefer if the protocol doesn't leak any hardware
specifics like the connector's gamma LUT so that the compositor can
chose to map the color pipeline to all available hardware (shaders,
connector degamma, CTM, gamma, plane degamma, CTM, gamma) as it sees
fit. I'm not sure how much it will impact the precision though.

> 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".
> 
> 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.)
> 
> 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?
> 
> 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?
> 
> 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.
> 
> 
> Thanks,
> pq
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel