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

Warp schrieb:
>   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?

I just went back to this post, to find that I misunderstood.

Yes, POV-Ray /definitely/ has a problem with gamma of input files. PNG 
files with a gAMA chunk are allegedly safe, and HDR files as well from 
my experience (OpenEXR probably too), but just about everything else is 
currently bogus, due to POV-Ray not taking into account any color 
management metadata.

My suggestion would be to (A) fix the standard handling to respect at 
least standard color profiles, and (B) provide a means to override the 
assumed gamma pre-correction on a per-file basis.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> My suggestion would be to (A) fix the standard handling to respect at 
> least standard color profiles, and (B) provide a means to override the 
> assumed gamma pre-correction on a per-file basis.

  Also POV-Ray 3.7 displaying the image on screen with one gamma setting
(with Display_Gamma is set) and writing the file with a completely different
gamma setting is a problem.

  Btw, a Display_Gamma of 1.0 produces (on screen) an image which is
basically identical to what POV-Ray 3.6 produces, all image_maps look
correct, etc. Is there a reason why it cannot be the default?

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Also POV-Ray 3.7 displaying the image on screen with one gamma setting
> (with Display_Gamma is set) and writing the file with a completely different
> gamma setting is a problem.

It only is a problem if you set the Display_Gamma value wrong, or set 
the File_Gamma value to a nonstandard value with a file format not 
supporting embedded gamma information.

>   Btw, a Display_Gamma of 1.0 produces (on screen) an image which is
> basically identical to what POV-Ray 3.6 produces, all image_maps look
> correct, etc. Is there a reason why it cannot be the default?

Yes, there is: It's perfectly wrong for most systems.

Did you ever try it out with a scene to test your workflow for gamma issues?

Just set up a scene with a thin-horizontally striped (or, if you have an 
LCD display, checkered) black-and-white background and some rgb 0.5 
object for comparison, using ambient-only materials.

Such a scene /should/ look perfectly homogenous when you squint you 
eyes. If it doesn't, your workflow doesn't handle gamma properly.

(Similarly, the output of such a scene, used as input for another scene 
and heavily blurred by focal blur or anti-aliasing, should appear 
homogenous as well; this is where POV-Ray currently does a poor job.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   Also POV-Ray 3.7 displaying the image on screen with one gamma setting
> > (with Display_Gamma is set) and writing the file with a completely different
> > gamma setting is a problem.

> It only is a problem if you set the Display_Gamma value wrong, or set 
> the File_Gamma value to a nonstandard value with a file format not 
> supporting embedded gamma information.

  It is a problem when POV-Ray ignores the File_Gamma setting, as seems to
be currently the case.

  Anyways, I don't really understand the reason to have a different gamma
setting for displaying the preview image on screen and another for writing
the image data to a file. If you specify different values, you will not get
what you see, but something different.

> >   Btw, a Display_Gamma of 1.0 produces (on screen) an image which is
> > basically identical to what POV-Ray 3.6 produces, all image_maps look
> > correct, etc. Is there a reason why it cannot be the default?

> Yes, there is: It's perfectly wrong for most systems.

  Then every single program out there which displays image is wrong, and
POV-Ray is the only program which is right?

  If I take a jpeg image and view it with Firefox, ImageMagick, The Gimp,
Konqueror or basically any software in existence which is able to read and
display jpeg images, they will all show the image in the same way. However,
if I use that same jpeg image as an image_map in POV-Ray 3.7 beta, using
default settings, eliminate all lighting effects and render an image like
that, the gamma setting for that jpeg image will be completely wrong: It
looks way too light and washed out. And not just a little, but quite
significantly. Basically the image is useless that way.

  However, when I tell POV-Ray to use a Display_Gamma of 1.0, then it will
start showing the image in the exact same way as all the other programs.

  If a Display_Gamma (and, I assume, File_Gamma when it's fixed) of 1.0
is not the proper way of fixing this problem, then please tell me what is.
Because as it is now, the default setting makes image_maps completely
unusable.

  If you don't believe me, I can show you examples.

-- 
                                                          - Warp

Post a reply to this message