openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] magic numbers


From: Florian Kainz
Subject: Re: [Openexr-devel] magic numbers
Date: Mon, 15 Jan 2007 15:12:29 -0800
User-agent: Mozilla Thunderbird 1.0 (X11/20041207)

Hi Peter,

there is no single correct way to map the half values in an OpenEXR image
to 8-bit integer frame buffer values.  Conceptually, OpenEXR images are
"scene referred" or "focal-plane referred", that is, the half values in
the pixels are proportional to the amout of light that was emitted by the
corresponding objects in the depicted scene.

When you display an OpenEXR image you must decide how bright the
image is supposed to be; this is analogous to choosing an exposure
when you photograph a scene.  In addition, you may choose to make the
amount of light emitted by your monitor strictly proportional to the
amount of light in the original scene, or you may decide to manipulate
the contrast of the image to make it look more pleasing.

Of course, having to choose what the image will look like on the screen
isn't always good.  When you send an image file to someone else, you want
to be reasonably sure that when they display the file on their computer
they see what you see on your computer.

In order to ensure compatibility, we used to recommend that applications
display images using the magic numbers in exrdisplay.  What exrdisplay
does is useful but certainly not the only way you could display an image.
You may want to do something different.  Therefore, the latest
version of exrdisplay and playexr supports color rendering
transforms written in a Color Transformation Language (CTL).  When
exrdisplay displays an image, it executes a corresponding CTL program
to derive the on-screen pixel colors from the pixels in the OpenEXR file.
String attributes in the file header tell exrdisplay which CTL program to
run.  If you send someone an OpenEXR file, and the image is meant to be
displayed with a non-standard rendering transform, then you should also
send them the corresponding CTL program.  (CTL will be released separately
from OpenEXR, hopefully before the end of January.)

Regarding the magic numbers that are hard-wired into exrdisplay: we
decided, more or less arbitrarily, that the floating-point value 0.18
corresponds to the amount of light reflected by a "middle gray" object
that reflects 18% of the incident light.  When an OpenEXR image is
created the exposure should be set such that middle gray objects map
to the floating-point value 0.18.  We assume that a computer monitor in
an average office environment has a usable dynamic range of approximately
128:1, or 7 f-stops.  We scale the floating-point pixel values from the
OpenEXR file such that the value 0.18 is placed in the middle of the usable
range: 11.31 times darker than the monitor's maximum white and 11.31 times
brighter than what we assume is the darkest usable value.  Simple linear
scaling of the floating-point pixels, followed by clamping of values that
are brighter than the monitor's white, causes objectionable discoloration
and Mach banding at bright highlights.  We reduce those artifacts by
applying a "knee function" to the pixels: starting at a brightness level
somewhere between middle gray and the monitor's white, we progressively
reduce the contrast of the input image.  This way discolorations and
Mach banding due to clamping are much less noticeable.  Exrdisplay's
"knee low" and "knee high" controls determine the brightness level
where contrast reduction sets in, and how much contrast is reduced.

For more information, see:

    http://www.openexr.com/OpenEXRViewers.pdf

    http://en.wikipedia.org/wiki/Tone_mapping

    Erik Reinhard, Greg Ward, Sumanta Pattanaik, Paul Debevec,
    High Dynamic Range Imaging,
    Morgan Kaufmann, 2006

    Mark D. Fairchild,
    Color Appearance Models,
    John Wiley & Sons, 2005

Hope this helps,

Florian



Peter Kümmel wrote:
Hi all,

currently I'm reading the source code of exrdisplay,
and I'm wondering about where all the magic numbers
are coming from:

- 2^(exposure + 2.47393)

-       //
        // Map floating-point pixel values 0.0 and 1.0
        // to the display's white and black respectively.
        //

        exposure = 1.02607;
        defog = 0;
        kneeLow = 0.0;
        kneeHigh = 3.5;


Could someone point me to papers/books/explanations
how to map the half range to 0..255?

Many thanks,
Peter


_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel






reply via email to

[Prev in Thread] Current Thread [Next in Thread]