Re: [Openexr-user] storing an EXR image in memory

[Florian Kainz]

> 1) again on exrdisplay rendering pipeline (someone of you may remember
> me, i was posting as tensor g): I studied the whole code and the only
> question remaining is, do i really need the knee function? Actually I
> made some tests, but i can't really see much difference between an app
> running the knee and one that doesn't. Just wondering if i may be able
> to cut a bit on that code, but yet afraid of leaving back some necessary
> stuff... ;)

You don't have to apply a knee function if you don't find it useful.
The function only compresses the dynamic range of the pixel data.
It lets you display a wider range of values, but it also alters the
appearance of the image.  If you adjust your image's exposure so that
most pixels are less than middle gray + 3.5 f-stops, then your image
will look "more correct", that is, more like the original scene, if
the knee function is turned off.

> [...]
> 
> > Given an OpenEXR file's "chromaticities" and "whiteLuminance"
> attributes, the code snippet below computes a pixel's absolute luminance
> 
> now how do I extract chromaticities and whiteluminace values???
>

"chromaticities" and "whiteLuminance" are optional attributes in the
OpenEXR file's header.  The easiest way to access the attributes is
via the utility functions declared in ImfStandardAttributes.h.

"chromaticities" defines exactly what colors are represented by the RGB
triples (1,0,0), (0,1,0), (0,0,1) and (1,1,1).  On your monitor, (1,0,0)
is a particular shade of red, but on my video projector, (1,0,0) may be
a rather different red.  If you save an image, and you store your monitor's
chromaticities in the file, then I know exactly what the image looks like
on your monitor, and I can adjust the RGB values in the pixels to make
the image look almost the same on my projector.

"whiteLuminance" defines how bright the RGB triple (1,1,1) is.  If your
image shows a landscape with an overcast sky, I may not necessarily know
whether the image was taken during the day, or during a full-moon night,
with a long exposure, but whiteLuminance tells me.  Assuming that RGB
values in the sky are approximately (1,1,1), then a whiteLuminance of
1000 or so would indicate a daylight image, but for a night-time image,
whiteLuminance might be only 0.001.

Since "chromaticities" and "whiteLuminance" are optional, not every
OpenEXR file has them.  (Equipment for measuring chromaticities tends
to be expensive.  Luminance can be estimated with a photographic exposure
meter; converting exposure values to candela's per square meter is left
as an exercise to the reader.)

If one or both attributes are missing, you have to use default values.
The sample code in my last mail tries to do that:

    RgbaInputFile in (...)

    Chromaticities cr;
    float wl = 1;

    if (hasChromaticities (in.header()))
        cr = chromaticities (in.header());

    if (hasWhiteLuminance (in.header()))
        wl = whiteLuminance (in.header());

    M44f m = RGBtoXYZ (cr, wl);

    Rgba &pixel = ...

    float Y = pixel.r * m[0][1] + pixel.g * m[1][1] + pixel.b * m[2][1];

If the "chromaticities" attribute is missing, then cr is initialized
to a value that approximates most real video monitors reasonably well.

If the "whiteLuminance" attribute is missing, then the code simply uses
the value 1.0.  You will not be able to retrieve the absolute luminance
data, but you can determine relative luminance values: "this object is
twice as bright as that one".