POV-Ray : Newsgroups : povray.beta-test : Same scene renders different in v3.7beta34 versus v3.62 : Re: Same scene renders different in v3.7beta34 versus v3.62 Server Time
6 Oct 2024 04:22:37 EDT (-0400)
  Re: Same scene renders different in v3.7beta34 versus v3.62  
From: clipka
Date: 2 Sep 2009 01:03:38
Message: <4a9dfcaa$1@news.povray.org>
Warp schrieb:
>> 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).

(1) Note that specifying a Display_Gamma does /not/ change what POV-Ray 
/computes/; so if you specify a wrong Display_Gamma (and 1.0 /is/ a 
wrong value for your system), what you see during preview is /not/ what 
POV-Ray computed either.

(2) Are you /sure/ that what you observe is a gAMA chunk specifying an 
encoding gamma of 1/2.2 (i.e. encoded for direct display on a gamma 2.2 
display)? I pretty much doubt it:

- If POV-Ray writes linear color values into the PNG file, it must write 
a gAMA chunk specifying a gamma of 1.0 to produce a properly encoded PNG 
file.

- If the file contained a gAMA chunk specifying a precorrection for a 
gamma of 2.2 (i.e. an encoding gamma of 1/2.2), then AFAIK stripping 
that gAMA chunk would not change the way most image vewers display the 
image, because they will by default assume exactly that encoding gamma.

- If, however, POV-Ray does write linear color values into the PNG file, 
accompanied by a gAMA chunk specifying an encoding gamma of 1.0, then 
indeed stripping that gAMA chunk will cause image viewers to presume an 
encoding gamma of 1/2.2 (which will then be /not/ what POV-Ray used), 
and therefore not perform any additional gamma-correction, because it 
cancels out with their assumed display hardware gamma of 2.2 - and this 
would indeed have the same effect as the wrong Display_Gamma=1.0 
settings (which tells POV-Ray to not perform gamma-correction on the 
preview, by forcing it into assuming that the display hardware has a 
gamma of 1.0).


So to sum it up: Specifying Display_Gamma=1.0 does not change what 
POV-Ray /computes/, only what it shows in preview; and I expect the 
gamma 2.2 gAMA chunk in the File_Gamma=1.0 to be a misinterpretation of 
your observations.

>   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.

Tell me, in all honesty, what do you /want/ those "'raw', 
non-gamma-corrected pixels" for in the first place?

I actually find it ridiculous that you /ask/ for it, that being 
essentially /messed-up/ gamma in what will ultimately be visible 
on-screen; if you do not recognize this fact, then you haven't 
understood gamma handling yet (and I'm not talking about POV-Ray in 
particular here, but the general concept), and might want to do a bit of 
googling on the topic.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.