[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...
Grayscale_Output=true
Bits_Per_Color=4
....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.

Post a reply to this message

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...
> Grayscale_Output=true
> Bits_Per_Color=4
> ....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.

See :

https://stackoverflow.com/questions/55978230/how-to-query-the-bit-depth-of-a-png

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

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

Le_Forgeron <jgr### [at] freefr> wrote:
>
> 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.

Aha! So the fault is not with POV-ray (my mistake, mea culpa), but with the .png
container itself. A strange situation, that.
>
> See :
>
> https://stackoverflow.com/questions/55978230/how-to-query-the-bit-depth-of-a-png

Egads, the code example there looks mighty complex (to me!)

I find it surprising that in the Year 2021, the powers-that-be who created the
..png format have not yet made a simple little tool or app-- maybe for Windows
:-) -- that would allow us to easily query the true bit-depth of a created
image. I wonder why? It's such a commonly-used format, with many different uses.
>
>
> The PPM format is more respectful of pixel depth...

I've never rendered with that; I thought it was specifically for the Unix
platform, but I've never researched it. I see in the docs that POV-ray can both
render that file type and use it for height_fields.

Post a reply to this message

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

"Kenneth" <kdw### [at] gmailcom> wrote:

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

If I were to do it, I'd make a staircase from one side of the source image to
the other and look at the resulting heightfield from the side.  Then it would be
a "graph" of the numerical data.  Contrasting gridlines would eliminate any
ambiguity int the visual judgement part.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > I'm still testing the various .png bit-depths (by generating test images for
> > height_fields)...
>
> If I were to do it, I'd make a staircase from one side of the source image to
> the other and look at the resulting heightfield from the side.  Then it would be
> a "graph" of the numerical data.  Contrasting gridlines would eliminate any
> ambiguity int the visual judgement part.

Heh heh, that was exactly my thought as well, although I ended up using a
slightly different method. Brilliant minds named Walker sometimes think alike--
well, uh, every now and then-- you usually think circles around me, ha.

*Ideally*, for testing a 16-bit grayscale-output image (to then make a
height_field for examination), I would need to render at least the vertical
dimension of the image at a res of 65,536 pixels-- to *clearly* see the steps
vs. some other bit depth. I actually tried such a test-image render-- and
POV-ray crashed and burned :-O   I kind of expected that.

SO, thinking more practically, I rendered a 2500X2500 image using the 'bumps'
pattern... testing every bit-depth from 4 - 16... then exaggerated the height of
the resulting HFs and zoomed-in with the camera, to see the individual steps.
Not ideal, but successful.

I'm happy to say that POV-ray does indeed render its grayscale images at each
individual bit-depth. :-) With no 'gaps' re: the way that other image-viewer
apps are reporting it.

I can rest now!

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> *Ideally*, for testing a 16-bit grayscale-output image (to then make a
> height_field for examination), I would need to render at least the vertical
> dimension of the image at a res of 65,536 pixels-- to *clearly* see the steps
> vs. some other bit depth. I actually tried such a test-image render-- and
> POV-ray crashed and burned :-O   I kind of expected that.


So did I.  But you don't have to render them all at once.
Do an animation and shift the camera to render different sections and "ascend
the staircase" one chunk at a time.



> I can rest now!
You think so, eh, slacker?
As long as POV-Ray is around you have a lot of work ahead of you....   ;)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> As long as POV-Ray is around you have a lot of work ahead of you....   ;)

Funny you should mention that:
I currently have at least four major experiments going, in various states of
(in)completion, that I'm itching to post about...

* more stuff about radiosity in animation (and rad itself)
* an interesting discovery concerning the recent "Luna Moon" post, about that
NASA 16-bit .tiff height-map
* an update about our old discussion (with Tor Olav) of Point_At_Trans() and
VPerp_To_Vector
* using the 'object pattern' in media (which is very cool)

It's unfortunate that I have to sleep at least *sometime* ;-)

Post a reply to this message