On 6/30/20 3:19 AM, Thorsten wrote:
> On 29.06.2020 12:26, William F Pokorny wrote:
>> Hi, Take a look at output file dithering in the documentation. Color 
>> banding happens due there not being enough color channel depth in most 
>> any output file format - exr being the exception - for close color 
>> gradients. And given display / code limitations, you'll sometimes see 
>> banding with exr viewers too.
> 
> Actually, setting the output to 16 bit per color component PNG would be 
> sufficient and has been available since POV-Ray 3.0.
> 

It's good to point out the 16 bit per channel png output - and the hdr 
output is in that depth class too. The obvious cost to the higher bit 
depths over dithering is storage. Certainly there are occasions where 
using 16 bit depth output is exactly what's needed.

---
Aside: I think we too often toss out 16 bits as enough depth for any 
POV-Ray related application. In my experience 16 bits is only sometimes 
enough channel depth.

It depends on what you are doing with the image after output or with one 
as input. Also on what sort on image it is and what dynamic range it 
represents.

When I was playing with lidar elevation files some years ago I needed 19 
bits to not see banding/posterization in the local isosurface window. I 
wrote some custom image/function code to implement that depth.

Recently I was playing with 3 image outputs(1) of parametrics both as a 
possible alternative approach to Jerome's new UVMeshable approach and as
a possible alternative representation. Even the floats of the exr format 
are not enough for the parametric -> 3ximages -> isosurface without 
banding (shadow artifacts) in the isosurface. The 23 bits worth of steps 
is not enough for surfaces/surface-portions with curvature.

(1) - In povr I can create images representing the positive and negative 
function values using two color channels.

If we want someday to represent user defined / function defined cameras 
with point sets easily transformable with good performance we are going 
to need a 64bit double depth format storage accessible to functions - 
and so parsing - whether it be 'psuedo-image' based or something custom.

I've played a lot with df3 based isosurfaces and the 8 and 16 bit depths 
are sometimes just not enough. The more blob-y the interpolations of 
povr can sometimes hide the banding, but then less is re-presentable.

Anyway... I'll get off my 16 bits isn't always enough soapbox, as folks 
say. :-)

Bill P.

Post a reply to this message