William F Pokorny <ano### [at] anonymousorg> wrote:
> 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.

I need to look into this! That format has been a complete unknown to me, until
now. Thanks.

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

So it seems; that's suprising to me.
>
> 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.

I'm still testing the various .png bit-depths (by generating test images for
height_fields). The different visual results between, say, 8-bit and 10-bit is
difficult to see so far...and right now I'm not *sure* that 10-bit is really
10-bit, or some other value. With the screwy bit-depth-reporting that I
mentioned, I haven't been absolutely sure of my own visual judgement!
>
> ---
> 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...

Yes, very true. I have a common practice of 'correcting' images that I stick
into POV-ray-- via gamma adjustments or 'levels' or some such, in external
apps-- when I don't like the way they look. (For example, with a grayscale image
that I want to use for a height_field: If it's composed mostly of middle grays,
or is perhaps too dark, I'll 'stretch' its values between black and white, for a
more even distribution.) Or by the newer gamma adjustments for image_maps.
>
> What I try to do is make any non standard encoding information part of
> the output name.

Yep, that's the only recourse that I've been using as well, for my tests... when
I can remember to do so :-[

Post a reply to this message