When a surface has a high reflection value, distinguishable circles of lighting
appear on the surface (see the linked image)

https://ibb.co/9s3xW7H

for

camera {location <0,0,-3> look_at <0,0,0> angle 45  }
light_source {<0,1,-3>  color rgb<1,1,1>  }

plane{<0,0,1>,0 pigment{ color rgb<0.2,0.2,0.2>} finish{reflection 1 } }

How can we fix this to have smooth and uniform lighting on the surface?

Post a reply to this message

On 6/28/20 9:08 PM, Kima wrote:
> When a surface has a high reflection value, distinguishable circles of lighting
> appear on the surface (see the linked image)
> 
> https://ibb.co/9s3xW7H
> 
> for
> 
> camera {location <0,0,-3> look_at <0,0,0> angle 45  }
> light_source {<0,1,-3>  color rgb<1,1,1>  }
> 
> plane{<0,0,1>,0 pigment{ color rgb<0.2,0.2,0.2>} finish{reflection 1 } }
> 
> How can we fix this to have smooth and uniform lighting on the surface?
> 
> 

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.

The ini settings are Dither=on/off, Dither_Method=??? or you can use the 
flag +th??. Just +th, I believe, defaults to the new blue noise in v3.8 
over an older less robust method. Christoph did a lot of work on output 
dithering for v3.8!

Aside: Dithering is on in the display window which makes POV-Ray itself 
a pretty good image file viewer... I posted some sample as-image-viewer 
code at the bottom of my pgm depth map patch announcement last year 
(asPGMViewer.pov):

http://news.povray.org/povray.unofficial.patches/thread/%3C5cdd97f8%241%40news.povray.org%3E/



which is pretty easily adapted to other image formats. Change the 
image_map gammas to sRGB. The gamma 1 was due the depth map usage. Ah, I 
see too I left in a background statement - harmless, but it shouldn't be 
there.

Bill P.

Post a reply to this message

hi,

"Kima" <nomail@nomail> wrote:
> When a surface has a high reflection value, distinguishable circles of lighting
> appear on the surface (see the linked image) ...
> for
>
> camera {location <0,0,-3> look_at <0,0,0> angle 45  }
> light_source {<0,1,-3>  color rgb<1,1,1>  }
>
> plane{<0,0,1>,0 pigment{ color rgb<0.2,0.2,0.2>} finish{reflection 1 } }
>
> How can we fix this to have smooth and uniform lighting on the surface?

running the above with "+q9 +am2 +a0.1 +ag1 -j"  :-), the surface lighting does
look already fairly uniform.  you could add "roughness .01" to the 'finish{}'.
(looks ok here, the '.01' may need tweaking depending on actual surface, etc)


regards, jr.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> 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.
>
> The ini settings are Dither=on/off, Dither_Method=??? or you can use the
> flag +th??. Just +th, I believe, defaults to the new blue noise in v3.8
> over an older less robust method. Christoph did a lot of work on output
> dithering for v3.8!
>
> Aside: Dithering is on in the display window which makes POV-Ray itself
> a pretty good image file viewer... I posted some sample as-image-viewer
> code at the bottom of my pgm depth map patch announcement last year
> (asPGMViewer.pov):
>
>
http://news.povray.org/povray.unofficial.patches/thread/%3C5cdd97f8%241%40news.povray.org%3E/
>
>
> which is pretty easily adapted to other image formats. Change the
> image_map gammas to sRGB. The gamma 1 was due the depth map usage. Ah, I
> see too I left in a background statement - harmless, but it shouldn't be
> there.
>
> Bill P.

Thanks Bill, +TH did the trick. It is nearly perfect. I learnt a lot.

I use the pre-compiled 3.7 on Linux. You motivated me to install 3.8 :-)

Post a reply to this message

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.

Thorsten

Post a reply to this message

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

Le 2020-06-30 à 10:35, William F Pokorny a écrit :

> 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.
> 
The 16 bit per channel don't have a greater range, it have a finer tone 
resolution.

Post a reply to this message