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


> Setup was as follows:
> 
> - added another plane to that gamma test shot
> - mapped the (.png) *output* of a previous run to that plane
> - size the texture so that antialiasing would kick in on the checkered part
> 
> Antialias did kick in on the texture, and did blur the checkered parts to what I
> guess was a nice 50% grey - but the circle in the texture came out significantly
> brighter than the original sphere, and so did the upper parts of the texture,
> creating a prominent gradient.
> 
> Using the described procedure to convert to HDR did fix this issue. But the
> proper gamma to choose in HDRShop did *not* depend on the File_Gamma with which
> the file was *created*, but rather with which it was to be *used*.
> 
> 
> Try for yourself.
> 
> I guess that's why it is "File_Gamma", and not "Output_File_Gamma".
> 
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.


> I guess you're somewhat mistaken here: From all I see, the .HDR format *does*
> seem to be able to use a gamma encoding for the pixel values, as specified in
> the optional "GAMMA=..." header string. (I don't know what the default is, but
> it may well be 1.0, i.e. linear encoding.)
> 
Read the RADIANCE documentation about this, for short a RADIANCE HDR 
file is always linear no matter what.


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


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


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


> .... and probably doesn't work either (see above).

Nope. This definitely works (for exactly the same reason Radiance does 
work) and I have no intention of getting into a fight about this because 
both of our 'solutions' use the same workarounds to overcome some 
serious limitations POV-Ray has in this regard.


> 
> (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... ;)

-Ive

Post a reply to this message