Le 25/09/2021 à 23:46, Kenneth a écrit :
> [Windows 10, running v3.8.0 beta 2]
> While experimenting with the Bits_Per_Color .ini file feature (I don't know what
> the command-line version is for that), and running .png renders, it seems that
> other image-viewer apps are reporting this information wrong. The images
> themselves visually show up with the correct specified bit-depth -- although not
> in POV-ray's preview window-- but the reported bit-depth does not. I tested this
> three ways:
> * The typical Windows right-click 'Properties' menu
> * I've's Lilysoft/IC app
> * Irfanview app
> For example, using...
> ....this reports as 8-bits per pixel grayscale.
> Bits_Per_Color=12 reports as 16-bit
> Another example:
> Turning off Grayscale_Output, but setting Bits_Per_Color=4, the apps report this
> as 24-bit with 8-bits per color.
> From further tests, it seems that POV-ray's .png output image files report
> elsewhere as 'only' 8-bit or 16-bit, regardless of the actual bit-depth. This
> can get really confusing, when trying to determine later what the actual
> bit-depth of a rendered image is!
> Perhaps POV-ray is writing incorrect information in its .png output files, in
> the file header for example? I haven't yet tested other file-output formats. I
> would be curious to know if this happens with rendered images in earlier
> versions of POV-ray.
The png container is the one to blame.
Nobody wants to handle partial byte shifts, so in colour mode (2 & 6
color type), it is either 8 or 16 bits per colour channel.
Notice that Grayscale output COULD use smaller than 8 bits (color type
0, but not with alpha!), yet the code to write png in povray does not
handle such exception and stay at either 8 or 16 bits per gray.
The PPM format is more respectful of pixel depth, as the actual mask is
part of the format. Yet, no shift of channel in the byte, it is one or
two bytes per channel.
Post a reply to this message