POV-Ray : Newsgroups : povray.text.tutorials : How To do Proper Gamma in POV-Ray 3.7 : Re: How To do Proper Gamma in POV-Ray 3.7 Server Time
18 Sep 2021 01:06:19 EDT (-0400)
  Re: How To do Proper Gamma in POV-Ray 3.7  
From: clipka
Date: 18 Jun 2009 08:45:00
Message: <web.4a3a34f8b683ece6e01952250@news.povray.org>
Ive <"ive### [at] lilysoftorg"> wrote:
> >> why would this be a good choice?
> >
> > Because chances are that your standard image viewers don't care about gamma.
> >
> So what you mean is: it's a good choice because some people might use a
> crappy piece of software. Seems not like a good advice to me.

Note that I didn't call it a good choice - I called it not a bad choice. It
depends on what you want to do with the image. I warned about the consequences,
so I see no problem there.

> You are using the output file as input file so how can this be a proof
> that File_Gamma does effect the file used as image_map on input? Try a
> much simpler test by just using any jpeg file as image_map, use various
> settings for File_Gamma, keep Display_Gamma the same and compare.

That's a bad suggestion, because it will change the output file gamma, and
therefore make the output files not comparable anyway.

What I observed was that

(1) The output file didn't work as input file.

(2) Processing the file as described did the job, provided that the "display
curve" value used in the generation of the HDR file matched the File_Gamma

(3) When changing the File_Gamma between generation of the image and using it as
input file, the process worked fine when using the new File_Gamma setting, but
did not when using the old value.

The first is proof that POV-Ray's gamma handling is still far from ideal.

The second and third, combined, are proof that there is *some* effect of
File_Gamma on *input* files - even if this is the case only for HDR images.

Note that the effects observed when using the image as input are clearly
indicative of a problem either with the input material, or the process of
coverting the input material to linear color space.

If the fix depends on a particular POV-Ray setting at the time the file is used
as *input*, it is also indicative of this setting affecting the conversion of
input material to linear color space.

Any logical loopholes I'm missing here?

> > At any rate, even though it may appear queer (it does to me), the approach I
> > described *does* do some good.
> >
> > As you say yourself: Try it out!
> No need to try, it is obvious that this does work, I do not even see
> what seems so queer to you, I just mentioned some back drafts.

I wouldn't be that perplexed if the correction to be applied would depend on the
File_Gamma with which a file was *created* - but for some mysterious reason the
proper value to supply to HDRShop depends on the File_Gamma with which the file
is to be *used*.

> > Note however that this loss of dynamic range primarily applies to low color
> > component values in an otherwise comparatively bright color (for dark colors,
> > all components will be scaled up and E adjusted accordingly), and therefore has
> > not much effect on overall brightness or color anyway.
> Huh. There is no loss of dynamic range (how should it) there is 'just'
> some loss of information caused by the way data is stored.

If you interpret that information loss as noise, we're talking about dynamic
range again.

> > What's the point in having perfect ICC profile handling if POV-Ray gets the
> > gamma wrong.
> In many cases (and ALL files created by e.g. Photoshop, or MOST files as
> distributed within Poser or by DAZ) POV-Ray gets the gamma wrong
> *because* it cannot handle ICC color profiles.

May well be. But I'm talking about solutions here, not root causes. And if that
solution gets the Gamma fixed at the cost of the ICC information, then I say
it's a comparatively small price to pay. (Although of course I agree that it
would be better to have both right.)

> In fact POV-Ray only gets the gamma right when it uses a PNG file that
> does include a gamma-chunk (but ONLY in this case), the sRGB-chunk, the
> chromaticity-chunk and the ICC-chunk are ignored by POV-Ray and therefor
> it does not work correctly with a PNG as e.g. written by Photoshop CS3.
> And POV-Ray gets Radiance and OpenEXR right because it correctly assumes
> a linear color space there.

Interestingly enough, it even gets the gamma from its own output wrong.

> > (Whatever IC is, anyway...)
> And I was pretty sure you have visited my HP, maybe you should look
> around a bit next time when you are there... ;)

Now that Thomas pointed me there, I found out that I did see the site earlier.
"IC" didn't stick with me though.

Post a reply to this message

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