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