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