On 2019-04-16 12:45, Pekka Paalanen wrote:
On Sun, 14 Apr 2019 12:57:47 +0200
Erwin Burema <[email protected]> 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
