Warp schrieb:
>   In fact, it seems that POV-Ray is not ignoring the File_Gamma setting,
> as it apparently affects the pixels of the resulting PNG image. However,
> it seems that the incorrect gamma metadata setting is written to the PNG
> file so that when it's viewed with some program (which obeys that setting),
> it looks different from what POV-Ray itself showed on screen (with
> Display_Gamma being set to 1.0).

And that's *exactly* how it should work.

POV-Ray computes its scenes in linear color space. There is no ambiguity 
in the interpretation of the data until it is written to a file.

It is the job of the "Display_Gamma" setting to make sure that the 
linear color data is converted properly to /your/ display's color space 
for the sake of preview, so you can see what you get. It is /your/ job 
of course to set the Display_Gamma properly.

The job of the "File_Gamma" setting, on the other hand, depends on your 
output file format:

(1) If the file format is inherently ambiguous with respect to gamma, it 
is the job of the "File_Gamma" setting to make sure that the linear 
color data is converted properly to whatever the /next/ step in your 
workflow expects.

In this case it is /your/ job to determine your workflow's gamma 
requirements, and set "File_Gamma" accodingly. Note that this may or may 
not be the same as the Display_Gamma - in any case it's your 
responsibility to get it right, not POV-Ray's.

(2) If the file format is inherently unambiguous with respect to gamma 
(e.g. linear coding), the image /must/ be encoded in such a way that the 
linear color data computed by POV-Ray is preserved, e.g. that an output 
software properly handling the file format and properly tuned to the 
display hardware would render a 50% grey computed by POV-Ray indeed as a 
50% grey on the display.

(2a) If the file format is defined to use a fixed gamma for encoding 
(e.g. linear), then obviously this can only be achieved by ignoring the 
"File_Gamma" setting altogether, and using the prescribed file format gamma.

(2b) If the file format is defined to use a variable gamma for encoding, 
to be specified in the metadata, then it is the job of the "File_Gamma" 
setting to specify the gamma to use for encoding, but obviously this 
information must also be stored in the metadata. (This is what happens 
with PNG.)

Note however that in both cases (2a) and (2b), "File_Gamma" will 
obviously /not/ affect rendition of the output file, unless the display 
software fails to properly handle the file format.


Generally speaking, it is the job of the "File_Gamma" setting to specify 
the gamma to use in encoding of the pixel values, for file formats that 
do not prescribe a particular fixed gamma.

It is /not/ the job of either the "Display_Gamma" or "File_Gamma" 
settings to remedy artistic problems of the scene (e.g. it being overly 
bright or pale), technical flaws of legacy versions (e.g. them using no 
gamma correction by default), or technical issues of other parts of the 
software (e.g. input file gamma handling being bogus).


>   If the gamma metadata is removed from the PNG file (eg. by converting it
> to another format, ignoring that gamma setting), then it shows ok.

No, it does not. That's the definition of the metadata. If it looks 
crappy with the metadata, your scene is crappy.

>   You didn't ask for the example, but I went ahead and created one anyways:
> 
> http://warp.povusers.org/pov_imagemap_test/
> 
>   Note that the page has a background color of #7F7F7F and the rendered
> image a background color of 0.5.

Note that...

(1) HTML colors follow the tradition of specifying color values in a 
non-linear encoding subject to display gamma. #7F7F7F therefore does 
/not/ correspond to 50% of actual brightness, but to 50% of /voltage/ on 
the VGA connector, which on a typical 2.2 gamma display corresponds to a 
mere 22% of brightness. (Which in turn happens to roughly correspond to 
a grey /percieved/ to be halfway between black and white, but that's a 
different matter.)

(2) POV-Ray colors are genuine linear brightness values, so rgb 0.5 
/does/ correspond to a 50% of brightness. Which should obviously be 
brighter than 22% of brightness.

With these facts in mind, your experiment in fact proves POV-Ray /3.6.1/ 
output to be wrong (and Display_Gamma=1.0 preview of POV-Ray 3.7 as 
well, which comes as no surprise because your display will typically 
have a gamma of somewhere beteen 1.8 to 2.4).

The only other thing it shows is that the /combination/ of input and 
output gamma transformations are correct for both 3.6.1 as well as 3.7 
with Display_Gamma=1.0, but wrong for 3.7 with defaults. Now given that 
output gamma handling is obviously right for 3.7 defaults, but wrong for 
the others, it follows that input gamma handling must be broken for all 
three of them.

>   Please explain to me, once again, why the default output of POV-Ray 3.7
> beta is the correct one and the others are incorrect.

Done.

Post a reply to this message