On 3/20/21 1:31 PM, William F Pokorny wrote:
...
> 
> ---  png gamma issue.
...
> 
With respect to the current v3.8 not writing a png srgb gamma block 
unless somewhere File_Gamma is set to 'srgb', the current v3.7 looks to 
be OK. If the gamma correction used was srgb, explictly or not, the srgb 
block is always written.

Somewhere during the v3.71 / v3.8 work something changed - but I cannot 
pick up the cause just reading the code. And! this time I'm not going to 
spend 3-4 hours compiling different historical commits to try which 
commit broke things.

The fix in the png.cpp file is to change:

#if defined(PNG_WRITE_sRGB_SUPPORTED)
     if (options.encodingGamma &&
             typeid(*options.encodingGamma) == typeid(SRGBGammaCurve))
         png_set_sRGB(png_ptr, info_ptr, PNG_sRGB_INTENT_PERCEPTUAL);
#endif // PNG_WRITE_gAMA_SUPPORTED

to read:

#if defined(PNG_WRITE_sRGB_SUPPORTED)
     if ((!options.encodingGamma) ||
         (options.encodingGamma &&
          typeid(*options.encodingGamma) == typeid(SRGBGammaCurve)))
     {
         png_set_sRGB(png_ptr, info_ptr, PNG_sRGB_INTENT_PERCEPTUAL);
     }
#endif // PNG_WRITE_gAMA_SUPPORTED


With this update above the color render and viewer v3.8 outputs match 
whether File_Gamma explicitly set to srgb or not.

The grey scale too is better as shown in the attached image. The top row 
less the fix above and the bottom row with the fix. There is still 
something off related to non-grey defined colors in the render.pov 
result leading to different between render and viewer by as much as 
11/255(1). I don't understand what is happening there as yet...

(1) - Prior to the srgb gamma chunk fix the max color differences where 
9/255 at very low luminance.

With the previously posted grey output pgm/ppm fix, both the color and 
greyscale ppm outputs match so long as 'gamma=bt709' is used when 
defining the image_map (reading the POV-Ray created image file). The 
netpbm format doesn't encode the gamma on write - so you have no choice 
but to be explicit on the read if you want to be sure you match.

Aside 1: Don't trust ImgeMagick's identify command with respect to the 
srgb block being there or not. It's wrong when I run it. The iinfo 
command from the OpenImageIO package works OK. Or you can just edit the 
generated png with a text editor; this looks really ugly but if the sRGB 
chunk is being written you'll see 'sRGB' between the readable text 
'gAMA' and 'sBIT' right at the top. (Gimp, for me, is also not reporting 
all the meta data completely/correctly)

Aside 2: For those running stock v37/v38, I guess my recommendation 
would be to use linear gamma explicitly coded where you want to write an 
image file you'll later use (read) within POV-Ray. If only writing a png 
file, and using stock v3.8 be sure to use File_Gamma=srgb, if you want 
to be sure you have the srgb gamma block for downstream tools. Remember 
too Christoph corrected quite a lot post v3.7 in how the file gamma's 
are handled, but for color at least it looks to me like v3.7 png output 
OK. V3.7 image file input is another matter.

More on the png greyscale (single channel png) differences when I 
decipher more.

Bill P.

Post a reply to this message

Attachments:
Download 'pnggreymoretodo.png' (21 KB)

Preview of image 'pnggreymoretodo.png'