On 3/4/23 07:49, Thomas de Groot wrote:
> adding gamma 1 to the image_map is still essential and makes a 
> difference whether you use it or not

The latter part about it making a difference can certainly be true.

It only needs to be 'gamma 1', if the file was created in a linear color 
space(a). The default output and input is 'gamma srgb' in v3.8/v4.0 - 
excepting hdri file formats at 'gamma 1' and netpbm formats which use 
'gamma bt709' by default(b).

The above a lie, if you want to use odd file gammas for effect. You can, 
for example, specify a 'gamma <value>' and stick whatever you want in 
there for a positive value.

That said. Practically, it's true the majority of the image files coming 
from models we pick up somewhere out and about are written in the linear 
color space. For those you do need to always use 'gamma 1' because they 
were written with the expectation they'd be read as 'gamma 1' files.

Bill P.

--- More detail...

(a) - There was/is a bug in the v3.8/v4.0 branches were png files were 
being written without the srgb block unless the render was invoked with 
file_gamma=srgb. It's fixed in povr, I do not know the current status in 
v3.8 beta 2 or v4.0 master. The block is something you can see - or not 
- by editing a png file. Amongst the gibberish, look for the text 'sRGB' 
almost immediately following 'gAMA' near the top. If you see it, you 
have the sRGB block.

If you don't see and are using v3.8/v4.0 defaults you should code 'gamma 
srgb' while reading / using such POV-Ray created pngs. And/or be sure to 
use file_gamma=srgb on writing pngs.

(b) - Yes, there was another bug POV-ray v3.8/v4.0 which is patched in 
povr for netpbm file formats of .ppm and .pgm. The gamma wasn't 
defaulting properly on write or read - I cannot remember which at the 
moment.

---
Aside: With both (a) & (b) bugs, the reality is you might see the 
differences or not depending on stuff. Ignorance is bliss until the 
truck runs you over. A lot of truth too in, "if it looks good, it is 
good."

A test I sometimes run is to write file formats from povr, then 
immediately read that file back in sort of a SDL povr/POV-Ray image 
display tool where I again write the image file using a different name 
from the first written. I now have two files I can compare image to 
image which should be very near identical. Once in a while they're not.

Post a reply to this message