[RFC PATCH 1/6] Add colorcorrection protocol
John Kåre Alsaker
john.kare.alsaker at gmail.com
Thu Apr 3 03:06:34 PDT 2014
On Thu, Apr 3, 2014 at 11:12 AM, Niels Ole Salscheider
<niels_ole at salscheider-online.de> wrote:
> Zoxc did not like the way I handle the "uncorrected" case because it is a bit
> ugly and breaks blending in the uncorrected area. Instead of using a mask to
> opt-out from color management, he suggests to just attach the output color
> space to the surface so that it is converted from output to blending and again
> to the output color space. This however makes it necessary for the client to
> know its output and might cause a loss of precision (which might not be too
> bad in the 16 bit LUT case). What do you think?
I'm not sure there's a use case for having a uncorrected area.
Calibration will require
a separate API to reset the GPU LUT. Also my plot was to tag a surface
as "uncorrected"
and let the compositor convert it from the output color space. The
compositor could also
just copy the content without conversion when the surface is
unobscured, removing
rounding errors, but as I said I don't see a use case for it.
>
> Unfortunately, I have not been aware that Zoxc is also working on color
> management before writing these patches. I do not know what his plans are for
> his code but he seems to have some useful patches...
My plot is to coerce Kristian to merge them at some point.
>
> Regards,
>
> Ole
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Since you all seem keen to discuss a color correction protocol, here's
my WIP one:
https://github.com/Zoxc/weston/blob/cms/protocol/cms.xml
In particular I'm wondering on what meaning should be had when one or
both of compositing_color_space
and color_space is pass-though/ignorant in
wl_cms_output_info.output_color_space.
We might want to indicate that:
- The compositor doesn't do color correction and the output has a
profile (so clients can do color correction themselves)
- The compositor doesn't do color correction and the output doesn't
have a profile (we're screwed, should clients assume sRGB?)
- The compositor does color correction and the output doesn't have a
profile, but we have a compositing space (should the compositor assume
the output is sRGB here and give us a sRGB output color space in this
case?)
- The compositor does color correction and the output does have a
profile and we have a compositing space
More information about the wayland-devel
mailing list