[argyllcms] Re: Argyll and 30-bit colors

  • From: ternaryd <ternaryd@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 16 Aug 2016 07:32:07 +0200

On Tue, 16 Aug 2016 13:13:30 +1000
Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:

that neither MS nor Apple have current native
operating systems support for 30 bit frame

I have seen reports of people claiming that
they managed to set Windows to 30-bit, but they
where unhappy because non-30-bit-aware
applications wouldn't be dealt with gracefully.

In contrast, X11/Linux should work out of the
box using existing API's, if the applications
look for it.

Yes it should. A depth of 32 bits in X was
allowed since a long time, and it's up to the
driver what to do with the spare bits. The
nouveau driver does not support the 30 as I
found out asking on their mailing list (some
time ago). The proprietary nVidia drivers
promise this setting since a long time, but
only with the most recent driver I was able to
actually get 30 bits also being reported by X.
I'm still looking for one of that bad cases of
banding which lead me to pursue all this, and
now, I can't find one in order to get visual

My guess is that OS don't want to support
30-bits straight away because most applications
are not 10-bit aware and need to be adjusted on
the fly (potentially looking worse), besides the
fact that the alpha channel (a hack in my
opinion) is reduced from 8 to 2 bits. And this
is something which can not be changed that
easily in so much software. This will probably
change only, if libraries support it behind the
scene. Specially optimized code running through
the image with bit shifts will need a complete

For that reason, I thought it to be
interesting, to stick with the 8 bit by default
and ask for the 10 bit for a particular window
only. And that is, why I chose to cite this
PDF. However, I'm not sure yet with things
actually work or just report to be working.
Running X in 8 bit and open a window with
10 doesn't (visual not found). Running in 10
does work, and 8-bit images look rather normal;
there are some applications which don't run
anymore, because they don't find their
(old) visual. But I still lack visual proof to
actually get 10-bit images automatically or by

Overall I'm a bit unconvinced by it all.
Calibration is already 8 bpc, and profiling
doesn't sample in enough detail for 8 bpc to
be of much significance (i.e. what does it
matter that you are restricted to 16 million
colors out of 1 Billon, if you are only
measuring a few > thousand of them ?). The
resulting calibration curves are floating
point, and the profiles are 16 bpc, so if
your system has 8 bpc, the end result will
be smooth.

I was less thinking of picking a color to
measure, than trying to match one. What
triplet sent to the monitor will yield a
measuring of that XYZ-value? Those lines in
"dispcal -v2" with "Failed", don't they vary
the colors hoping to get a reading which
matches some target values within some

Those "Failed" lines yield some ugly
discontinuities in the final curve which,
although short, have a surprising (for me)
effect on the overall image. I can see this
easily when adjusting the curve with the mouse
in darktable (but my results are useful for
individual images only).

In terms of dispcal, there are two directions
I'd like to go in, neither of which relies on
30 bit frame buffers. One is to use dithering
(which is tricky to do automatically - it's
hard to quickly and reliably figure out the
actual bit depth from VideoLUT to display
using an instrument),

If it's hard to figure out, why not ask the
user? Maybe you could even allow him to set
some environment variable such that this
setting would apply to all Argyll tools. I
think if someone doesn't know he's using 30-bit
colors, his bank account will certainly know.

BTW, dispcal told me that it was unable to find
the bit-width of the Video LUT; a bit later I
read that the official software for the Eizo
Monitors (running Windows only) won't allow to
adjust the Video LUT either. Might there be
some connection?

and the other direction is to change dispcal's
algorithm to not be so sensitive to

What would be the effect of this upon the
results? Smoother but less precise curves?

I do have some OpenGL code from a few years
back that I could base something on - it was
the only way of getting smooth crossfades
between images on an MSWin machine :- GDI
and MS's other API's were a joke, but
years-old OpenGL > had a stable API and just
worked. So I suppose an OpenGL test window
option is a possibility.

I completed the code in the PDF just enough to
create a colored window which X considers to be
10-bit per channel (xwininfo; but I'm unsure if
it actually is). The glx variant is actually
just a few lines. Recalling my nightmares of the
1990's, setting up flightgear, OpenGL and GLX
worked now out of the box.

Dithering does help, as can be experimented
with using madTPG.

I haven't figured out yet what madTPG is, but
if dithering helps, why don't 10-bits?

I'm not so sure. The basic colorimetry isn't
that repeatable per measurement, unless you
are using expensive instruments (Klein K10
etc.), and there is little disadvantage in
choosing profile test points that land on 8
bit values, with the resulting profile is 16
bpc, so it can be used at whatever precision
the display is capable of.

My ColorMunki Photo certainly not being a high
quality spectrometer, it should be already
better than my previous Spyder4. But I'm
afraid, I don't follow you here: If the
instrument is too imprecise to give reliable
(repeatable) measurements, how would dithering
help then? Would it be possible (useful?) to
run some test cycle to measure the tolerance of
the instrument?

But the profiler doesn't need access to 10
bpp to characterize the display. It will
interpolate between 8 bpp values, just like
it interpolates between the relatively few
samples measured.

I didn't start trying to profile yet; still
trying to calibrate. I'm taking my time for
that, because I think the better the
calibration, the less change needs to be
introduced by the profile, which is desirable.


Other related posts: