[RFC wayland-protocols v2 0/1] Color Management Protocol

Fri Mar 15 10:41:57 UTC 2019

On Thu, 14 Mar 2019 14:29:23 +0100
Erwin Burema <e.burema at gmail.com> wrote:

> On Thu, 14 Mar 2019 at 14:04, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > On Thu, 14 Mar 2019 13:27:45 +0100
> > Erwin Burema <e.burema at gmail.com> wrote:
> >  
> > > On Thu, 14 Mar 2019 at 12:29, Pekka Paalanen <ppaalanen at gmail.com> wrote:  
> > > >
> > > > On Wed, 13 Mar 2019 15:50:40 +0100
> > > > Erwin Burema <e.burema at gmail.com> wrote:
> > > >  

...

> > > > > Adding to this all I would like to note that although I think that for
> > > > > the best possible output we need both a  critical and non-critical
> > > > > color path I personally can live with some wonky alpha transparencies
> > > > > considering that most of the time those should be limited to effects,
> > > > > but I would hardly call that every frame perfect ;)  
> > > >
> > > > Did the non-linearities from degamma not result purely because the
> > > > output color profile was not good enough? That is, the ICC file is
> > > > missing some optional parts or the data in them is not actually correct.
> > > >  
> > >
> > > No it comes from shitty cheap monitors, alas I am afraid that
> > > explaining all this to the people who use those kind of monitors will
> > > not be easy  
> >
> > Hi Erwin,
> >
> > do you mean that the mapping from pixel values to light levels for a
> > crappy monitor is not even expressable in the terms available in an ICC
> > file?
> >
> > I mean, in terms that would allow one to go from the non-linear output
> > space to a linear-light space?
> >
> > Or that the per-channel "gamma ramp" is not really invertible?
> >
> > Cross-talk between channels?
> >
> > Cross-talk between adjacent pixels?
> >
> > Something else too?
> >  
> 
> It will have mostly have non-proper white balance (so R=G=B=1 won't be
> anything "white"), a curve per channel which might not be invertible
> (so R=G=B=c won't have a constant hue/chroma for different c) and
> cross talk between channels (in decreasing likelihood) all of which
> can be described in an ICC file but it will most likely be a LUT
> profile instead of a matrix one and a LUT profile can't be guaranteed
> to be linear nor easily invertible.

Hi Erwin,

I see, so the problem is not so much as including the wonky effects in a
profile, but to extract the degamma mapping in a good way since it is
often not stored separately in an ICC file?

Can an ICC file include a per-channel degamma and gamma LUTs? That
is, in addition to the usual profile data that allows mapping between
PCS and the device space.

If yes, and if there are profiling applications that can produce those
properly, maybe a compositor could check for the existence of the
degamma/gamma LUTs and warn the user if they are missing? Up to
compositor policy, of course.

Is extracting a degamma mapping from a LUT profile an ill-defined
problem to begin with? If it can be done at all, I would be happy to
punt that to color specialized tools producing ICC profiles and have
compositors just say your output ICC profile file is lacking.
Especially so if finding the degamma mapping needs a measurement tool.

> > > > This may seem like finger-pointing, but if a compositor is given a less
> > > > than perfect ICC profile for an output, there is no way it could ever
> > > > make any frame perfect. Attempting to second-guess the profile will be
> > > > futile in any case. I would not include the completely different
> > > > blending space path, because it is trying to work around flawed data
> > > > (the output color profile) in a way that will be wrong if the data was
> > > > perfect.
> > > >
> > > > Weston has a policy to not work around driver bugs. I feel I can lump
> > > > an inaccurate ICC file in the same heap.
> > > >  
> > >
> > > Not inaccurate just cheap monitors (it is accurate for the cheap
> > > monitor it is just that cheap monitors have a tendency to be rather
> > > wonky color wise), although you might consider that a HW bug  
> >
> > If someone is using such a monitor, I wonder, do they actually benefit
> > from color profiles at all? Isn't it just an arbitrary transform over
> > an arbitrary presentation that might look nicer but have still a very
> > poor correlation to colors on anything else?
> >  
> 
> They would benefit with a proper profile they would be able to get
> much closer to proper colors then without in fact you can make a case
> that these kind of people would benefit the most from a good profile
> since a monitor that is already 99+% sRGB with the right kind of TRC
> won't need as much correction, although making such a profile on such
> a monitor is a bit harder (but this will be mostly hidden by good
> profiling /calibration SW)

Right, we shouldn't ignore the issue then.

> > The alternative would be to not use color management at all, which
> > means that e.g. weston will blend in non-linear whatever space.
> >
> > If it seems like I am desperately trying to find an excuse to ignore
> > this problem, that would be because I am. :-)
> >
> > But maybe I am mistaken and the problem is important. After all, I
> > suppose crappy monitors are the huge majority.
> >  
> Yes sadly they are and are also mostly used by people who don't fully
> understand color management but still might want to benefit from it.
> In the past most of these kind of issue where seen by professional
> using monitors that could display in for example adobeRGB without full
> desktop color management but at least to those you should be able to
> explain why only their color managed apps looked OK while the rest
> looked crappy, which is inverse of the case we have here with full
> desktop color management and alpha blending. Of course we can just
> ignore it and hope no one notices that the alpha blended colors look a
> bit off
> 
> Kind regards,
> 
> Erwin
> 
> PS. Very much enjoying this discussion hope I am not to much of a contrarian

Not at all! I'm happy to have constructive feedback.

I believe that while I won't be implementing color management in
Weston, I will likely need to review it, so I'm asking all these
questions to learn the right way, as I have no background in color
management.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190315/29f46a7a/attachment.sig>