[Openexr-devel] OpenEXR colorimetry

[joseph]

Hello all--

Drew mentioned in his 2 Oct 2003 mail ("new release coming soon") that
one of the next things up was to standardize on some colorimetry and
image capture attributes and forwarded me some off-list mail on the
topic.  So just to get some discussion going:

Greg Ward had proposed a couple new attributes:

> "sampToNits"
> a FloatAttribute that gives the absolute scale
> to get from sample values to Nits (cd/m^2) for the
> purposes of photometric calibration

(is this supposed to be like the LogLuv TIFFTAG_STONITS tag?)

and

> [...] also add a parameter to record the CIE (x,y) chromaticities of
> each color channel, plus the white point.  This is standardized in TIFF
> as tag 319 (TIFFTAG_PRIMARYCHROMATICITIES in Leffler's library), and
> consists of 6 floating-point values.  In addition, tag 318
> (TIFFTAG_WHITEPOINT) is two floats that hold the white point CIE (x,y)
> coordinates.

Florian suggested consolidating the PRIMARYCHROMATICITIES and
WHITEPOINT tag:

> I suggest that we add a single "chromaticities" attribute whose value
> is a struct:
>
> struct CieChromaticities
> {
> V2f	red;
> V2f	green;
> V2f	blue;
> V2f	white;
> };
>
> "White" is somewhat ill-defined in HDR images.
> For the purpose of defining the chromaticity of
> the white point, will it be necessary to state
> something like "white means R, G, and B are
> all 1.0", or is it enough to say "white means
> R, G, and B are equal"?

-=-=-=- MEANING OF WHITE

If we specify that white means R = G = B = 1.0, and we have the xy values
of all the primaries and white, then we can recover the
XYZs of the three primaries and white point without ever having to
carry around an explicit Y, which is kind of nice.  Couple that with
"sampleNits" and you get CIE-absolute colorimetry.

Are there situations where one would know the primaries, but NOT know
the white point?

-=-=-=- NAMING OF THE CHROMATICITY ATTRIBUTE

Since the CIE defines other types of chromaticities besides x,y, is
CIEChromaticities a good name?

(I kind of hate to have the Cie prefix, since it's CIE in every
official document, but then again the library names start with
libIlm... instead of libILM... -- if we do keep a reference to the CIE
in the name, how do people think it should be capitalized?)

Poynton's newer book (pp. 236-239) uses "primaries" to mean R, G, B and
white as well.  Not so Hunt, or at least not so 5th edition Hunt (6th
ed. is due out next month).

I dunno, I propose CIExyChromaticities, is that an OK name?  with the
"xy" in the attribute name, thus not implied, nor replicated in the
names of the individual members of the struct?  With Florian's proposed
representation.

-=-=-=- VERIFICATION OF PERCEPTUAL CONTINUITY

I suppose for completeness it would be good to be able to assert
mathematically what most of us feel intuitively: that for a given set
of primaries and white point, there are no two adjacent colors in the
OpenEXR RGB color cube whose displayed colorimetry is more than 1 JND
apart.  "Adjacent" in this case means that for two RGB values, all of
the R, G and B values are either the same, or that they are direct
neighbors along OpenEXR's sampling of the Real line.

If you have all four chromaticities, you can reconstruct the XYZs for
the three primaries and thus the RGB-to-XYZ matrix; and the XYZ to
(say) L*a*b* equations are well known; but I can't reason about math
[sorry, Neil, I meant "maths"] well enough to go from OpenEXR's
sampling of the Real line to some formulation about (say) deltaEab.  It
seems like some sort of problem in symbolic interval arithmetic.

In sum, is it worth doing a worst-case analysis of the distance in
(say) L*a*b* space from two adjacent RGB pixels, for a given set of
[reasonable, e.g. Rec. 709] primary and whitepoint xy chromaticities?

-=-=-=- COMPATIBILITY

a meta-point: are there EXR clients out there which are already using
custom attributes for this purpose, and if so what (if any)
compatibility constraints are imposed on us by such clients?  I'm
thinking about Photosphere and any EXR images it might also have
written.  If we change the attribute could we just make the EXR reader
recognize the old name, and make the reader write the old name if
present?  With a conflict between old-named and new-named attributes in
the same image file being settled by going with the new?



Comments?
--joseph



-=-=-=-=-=- -=-=-=-=-=- -=-=-=-=-=- -=-=-=-=-=- -=-=-=-=-=- 

Taking logs - Broadly speaking, any equation which looks difficult
will look much easier when logs are taken on both sides. Taking logs
on one side only is tempting for many equations, but may be noticed.
-- R. Ainsley in Bluff your way in Maths, 1988