POV-Ray : Newsgroups : povray.binaries.images : antialiasing fails with very bright objects Server Time
29 Mar 2024 11:30:25 EDT (-0400)
  antialiasing fails with very bright objects (Message 11 to 20 of 25)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 5 Messages >>>
From: Kenneth
Subject: Re: antialiasing fails with very bright objects
Date: 15 Feb 2021 17:35:01
Message: <web.602af4871995ddafd98418910@news.povray.org>
Alain Martel <kua### [at] videotronca> wrote:

> >
> > The basic problem is that my old Photoshop apparently saves PNG files with a
> > *very* wrong embedded gamma-- 4.4 (!) ...
>
> OK then, my question is : Why did you post process your image in
> Photoshop ? You could have just posted the original, untouched, PNG.

I used PS (my 'favorite' but flawed image-editing app) only because I needed to
combine my 6 original PNG POV-ray renders into a single presentation-- along
with text notes-- for posting here. Then I saved it as PNG-- a mistake.
*Usually*, I save the resulting single image as a JPEG, but I forgot that my
older PS has a gamma problem when saving a PNG file (even though the combined
image 'looks' correct in PS and most of my other apps.)
>
> Was it to resize it ? Then, for that task, Photoshop is gross overkill.
> If I want to do that, I'd use IrfanView. It's lightweight, free, can
> perform the combining of several images as you did and properly handle
> the PNG gamma.

As strange as it seems, I've never used Irfanview for such tasks(!) I only use
it as an image viewer, and not very often; Photoshop is just more familiar to
me.

Obviously, I need to investigate what Irfanview can do. Thanks for the 'nudge'
;-)


Post a reply to this message

From: William F Pokorny
Subject: Re: antialiasing fails with very bright objects
Date: 17 Feb 2021 11:04:12
Message: <602d3e7c$1@news.povray.org>
On 2/14/21 9:48 AM, William F Pokorny wrote:
> On 2/13/21 6:39 AM, William F Pokorny wrote:
>> On 2/11/21 2:12 PM, Kenneth wrote:
> ...
>>
>> When I write to exr or hdr I was expecting linear encoded values, but 
>> this is not what I see...
>>
..
>>
>> I believe exr and hdr input and output are supposed to be linear. 
> 
> Comments in the code say this is the intent. It is not what is happening 
> on write...
> 

Got back to looking at this - and I got EXACTLY what I asked for in my 
coding in the scene file! All is good with POV-Ray.

I thought I was using linear encoding for the emission colors, but I was 
actually using srgb... (a)

My personal discoveries related to the exr(as used) and hdr formats not 
being useful for other than expressing dynamic range, stand. In other 
words, don't use these two formats for height fields and such.

Bill P.

(a) Growing up my family owned a small, single crew, tree service and 
one of my brothers has a small tree service of his own. A decade or more 
ago he suggested I read the book, "The Wild Trees." In it there's a 
story about an experienced climber taking a fall - while still thinking 
to yell "headache!" to those on the ground. His reason for falling came 
to being in that place where you trust your own skill too much. Twice in 
the last month that's been me with simple, quick scene files. My 
apologies for the false alarms. Please imagine, "HEADACHE!!!" in the 
subject line for my next post (or two) about there being a problem with 
POV-Ray. :-)


Post a reply to this message

From: Kenneth
Subject: Re: antialiasing fails with very bright objects
Date: 17 Feb 2021 15:40:01
Message: <web.602d7df01995ddafd98418910@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/11/21 2:12 PM, Kenneth wrote:

> > I don't think the failed AA is simply the result of a difference
> > in contrast/brightness with surrounding darker pixels.

> At the time AA is done it knows about the color channel values and nothing
> more. With color values >>1 there simply is a massive difference between
> adjacent pixels. If you have say emission 10 even with some sort of
> bloom / blend, you'll need consume 10 or more pixels around the ultra
> bright regions to get into a range were you'd get AA on the '<=1.0' edge.
>

Yes, I understand that now; and I was wrong to say that the surrounding darker
pixels have no effect on the 'lack of AA' of super-bright ones. They obviously
do, from visual tests. Making the surrounding pixels brighter helps to improve
the failed AA.

And the idea of simply 'clamping' very-bright pixels to <1,1,1> is rather naive,
I admit. There are probably many lighting/color situations where only one of the
color-vector values ends up >> 1.0-- in which case, simply clamping the highest
vector value to 1.0 may shift the intended (expected?) color, unless some other
'equalizing' scheme is brought into play to shift the other two values in a
subtle way. [This is just my 'thought experiment', based on nothing but
intuition ;-) ]


Post a reply to this message

From: Thomas de Groot
Subject: Re: antialiasing fails with very bright objects
Date: 18 Feb 2021 02:27:50
Message: <602e16f6$1@news.povray.org>
Op 17/02/2021 om 17:04 schreef William F Pokorny:
> On 2/14/21 9:48 AM, William F Pokorny wrote:
>> On 2/13/21 6:39 AM, William F Pokorny wrote:
>>> On 2/11/21 2:12 PM, Kenneth wrote:
>> ...
>>>
>>> When I write to exr or hdr I was expecting linear encoded values, but 
>>> this is not what I see...
>>>
> ..
>>>
>>> I believe exr and hdr input and output are supposed to be linear. 
>>
>> Comments in the code say this is the intent. It is not what is 
>> happening on write...
>>
> 
> Got back to looking at this - and I got EXACTLY what I asked for in my 
> coding in the scene file! All is good with POV-Ray.
> 
> I thought I was using linear encoding for the emission colors, but I was 
> actually using srgb... (a)
> 
> My personal discoveries related to the exr(as used) and hdr formats not 
> being useful for other than expressing dynamic range, stand. In other 
> words, don't use these two formats for height fields and such.
> 

Yes, that is what I had always thought indeed.

> 
> (a) Growing up my family owned a small, single crew, tree service and 
> one of my brothers has a small tree service of his own. A decade or more 
> ago he suggested I read the book, "The Wild Trees." In it there's a 
> story about an experienced climber taking a fall - while still thinking 
> to yell "headache!" to those on the ground. His reason for falling came 
> to being in that place where you trust your own skill too much. Twice in 
> the last month that's been me with simple, quick scene files. My 
> apologies for the false alarms. Please imagine, "HEADACHE!!!" in the 
> subject line for my next post (or two) about there being a problem with 
> POV-Ray. :-)
> 

Noted.



-- 
Thomas


Post a reply to this message

From: Kenneth
Subject: Re: antialiasing fails with very bright objects
Date: 19 Feb 2021 16:05:06
Message: <web.6030274d1995ddafd98418910@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
>
> ...My apologies for the false alarms. Please imagine, "HEADACHE!!!" in the
> subject line for my next post (or two) about there being a problem with
> POV-Ray. :-)


Your ideas and detailed code-analysis presentations are *always* of interest, so
don't hesitate to speak up and bring them to our attention. Keep up the good
work with povr!


Post a reply to this message

From: Kenneth
Subject: Re: antialiasing fails with very bright objects
Date: 23 Feb 2021 22:05:01
Message: <web.6035c02b1995ddafd98418910@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> Kenneth wrote:
> >
> > When image pixels go over <1,1,1> in brightness (regardless of how),
> > antialiasing starts to fail, both in the on-screen preview
> > and in the saved image file.
>
> ...At the time AA is done it knows about the color channel values and
> > nothing more. With color values >>1 there simply is a massive difference
> > between adjacent pixels.

You have given me an idea for what might be a useful feature (and feature
request!): A way to visually determine which pixels in a render have gone over a
certain brightness limit (to see where AA might fail, among other uses). This
would be for typical low-dynamic-range renders, not HDR where the idea may not
work as intended(?)

Let's say that I create a scene with many different light sources (spotlights,
fill lights, radiosity, etc.), and lots of objects with complex textures and
colors. With all of this stuff going on and interacting, it is sometimes
difficult to know exactly where the lighting of a scene is creating pixels that
are too bright, or where the colors have unintentionally washed out.  Of course,
some of this effect may BE intentional; but let's assume that it isn't. (For
simplicity' sake, assume the pixel brightness limit to be anything greater than
<1,1,1> or <0.3,0.6,1.0> -- any vector component that exceeds 1.0)

It would  be useful to have an optional 'switch' during render tests to actually
SEE which pixels are the problem ones. The idea would be to render the scene as
a pixel-by-pixel 'histogram' of sorts-- instead of the usual colorful render--
showing exactly where the lighting has gone over-limit. (For example, to pick
out a pixel that somehow ends up as <1.7,1.7,1.7>, or <0.3,0.5,1.9> or
whatever). To save on render time, this would be done before any final AA is
applied.

Once we can see where the lighting problems are, we can then go back and re-work
the lighting/textures to try and fix them.

For my example render, I've simply pumped up the lighting of the single
light_source, to mimic what multiple light sources might do when they interact
unintentionally. The 'histograms' are just Photoshop mock-ups of what I envsion
to be the result-- either in color, or equally useful as grayscale.

I don't know how this feature would be implemented within POV-ray, but it seems
possible(?)


Post a reply to this message


Attachments:
Download 'histogram_idea.jpg' (156 KB)

Preview of image 'histogram_idea.jpg'
histogram_idea.jpg


 

From: Bald Eagle
Subject: Re: antialiasing fails with very bright objects
Date: 23 Feb 2021 23:10:01
Message: <web.6035d08b1995ddaf1f9dae300@news.povray.org>
Functions.

Render your scene, then paste the filename into the provided spot.

Render this scene.
I think it _ought_ to do what you want.


#version 3.8;
global_settings {assumed_gamma 1.0}

#declare Zoom = 60; // 15
camera {
 orthographic
 right     x*image_width/Zoom
 up   y*image_height/Zoom
 location <0, 0, -20>  // x = 5
 look_at  <0, 0, 0>
 //rotate -y*1
}

light_source { <0, 0, -20>  color rgb <1, 1, 1>}

sky_sphere {pigment {rgb 1}}

//=====================================================================================================================
==

#declare Filename = "/home/oem/Documents/POV-Ray-3.8/PovLogo.png";
#declare ImageMap = pigment {image_map {Filename}}
#declare Pattern2 = function {pigment {image_map {Filename}}}

#declare f_red = function {max(Pattern2 (x, y, z).red, 1)-1}
#declare f_grn = function {max(Pattern2 (x, y, z).green, 1)-1}
#declare f_blu = function {max(Pattern2 (x, y, z).blue, 1)-1}

#declare OverOne = function {max(f_red (x,y,z), f_grn (x,y,z), f_blu (x,y,z))}


#declare Pigment2 =
pigment {
 function {OverOne (x, y, z)}
 color_map {
  [ 0 rgb 0 ]
  [ 1 rgb 1 ]
 }
}

#declare Resolution = max_extent (ImageMap);
#declare Resolution = Resolution + <0, 0, 1>;

box {0, 1
 pigment {Pigment2}
 translate <-0.5, -0.5, -0.5>
 scale Resolution*(1/Resolution.x)
}


Post a reply to this message

From: Kenneth
Subject: Re: antialiasing fails with very bright objects
Date: 24 Feb 2021 03:05:02
Message: <web.603605031995ddafd98418910@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Functions.
>
> Render your scene, then paste the filename into the provided spot.
>
> Render this scene.
> I think it _ought_ to do what you want.
> [code]
>

That's a valiant effort, and a clever use of functions! Especially with the use
of max(...)

[Btw, I couldn't get my own version of your
      #declare Filename = ... file path ...
to work in Windows, despite multiple tries and guesses; obviously some kind of
arcane syntax problem at my end that I haven't yet solved]

As far as I can tell, the intention of your code is to take a *pre-rendered*
image and find the brightest pixels => 1.0 (or more specifically, which color
component goes over that limit.) The three functions...
           #declare f_red = function {max(Pattern2 (x, y, z).red, 1)-1}
                        etc.
.......look like they expect to see values *over* 1.0, and to give the result as
the additional amount.

Unfortunately, what I see is a totally black render when I plug in a typical LDR
image. That's to be expected, though-- unless I'm wrong about your intention--
since an already-rendered LDR image has all of its pixels at or below 1.0, as
the image file (and monitor) can only reproduce colors in the 0-1 range.

(Maybe you had HDR images in mind instead?)

I re-worked a few things in the code to get your intended(?) result (re: using a
pre-rendered LDR image), and it works quite nicely: Pixels *approaching* 1.0 are
picked out. Cool!

But trying to determine which pixels are too bright *while* rendering involves
POV-ray's inner workings; as William alluded to, the scene's pixel values
(*prior* to being written to a file or to the preview screen) can easily exceed
1.0... hence the 'failed AA' effect, for example. I guess that they are clipped
to that maximum only when the file is written, or when the preview can't
reproduce them as-is.

In any case, here's my minor re-working of your code for LDR images...which
looks to be useful in and of itself. No light_source needed. Thanks for the
brain-boost ;-)
------------
#version 3.8;
global_settings {assumed_gamma 1.0}
background{rgb <.2,.2,.25>}

camera {
  perspective
  location  <0, 0, -1>
  look_at   <0, 0,  0>
  right     x*image_width/image_height  // aspect
}

#declare Pattern2 = function {pigment {image_map {png "my_image.png"}}}

#declare f_red = function {max(Pattern2 (x, y, z).red, .9999) - 1}
#declare f_grn = function {max(Pattern2 (x, y, z).green, .9999) -1}
#declare f_blu = function {max(Pattern2 (x, y, z).blue, .9999)-1}

#declare OverOne = function {max(f_red (x,y,z), f_grn (x,y,z), f_blu (x,y,z))}

#declare Pigment2 =
pigment {
 function {OverOne (x, y, z)}
 color_map {
// I reversed the color order here, to get a 'positive' image,
// so the brightest pixels show up white instead of black
  [ 0 rgb 1 ]
  [ 1 rgb 0 ]
 }
}

#declare Resolution = max_extent (ImageMap);
#declare Resolution = Resolution + <0, 0, 1>;

box {0, 1
texture{
 pigment {Pigment2}
 finish{ambient 1 emission 0 diffuse 0}
 }
 translate <-0.5, -0.5, -0.5>
 scale Resolution*(1/Resolution.x)
}


Post a reply to this message


Attachments:
Download 'brightest_pixels_test_1.jpg' (77 KB)

Preview of image 'brightest_pixels_test_1.jpg'
brightest_pixels_test_1.jpg


 

From: Bald Eagle
Subject: Re: antialiasing fails with very bright objects
Date: 24 Feb 2021 06:40:00
Message: <web.603639e01995ddaf1f9dae300@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:

> [Btw, I couldn't get my own version of your
>       #declare Filename = ... file path ...
> to work in Windows, despite multiple tries and guesses; obviously some kind of
> arcane syntax problem at my end that I haven't yet solved]

I know there's the thing with the forward/backward slashes in paths...

> As far as I can tell, the intention of your code is to take a *pre-rendered*
> image and find the brightest pixels => 1.0 (or more specifically, which color
> component goes over that limit.) The three functions...
>            #declare f_red = function {max(Pattern2 (x, y, z).red, 1)-1}
>                         etc.
> .......look like they expect to see values *over* 1.0, and to give the result as
> the additional amount.

Right-o.  Anything with a component over 1 is the only part that would show up.

> Unfortunately, what I see is a totally black render when I plug in a typical LDR
> image. That's to be expected, though-- unless I'm wrong about your intention--
> since an already-rendered LDR image has all of its pixels at or below 1.0, as
> the image file (and monitor) can only reproduce colors in the 0-1 range.

Hmmm.   I thought POV-Ray could write color values to a file that were over 1.
I certainly know from all my reading and poking around in the source code and
working with the gamma and color values that the industry algorithms have sanity
checks for values over 1...

> (Maybe you had HDR images in mind instead?)
>
> I re-worked a few things in the code to get your intended(?) result (re: using a
> pre-rendered LDR image), and it works quite nicely: Pixels *approaching* 1.0 are
> picked out. Cool!

Define a multiplier for the function right before the 1 is subtracted.
I faked an HDR image by using >1 on the blue channel.  Take your multiplier and
use a variable so you don't have to change all 3 when you want to tweak it.

> But trying to determine which pixels are too bright *while* rendering involves
> POV-ray's inner workings; as William alluded to, the scene's pixel values
> (*prior* to being written to a file or to the preview screen) can easily exceed
> 1.0... hence the 'failed AA' effect, for example. I guess that they are clipped
> to that maximum only when the file is written, or when the preview can't
> reproduce them as-is.

Is there a way to render it as "HDR" and without any antialiasing first, and
then re-render /post-process it WITH aa?
Maybe along the lines of what I'm doing here, or an image convolution kernel or
something.


#declare M = 0.9999;
> #declare f_red = function {max(Pattern2 (x, y, z).red, 1)*M - 1}
> #declare f_grn = function {max(Pattern2 (x, y, z).green, 1)*M - 1}
> #declare f_blu = function {max(Pattern2 (x, y, z).blue, 1)*M - 1}


> // I reversed the color order here, to get a 'positive' image,
> // so the brightest pixels show up white instead of black
>   [ 0 rgb 1 ]
>   [ 1 rgb 0 ]
>  }
> }

Odd, since the result of the function should provide 0 for LDR images, and white
for anything over 1 - the fractional component.
It seemed to work that way for me with my version, but it was a last-minute
late-night hack, so maybe I double-reversed something....

Set M to 1.1 and see what happens... oh, I see now.
When you use your subtraction method inside the function, your max is now less
than 1.  Then you subtract 1 and get a _negative_ value.   That dips into the
color map from the top, not the bottom, which is why you get backwards results.
Use the *M version that I posted an the original color map, and all should be
well.


Post a reply to this message

From: Kenneth
Subject: Re: antialiasing fails with very bright objects
Date: 24 Feb 2021 19:55:00
Message: <web.6036f2331995ddafd98418910@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > [Btw, I couldn't get my own version of your
> >       #declare Filename = ... file path ...
> > to work in Windows, despite multiple tries and guesses...]
>
> I know there's the thing with the forward/backward slashes in paths...

I finally got it to work (which is a major accomplishment for me, ha):
using DOUBLE backward slashes in Windows-- which is actualy mentioned in the
docs...
#declare Filename =
"C:\\Users\\Computer\\Documents\\Kens new POV-Ray scenes\\A1.png"

Double FORWARD slashes work too.

>
> Hmmm. I thought POV-Ray could write color values to a file that were over 1.

As far as *I* know (which isn't saying a lot), typical LDR image files like JPEG
and PNG top out at 255/255. Which makes sense, as to their final presentation on
a typical monitor.

> > But trying to determine which pixels are too bright *while* rendering
> > involves POV-ray's inner workings; as William alluded to, the scene's
> > pixel values (*prior* to being written to a file or to the preview screen)
> > can easily exceed 1.0... hence the 'failed AA' effect, for example. I guess
> > that they are clipped to that maximum only when the file is written, or
> > when the preview can't reproduce them as-is.

I've been rolling that seeming caveat around in my head since I posted it-- and
I now think I'm wrong: Once the too-bright pixels ARE eventually clipped to 1.0
maximum for the image file (and/or preview), the end result is just fine for
post-processing with the re-worked code here-- to find the brightest pixels. I
can't visualize any difference between that, and doing the same thing
'internally' in POV-ray like I initially imagined. The only difference I see is
that the code picks out pixels *at* 1.0 brightness, rather than > 1.0. But that
doesn't seem to be a deal-breaker, as to the code's intended use. As I reflect
more on the subtleties, I may turn out to be mistaken-- but the code seems to do
exactly what I envisioned... albeit *as* a post-processing step. But that's not
too painful a compromise ;-)

> > // I reversed the color order here, to get a 'positive' image,
> > // so the brightest pixels show up white instead of black
> >   [ 0 rgb 1 ]
> >   [ 1 rgb 0 ]
> >  }
> > }
>
> Odd, since the result of the function should provide 0 for LDR images,
> and white for anything over 1... oh, I see now.
> When you use your subtraction method inside the function, your max is now less
> than 1.  Then you subtract 1 and get a _negative_ value. That dips into the
> color map from the top, not the bottom, which is why you get backwards
> results...

Ha, I'm glad you figured that out; for me, it was just mucking around with
things until I got what looked like a good result! :-O

> Use the *M version that I posted an the original color map, and all should be
> well.

I'll give that a try.

BTW, I noticed something about my image results that makes me wonder about how
the max(...) function operates on other *functions*...

#declare OverOne = function{max(f_red (x,y,z), f_grn (x,y,z), f_blu (x,y,z))}

It seems that if every entry in max(...) is actually EQUAL, the overall function
returns all THREE values (combined? added?), not just one. I'm out of my depth
here, though; maybe that's how max always treats equal values(?), even if
they're just floats. But that's not a problem with the *code's* use; it works as
planned.

I've attached an image to illustrate this.


Post a reply to this message


Attachments:
Download 'max_result_with_functions.jpg' (93 KB)

Preview of image 'max_result_with_functions.jpg'
max_result_with_functions.jpg


 

<<< Previous 10 Messages Goto Latest 10 Messages Next 5 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.