[colord] [Lcms-user] ddc/ci and color management

[Richard Hughes]

On 18 May 2014 15:24, Sanford Rockowitz <rockowitz at minsoft.com> wrote:
> I apologize in advance for posting a question about DDC/CI to this list,
> as it's not quite on topic.  People here have been very helpful and I'd
> certainly appreciate suggestions as to a more appropriate place to post.

This would be interesting to the people using colord too, so I've included a CC.

> When I perform a calibration, it's specific to the current settings of
> the monitor: color temperature, RGB channel settings, brightness, etc.

Right. Some hardware can't do any of this, e.g. laptops, although in
theory we can know this from the DDC data.

> Yet handling these settings is an out of band process.  It's the user's
> responsibility to manually adjust the monitor settings and record the
> values before calibration, and restore them manually if necessary.  At
> the very least, it would be desirable to record those settings in the
> profile, or even just have a utility that allowed me to record the
> settings and possibly restore them.

At the moment GNOME, XFCE and KDE automatically set the backlight
brightness to the value used for profiling on session start, although
the user is free to change it as they wish.

> Googling, I find a bunch of posts from Kae-Uwe Berman, Graeme Gill,
> Richard Hughes and others circa 2009-2010  (e.g.
> http://comments.gmane.org/gmane.comp.freedesktop.xorg/41559,
> http://lists.x.org/archives/xorg-devel/2010-July/010922.html) Then
> discussion of this topic seems to die.

There are several good reasons for this, the biggest being that DDC/CI
is underspecified and also wrongly implemented by a *lot* of vendors.
For instance, on my high-end HP DreamColor monitor the DDC/CI API
behaves as you would expect, with a few HP specific extensions. When
you call GetContrast, you get the contrast value. The *huge* problem
with DDC/CI is that it's not really used by Windows to the full
extent, and if nothing is using it by default, you get firmware
engineers doing crazy things. IIRC, on my LG monitor the "Contrast"
scale is inverted. On my el-cheapo Sony rebranded panel using DDC/CI
anything more than getting the EDID sometimes triggers the panel to
reset to the factory defaults. I've heard other people report that
setting the brightness on some old CRT monitors did crazy things like
a degaussing.

This is why the ddccontrol project has that huge unmaintained XML file
of all the monitor quirks for basically every monitor. I'd love to say
that in 2014 monitors are just doing the right thing and that quirks
are no longer required, but you've found out the hard way that's not
true :)

I do see some value in recording things like the "contrast" in the ICC
file, and restoring it at session start if set, but it's not the kind
of thing we can support by default as the hardware support just isn't
there. Maybe a whitelist might work. Ideas welcome.

Richard.