Re: [Openexr-devel] f-stops and steps. How are they related?

[Yves Poissant]

Hi Florian,

Thank you for your reply and confirming that I basically got it right.

Yes, In my reasoning, I assumed that even in an 8-bit format, the values 
were encoded linearly. I assumed that for a few reasons:
- In my working setup, I use a well gamma calibrated monitor. So I directly 
view linearly encoded pixel values and I don't have to explicitly apply a 
gamma correction on the file pixel values.
- I also prefer to leave the values stored in a file as linear as possible 
until when the image is finished processing and ready to display. Even 
there, I will apply gamma adjustment only if I already know the explicit 
environment characteristics onto which it will be viewed.

So because of that, I see the *file* format as a linear color space storage 
device and the *display* format as a non linear color space storage device. 
It is in this spirit that i chose those those 8-bit *file format* encoding 
ezamples.

This said, I may be off on this. I'm not so sure. Maybe the industry's view 
on this is different. I know there is a controversy about this gama 
correction thingy directly in the image file (Aka Bruce Fraser vs Timo 
Autiokari that you are probably aware of). Still, on my side of things, I 
prefer to keep the data linear untill the very end.

But back to my cogitations:

If we assume that the encoding is linear, are my assumptions 3 to 6 still 
OFF?

Following up on:

> Then in the next paragraph, under "good color resolution", I read:
> "somewhere around 20 to 80 steps per f-stop for most 8-bit file formats"
>
> 5: - The actual values stored in an 8 bit buffer may be scaled down or up
> with a contrast operator of some sort.

I was trying to write down the rational for this range of numbers.

I agree with you that in an 8 bit format, the usable dynamic range is not 
well defined. And as you put it very well, it "depends on the minimum number 
of steps per stop (or the maximum quantization error) you are willing to 
accept". And I would add it also depends on the actual dynamic range of the 
output device and the actual dynamic range of the input device.

It is not well defined precisely because it is *not* a floating point format 
and so there is not a mantissa to tell us the resolution of the color. I 
specifically chose an 8 f-stop as an easy example that could well be encoded 
in an 5-mantissa, 3-exponent representation for the purpose of helping me 
reasoning the issue. An 4 f-stop image would be 6-mantissa, 2-exponent 
representation. Of course, a 5 f-stop would not be so easy to use as an 
example in this regard and would not hold with my fictitious representation.

An *average* CRT display can represent about 8 f-stops which fits nicely in 
an 8-bit representation. But lets say my input capture device only captured 
5 f-stops of data. And then I expand the histogram to use the full 8 f-stop 
of the file format. I then have an 8-bit file that represent 5 f-stop of 
data or about 51 steps per f-stop (in linear space).  20 steps per f-stop 
would mean the image represents almost 13 f-stops of intensity while 80 
steps per f-stop means the image encodes 3 f-stops of intensity.

----- Original Message ----- 

> Hi Yves,
>
> I agree with points 1, 2, 7, 8 and 9 of your interpretation.
>
> In points 3, 4, 5 and 6 you seem to assume that 8-bit image
> file formats encode intensity or luminance values as if the
> pixels were 8-bit floating-point numbers.  Typically this is
> not the case; most 8-bit file formats use a gamma encoding,
> where the relationship between the integer pixel value, v,
> and intensity, I(v), looks something like this:
>
>     I(v) = Imax * pow (v / 255.0, 2.2)
>
> With this relationship between I and v, the number of steps per
> f-stop is not well-defined.  For example, pixel values 186 and
> 255 are one f-stop apart (I(255) == 2 * I(186)), so you could
> say that you get 69 steps per stop.  On the other hand, pixel
> values 53 and 72 are also one f-stop apart (I(72) == 2 * I(53)),
> so in the range you get only 19 steps per stop.
> The usable dynamic range of the image is not well-defined either;
> the range  depends on the minimum number of steps per stop (or
> the maximum quantization error) you are willing to accept.
>
> For more on this topic, you may want to read Gred Ward's
> "High Dynamic Range Image Encodings" web page, at
> http://www.anyhere.com/gward/hdrenc/hdr_encodings.html, or
> Charles Poynton's "Gamma FAQ", at http://www.poynton.com/GammaFAQ.html.
>
> Florian
>
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel