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: Tue, 16 Jan 2007 11:59:02 -0800
User-agent: Mozilla Thunderbird 1.0 (X11/20041207)

Peter Kümmel wrote:
With this math I would have assumed that the middle gray of
a 0..1 range is 11.31/128 = 0.088, but you've chosen 0.18,
is this just an empiric value because 0.088 looks too dark?

This was the simple part.
But what is the 2^(exposure + 2.47393) good for?
It seems it is part of the gamma functions, with no
no defog (d = 0), no knee, and a linear gamma (g = 1)
the exposure factor is without effect, it is scaled
way when mapping to 0..255.

Mapping pixel value 0.18, or middle gray, to 0.883 times the
monitor's maximum brightness means that diffuse white objects
do not map to the monitor's maximum brightness; there's some
headroom left for specular highlights, which are often much
brighter than diffuse white objects.  As I mentioned in my
earlier mail, the decision to display images this way is
pretty arbitrary.

The statement

    x *= pow (2, exposure + 2.47393);

normalizes the incoming pixel data, such that the value 0.18
becomes 1.0 when the exposure slider is set to zero, or normal
exposure.  If the exposure slider is set to -1 or +1, 0.18 is
mapped to 0.5 and 2.0 respectively.  Changing the exposure
slider value by n is analogous to changing a camera's exposure
by n f-stops.

This normalization step merely simplifies the calculations that
come later; there's nothing else to it.

Or is clamp not a linear
maping from 0..x -> 0..155?

The statements

    x = pow (x, g);
    return clamp (x * s, 0, 255);

convert the floating-point screen luminance values into the 8-bit
integer values that must be stored in the hardware frame buffer in
order to actually produce the desired luminance values on the
computer screen: pow() compensates for the video system's overall
gamma curve, x*s scales to a 0...255 range, and clamp() eliminates
out-of-range values.

> But I could imagine what CTL will provide: some more
> flexible functions like the Gamma in ImageView.cpp.

This is correct, the bulk of the Gamma in ImageView.cpp will be
replaced by a CTL program.  This allows users to specify how an
image should be displayed.

Florian





reply via email to

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