[argyllcms] Re: Strange behavior of matrix profile generation from "incorrect" device white pint
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Fri, 29 Apr 2016 10:08:22 +1000
Janos Toth F. wrote:
Hi,
The problem seems to stem from the fact that RY+GY+BY != WY (in other
words, white is not as bright as one would expect by looking at the
luminance of the primaries alone, which is probably caused by an
"Average Brightness Level" limiter built into the display...).
the usual way of dealing with this is to limit the test patch size
to a small enough value that such brightness or power limiting is not
triggered.
A refinement of this is to adjust each test patch and the background
color to a constant average Video or Luminance level.
(The latter is implemented in ArgyllCMS for the ChromeCast test
patch source, but since I haven't implemented it in anything else,
I haven't exposed the functionality yet.)
Even though I am well aware that matrix profiles can not possibly
represent a gamut like this (and no profile [matrix or LUT] should try
and counter-act things like ABL anyway) but I think the error might
should be distributed in a different manner: by respecting the primary
colors over the white point (especially the primary color x,y
saturation over the white Y luminance) with a much heavy weight (in
other words: respect the primaries and let the white point drift).
I'm not so sure about that idea. Typically even a display without ABL
is not perfectly additive, and if the primaries are relied on to compute
the white point, then the white point is likely to be noticeably different
to the actual white, and people will complain. It is far less noticeable
if the white point is accurate and the primaries are slightly in
error, since we are much less sensitive to hue and saturation errors
in highly saturated colors, and very sensitive to them in neutrals.
I
think that would make much more sense since primary color saturations
are usually much more stable than the white point (in case of
displays, it's usually pretty stable while the white point can drift
at any time due to room/device temperature change, aging and/or
aging-compensation firmware algos, APL limiters, undefeatable/hidden
dynamic contrast firmware algos, etc...)
which is the very reason to measure it and use the actual value,
since 99% of color transforms will be white point relative.
Un-defeatable dynamic algorithms in display systems essentially makes
them unsuitable for high accuracy color profiling or color evaluation.
Graeme Gill.
Other related posts:
