Re: Feature request: controlling the display white point

[Andrew Lutomirski <andy luto us>]

On Tue, Nov 19, 2013 at 7:13 PM, Graeme Gill <graeme2 argyllcms com> wrote:
> Andrew Lutomirski wrote:
> > One thing that's bugged my about both ArgyllCMS and g-c-m is that it's
> > hard to set the target white point for the display.
>
>
> Hi,
>         perhaps you could explain how you think this could be
> improve ?
>
> Currently ArgyllCMS dispcal lets you set the white point as:
>
>         Native (default)
>         Daylight locus color temperature
>         Black Body locus color temperature
>         x,y coordinate

The last time I dealt with this (on my old Lenovo X200, which I barely
use anymore) I got annoyed by how hard it was to see how well a given
white point would work.  Some easy way to quickly estimate how much
brightness I'd lose for a given white point (and even a way to preview
a white point) would have been helpful.

I also think I had trouble understanding colprof's white point
settings.  ISTR that I could easily generate a VCGT for any given
white point, but I had trouble getting a sensible profile as output.
That may mean that I was just failing to understand something, and I'm
pretty sure I figured it out.

FWIW, I seem to remember that "native" did something awful on the
X200, though.  That display had (IIRC) a native "white" point (i.e.
255,255,255) that was rather blue but probably quite far from any
sensible locus, but grays tended to be very red.

> > 3. There are programs like f.lux [1] that vary the white point
> > throughout the day.  I should be able to do this using tools like
> > g-c-m.
>
> Such "entertainment" programs are at odds with accurate reproduction
> of color though.

That's certainly true.  I'm not a serious photographer, and I usually
just want decent color reproduction as opposed to excellent color
reproduction.  A version of something like f.lux that at least tried
to preserve some color fidelity would probably be an improvement.

On the other hand, aren't there some instruments that can quickly
measure the ambient color?  For more accurate color work, I can
imagine it being useful to be able to quickly adjust settings in a
daylit office throughout the day as your eyes' adaptation changes.

> > Ideally I'd be able to profile my display once
> > (possibly in a slower mode that collected more data points) and then,
> > whenever I want to set a white point, to generate the gamma ramp and
> > profile for that white point on the fly.
>
> While such a thing may be technically possible (and something like it
> can be achieved using absolute colorimetric intent and color profiles)
> the reason that ArgyllCMS colprof works like it does is in an attempt
> to provide an accurate calibration by actually determining the
> device values that meet the calibration target. It's not practical
> to fully characterise a display - some level of sampling and
> model fitting/interpolation is needed, and this introduces inaccuracy.
> Such inaccuracy in profiling is reduced by having an accurately
> calibrated device.

For the best accuracy, or even for acceptable accuracy on weird
non-additive devices, I can see how the current model would do much
better than trying to fully characterize a display and then picking a
calibration and deriving the profile.

I suspect (or hope, anyway) that most decent displays are reasonably
close to being additive.  (Isn't this necessary for matrix profiles to
work right?)  If you assumed that a display were close to being
additive and that the calibration, once applied, had the correct
effect, you could try to measure (once) the response of each color
channel to compute something like a matrix profile, only with an
actual curve instead of just a gamma value.  Then you could, assuming
the resulting profile were correct, choose a white point and calculate
a gamma ramp and real matrix profile to apply it.

Would this work reasonably well on modern LCD displays?

> > From the colord/g-c-m point
> > of view, being able to go into the g-c-m settings and select a white
> > point for immediate application would be nice (and programs like f.lux
> > could be replaced by some straightforward code to ask g-c-m or colord
> > to change the white point).
>
> It comes down to the mechanism being used for color management.
> Ideally the calibration curves shouldn't be changed to achieve such
> an effect, since their primary purpose is to improve the characteristic
> of the device, not achieve color management (something they
> are incapable of doing anyway) - if all the colors on the GUI were
> being color managed, then you would instead just change the source
> profile(s) being used for all the elements that you wanted to apply
> this effect to, or interpose an an abstract profile in the CMM path.

Hmm.  Hopefully it won't be too long until compositors color manage
everything (maybe with 10 bit output), so this might be doable.  If
that happened and people wanted to play with white points, it might
pay to prefer a calibration for the native white point to maximize the
gamut.

For now, though, I *think* that changing the gamma ramp will do
approximately the right thing for non-color-managed programs.

--Andy