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
_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel