clipka <ano### [at] anonymousorg> wrote:
> The reason for POV-Ray to refuse to do so in PNG files is simple: 
> Because the aim is to get /correct/ file output, i.e. if a brightness 
> level of 50% is computed, the aim is to generate an output file that, 
> when displayed, will cause a brightness level of 50% on the output hardware.

> Consider this a "what you see is what POV-Ray computed" policy.

  Except that it isn't. If you specify Display_Gamma=1.0 and File_Gamma=1.0,
POV-Ray will display non-gamma-corrected pixels on screen, and write the
exact same non-gamma-corrected pixels into the PNG file, but then it
specifies a gamma metadata of 2.2 in the PNG file (where is it getting
the 2.2 from anyways?) which causes the PNG to show *differently* than
what POV-Ray showed on screen.

  If you then manually remove the gamma metadata from the PNG file, *then*
the PNG and what POV-Ray showed on screen will match, because only then
will no extraneous gamma correction be applied (as was the original intent
when the gamma settings were both set to 1.0).

  Can you explain where the extranous 2.2 gamma setting is coming from,
when both Display_Gamma and File_Gamma are set to 1.0? Is there a third
setting somewhere? Is it hard-coded into the POV-Ray source code?

  I think that it's a bit ridiculous that if I want POV-Ray to produce "raw",
non-gamma-corrected pixels, I have to go through manual post-processing
trickery to achieve that (or, I assume, use an image format which does not
support gamma metadata). If I say that gamma is 1.0, in other words,
completely unmodified pixels, then I mean that.

-- 
                                                          - Warp

Post a reply to this message