Warp schrieb:
>   Btw, could someone explain, once again, why the default gamma settings
> of povray 3.7 are different from the defaults in 3.6, making all scenes
> without explicit gamma settings render differently? I never quite got the
> reason for this.

Maybe because they actually /do/ render identically, provided you 
specify "#version 3.6" to enforce backward compatibility?

Things only get complicated when you explicitly use a flexible-gamma 
file format (such as .png or .hdr). Having these render identically as 
well would probably require different "#version 3.6" defaults for the 
parameters of 3.7's gamma-handling mechanism. Or a nasty hack of that 
mechanism.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   Btw, could someone explain, once again, why the default gamma settings
> > of povray 3.7 are different from the defaults in 3.6, making all scenes
> > without explicit gamma settings render differently? I never quite got the
> > reason for this.

> Maybe because they actually /do/ render identically, provided you 
> specify "#version 3.6" to enforce backward compatibility?

  That didn't really answer my question.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>> Maybe because they actually /do/ render identically, provided you 
>> specify "#version 3.6" to enforce backward compatibility?
> 
>   That didn't really answer my question.

Of course it didn't - if the question is based on false observations and 
therefore moot, what point would there be in answering it?

That is, unless you are asking why the behavior is different when a 
#version statement is /not/ present. But in that case, there's no reason 
to favor compatibility over correctness: 3.6 default gamma handling was 
simply wrong (because it wasn't any gamma handling at all, thereby 
producing linear output where other software commonly expects 
gamma-precorrected files).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Stephen schrieb:
> > On Sat, 22 Aug 2009 10:21:58 EDT, "Frank_C" <fra### [at] skynetbe> wrote:
> >
> >> If you render this scene in both versions, then it looks as if the sphere has
> >> "flattened" in the new version.
> >
> > Sorry but the only differences that I get in pigment which disappears when
> > adding  global_settings { assumed_gamma 1 } to the v3.62 scene.
>
> Same here.
>
> Frank, are you sure you used the same resolution with both renders?


Hi!
I used indeed the same resolution settings for both renderings.
As Stephen indicated, the assumed_gamma keyword made both renders equal. However
I added an {assumed_gamma 2.2} in POV3.7 instead of an {assumed_gamma 1} in
POV3.62. This is because -on my PC- the latter setting had the effect of
"flattening" the sphere (or any other object).
Kind regards
Frank

Post a reply to this message

Frank_C schrieb:
> I used indeed the same resolution settings for both renderings.
> As Stephen indicated, the assumed_gamma keyword made both renders equal. However
> I added an {assumed_gamma 2.2} in POV3.7 instead of an {assumed_gamma 1} in
> POV3.62. This is because -on my PC- the latter setting had the effect of
> "flattening" the sphere (or any other object).

Ah, I see! I thought you meant geometric "flattening", but you're 
talking about colors.

Yes, gamma handling is significantly different between 3.6 and 3.7, and 
does lead to differences in color "intensity".

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Frank_C schrieb:
> > I used indeed the same resolution settings for both renderings.
> > As Stephen indicated, the assumed_gamma keyword made both renders equal. However
> > I added an {assumed_gamma 2.2} in POV3.7 instead of an {assumed_gamma 1} in
> > POV3.62. This is because -on my PC- the latter setting had the effect of
> > "flattening" the sphere (or any other object).
>
> Ah, I see! I thought you meant geometric "flattening", but you're
> talking about colors.
>
> Yes, gamma handling is significantly different between 3.6 and 3.7, and
> does lead to differences in color "intensity".

Just for the completeness, here's a comparison between the two spheres.
The sphere on the left was created with version 3.6 and the sphere on the right
was rendered in version 3.7. I didn't use the assumed_gamma keyword here.

http://img41.imageshack.us/img41/5444/testgjc.png

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >> Maybe because they actually /do/ render identically, provided you 
> >> specify "#version 3.6" to enforce backward compatibility?
> > 
> >   That didn't really answer my question.

> Of course it didn't - if the question is based on false observations and 
> therefore moot, what point would there be in answering it?

  How is it a false observation that I take a scene, render it in 3.6 and
3.7, and I get results which only differ in their gamma setting, and they
do so rather radically?

  Obviously the default gamma settings are different. What has never been
obvious to me is the reason for this.

> That is, unless you are asking why the behavior is different when a 
> #version statement is /not/ present. But in that case, there's no reason 
> to favor compatibility over correctness: 3.6 default gamma handling was 
> simply wrong (because it wasn't any gamma handling at all, thereby 
> producing linear output where other software commonly expects 
> gamma-precorrected files).

  Could you be more precise about this? I still don't understand the reason.
Maybe some concrete examples?

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Could you be more precise about this? I still don't understand the reason.
> Maybe some concrete examples?

Take any scene with (A) an object with a small-scale black-and-white 
checker pattern (if you're using a CRT display, use a large scale 
horizontally), and (B) some rgb 0.5 object. Render without AA.

Now if you render the whole smash and squint your eyes, you /should/ see 
just plain 50% grey for both objects.

Indeed the black-and-white object (A) /will/ look 50% grey (unless your 
display's black and/or white point are bogus), because POV-Ray will have 
output the perfectly unambiguous values 0 and 255 representing 0% and 
100% intensity respectively, in a 1:1 mix, and averaged no earlier than 
when passing between your eyelids.

In 3.6, however, the rgb 0.5 object (B) will look way darker: POV-Ray 
will have output "127", but your graphics card + display will interpret 
this as a meager 22% grey (0.5^2.2 - provided your display has indeed a 
gamma of 2.2).

3.7, on the other hand, will output "186" (255 * 0.5^(1/2.2)) for rgb 
0.5, which is just the right value for a 2.2-gamma display system to 
show 50% grey ((186/255)^2.2); even if your display gamma is somewhat 
off, like 2.0 or so, it will still be closer to the right thing than the 
3.6 output.

(Or, alternatively, POV-Ray will output "127", but store information in 
the output file that a display gamma of 1.0 has been assumed, leaving it 
  to the image viewer to perform gamma-correction; this will happen for 
instance if you choose PNG output and set File_Gamma=1.0.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> In 3.6, however, the rgb 0.5 object (B) will look way darker: POV-Ray 
> will have output "127"

  You mean that POV-Ray 3.6 didn't gamma-correct the output at all, while
POV-Ray 3.7 now does?

  Does that mean there's now a new option to set the gamma correction of
the created image (the actual pixels, not just some header data in the
image file format)? Is there a way to turn this off, if one so desires
(eg. if you really *want* the pixels to be exactly (127,127,127) and
nothing else)?

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
> clipka <ano### [at] anonymousorg> wrote:
>> In 3.6, however, the rgb 0.5 object (B) will look way darker: POV-Ray 
>> will have output "127"
> 
>   You mean that POV-Ray 3.6 didn't gamma-correct the output at all, while
> POV-Ray 3.7 now does?

I mean that 3.6 didn't do it /by default/ (which is what you've been 
asking about all the time).

>   Does that mean there's now a new option to set the gamma correction of
> the created image (the actual pixels, not just some header data in the
> image file format)? Is there a way to turn this off, if one so desires
> (eg. if you really *want* the pixels to be exactly (127,127,127) and
> nothing else)?

Yup. "File_Gamma" is the magic ini file option. Set it to 1.0 and you'll 
get linear pixel values, plus (for PNG and HDR) a header saying that the 
data is linear. Set it to 2.2 and you'll get gamma pre-corrected pixel 
values, plus a header saying that the data is pre-corrected for a gamma 
of 2.2. (The latter is highly recommended though, as not all viewers - 
browsers included - support linear image data.)

Note that this makes it impossible to deliberately mess with gamma for 
artistic effect in POV-Ray when you use PNG output and all your image 
processing software handles gAMA chunks properly: You can only affect 
the encoding of pixels - and thereby the dynamic ranges of highlights 
vs. shadows - but not their interpretation.

At least that's the theory as known to me. I never tested in detail 
whether it indeed works exactly as intended.

Post a reply to this message