Warp schrieb:
>> Which is exactly what you should get if you use a gamma-aware image  
>> format, regardless of what you set File_Gamma to.
> 
>   No, because gamma correction will change the actual values of the
> pixels before they are used/displayed. Thus, for example, a pixel which
> in the image file has values <0.5, 0.5, 0.5> will be converted to
> <0.73, 0.73, 0.73> before being displayed on screen, for a gamma correction
> value of 2.2.

And here's where you're getting the gamma correction concept wrong:

With PNG (in the presence of a gAMA chunk), it is up to the /displaying/ 
software to apply a gamma correction, for the /sole/ purpose of showing 
it on a system with an inherent display gamma.

Hence, if the image is used for anything other than immediate display 
(i.e. writing it to the framebuffer of a graphics card), gamma 
correction will /not/ be applied, and the image data is left in the 
linear domain.


>   However, when you are using an image to generate a heightfield, you are
> not *displaying* the pixels. It's actually not an image supposed to be
> shown on screen. It's just an image file being used to represent height
> values. (One could say that an image file is being "abused" for a different
> purpose than it was originally intended.) However. this is a very common
> technique because image files are both very common with a lot of support,
> and a practical way of storing height information.
> 
>   In this situation gamma correction makes no sense because the image file
> does not actually contain an image.

... which is exactly why in such a situation gamma correction will 
indeed not be performed.

The trick here is that in contrast to older file formats, PNG contains 
all information to reconstruct the original linear data, whether an 
encoding gamma has been applied or not - which allows the /reading/ 
application to decide whether a gamma correciton is to be performed or not.

This is a stunt that older file formats cannot achieve.


There is /one/ use case though where it /might/ make sense to tamper 
with output file gamma - and that is if the output file would be 
intended to be used as a heightfield (or similar) in a program that does 
/not/ use linear (= brightness) values, /nor/ the actual encoded pixel 
values stored in the file, but rather categorically expects height to be 
proportional to "framebuffer colors" [*] (which are /not/ linear, but 
gamma pre-corrected for a typical display with a gamma of 2.2), 
regardless of the image file format used.

[* i.e. the values typically ending up in the graphics hardware 
framebuffer, on which not only the HTML colors are based, but also the 
Windows color picker, and the values dispayed in most image editing tools.]

However, POV-Ray itself is not of this kind; furthermore, I would 
consider such software broken, and recommend deliberately feeding it 
input files in a format that is /not/ gamma-aware, so that the software 
is not bothered with ambiguities about whether heights are properly 
encoded based on brightness, "framebuffer colors", or whatever.

Note that with respect to use for height fields, the PNG file format 
with a gAMA chunk is /always/ inherently ambiguous regarding the 
representation if heights: The brightness will /never/ match the 
"framebuffer colors" (except for values 0.0 and 1.0), and there is 
nothing that POV-Ray could possibly do to avoid this mismatch: It's 
rooted in the definition of the "framebuffer colors", which equal the 
brightness values raised to the power of 1/gamma, to compensate for the 
hardware gamma. So a PNG file that works for a program interpreting 
height to be proportional to brightness will never work for a program 
interpreting height to be proportional to "framebuffer colors".

With non-gamma-aware file formats, this ambiguity is more easily 
resolved, as the values can mean just about /everything/, so chances are 
a software interpreting the file as a height field will use the values 
stored in the file, without paying a single thought about whether they 
would normally denote brightness, "framebuffer colors" or 
what-have-you-nots.

Post a reply to this message