Re: [Openexr-devel] magic numbers

[Peter Kümmel]

Hi Florian,

what a excellent explanation! Thanks.

I see, the main point is that one has to think in factors/f-stops.
When the dynamic range (is this the contrast given in the monitor
manual?) is 128, then the brightest pixel is 128 times the darkest,
or one could double the brightness of the darkest value 7 times
(2^7 = 128).
Additionally, because of the logarithmic nature of the eye, the
middle-brightness is not 64 but the solution of the fact:
That the middle-brightness is x times the darkest brightness
and the highest brightness is again x times the middle-brightness:
x*x = 128 -> x = sqrt(128) = 11.31

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. Or is clamp not a linear
maping from 0..x -> 0..155?


float
Gamma::operator () (half h)
{
    //
    // Defog
    //

    float x = max (0.f, (h - d));

    //
    // Exposure
    //

    x *= m; // ctor: m = 2^(exposure + 2.47393)

    //
    // Knee
    //

    //no kee
    //if (x > kl)
    //    x = kl + knee (x - kl, f);

    //
    // Gamma
    //

    x = Imath::Math<float>::pow (x, g);

    //
    // Scale and clamp
    //

    return clamp (x * s, 0.f, 255.f);
}


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


Thanks again,
Peter



Florian Kainz wrote:
> 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
>>
>>
> 


-- 
Peter Kümmel