On 9/26/21 2:45 AM, Le_Forgeron wrote:
> This
> can get really confusing, when trying to determine later what the actual
> bit-depth of a rendered image is!

Adding to what Le_Forgeron said, the netpbm formats pgm(written still 
with file suffix ppm) and true ppm(1) includes in its visible header the 
true max bit depth just after the image size in the 'ascii, human 
visible' header - you can just look for the actual bit depth written in 
any netpbm image file.

No matter the program used, when netpbm formats are encoded in binary, 
only 8 or 16 channel 'storage' bit depths are used. When the ascii raw 
format is used one can save space using other than 8 or 16 bit depths 
because fewer ascii characters are needed to represent the channel values.

(1) also netpbm's pam, but POV-Ray doesn't write that format directly.

Having a handy 'max encoded channel depth' value isn't really there with 
other formats.

Aside: With the png formats though the channel storage depth is always 8 
or 16, you DO get smaller file sizes with depths of other than 8 or 16. 
This is due the compression algorithms working better - there are fewer 
actual binary value representations and the compression better works.

---
Knowing what's really in an image file is always somewhat tricky as we 
can subvert defaults in POV-Ray with options like file_gamma= or with 
image editing programs like gimp. Mangling of formats can be had with 
other tricks inside POV-Ray itself - up to and including creating your 
own sub-formats within a standard image format.

What I try to do is make any non standard encoding information part of 
the output name. For example,

povray tmp.pov +fpg10 file_gamma=1.0 +otmp_GrayLinDepth10bits

Lastly, I'll add programs like imageMagik's 'indentify -verbose tmp.png' 
dump more information about pngs such as the color_type. However, take 
care in trusting everything such utilities report. In my experience, the 
information is occasionally wrong.

Bill P.

Post a reply to this message