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

clipka <ano### [at] anonymousorg> wrote:
> 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.

  Well, this clears things up a bit. I'm still not 100% happy that old
scenes will render differently by default, but I suppose it's an acceptable
change.

  I highly recommend writing a concise and clear explanation of this in the
"what's new in POV-Ray 3.7" section when the final version is published.
Else it's only going to cause a lot of confusion.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Well, this clears things up a bit. I'm still not 100% happy that old
> scenes will render differently by default, but I suppose it's an acceptable
> change.

/That/, as I mentioned as well, is only the case if they don't have a 
"#version" directive, or when you're rendering to a "gamma-aware" file 
format.

>   I highly recommend writing a concise and clear explanation of this in the
> "what's new in POV-Ray 3.7" section when the final version is published.
> Else it's only going to cause a lot of confusion.

Boy, how /I/ long for a concise and clear explanation of gamma! Output 
gamma is only the tip of the iceberg.

Try feeding POV-Ray output into POV-Ray again as a texture image - 
that's where things appear to get /really/ hairy!

Post a reply to this message

Btw, if I load a jpeg image as an image_map to an object with diffuse 0
and ambient 1, the image will look way too bright and washed out, completely
different than when I look at the image with any other program.

  If I write an "assumed_gamma 2.2" in the global_settings block, pov3.7
will warn me, but now the image will look correct.

  So what is the *proper* way to tell pov3.7 how it should assume colors
(eg. in image maps) to be gamma-corrected?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   So what is the *proper* way to tell pov3.7 how it should assume colors
> (eg. in image maps) to be gamma-corrected?

  Btw, if I put "Display_Gamma=1.0" in povray.ini, then the *display* shows
the proper gamma. However, the generated png file has the wrong gamma.

  I thought that I could fix that by adding "File_Gamma=1.0", but that had
no effect on anything. Neither does "File_Gamma=2.2" or anything else.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Btw, if I put "Display_Gamma=1.0" in povray.ini, then the *display* shows
> the proper gamma. However, the generated png file has the wrong gamma.
> 
>   I thought that I could fix that by adding "File_Gamma=1.0", but that had
> no effect on anything. Neither does "File_Gamma=2.2" or anything else.

Apparently POV-Ray fails to properly read the gamma information from its 
own generated PNG files. There has been some discusson about this in thread:
news://news.povray.org:119/web.4a398f2555c7683545339cfa0@news.povray.org

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Apparently POV-Ray fails to properly read the gamma information from its 
> own generated PNG files.

  In this case it's not a problem of POV-Ray itself reading its own PNG files.
It's a problem of POV-Ray always creating image files with the same (and to
my understanding wrong) gamma value, regardless of what the File_Gamma ini
setting is.

-- 
                                                          - Warp

Post a reply to this message