POV-Ray : Newsgroups : povray.binaries.images : am3 test image Server Time
29 Mar 2024 09:33:35 EDT (-0400)
  am3 test image (Message 1 to 6 of 6)  
From: Ash Holsenback
Subject: am3 test image
Date: 24 Sep 2020 14:31:22
Message: <5f6ce5fa@news.povray.org>
image is a comparison of the tracetask.cpp fix that bill ask us to 
try... working with 3.8.0-alpha.10064268. saved aside before and after 
images and did a compare:


Post a reply to this message


Attachments:
Download 'am3diff.png' (3254 KB)

Preview of image 'am3diff.png'
am3diff.png


 

From: William F Pokorny
Subject: Re: am3 test image
Date: 25 Sep 2020 09:00:34
Message: <5f6de9f2@news.povray.org>
On 9/24/20 2:31 PM, Ash Holsenback wrote:
> image is a comparison of the tracetask.cpp fix that bill ask us to 
> try... working with 3.8.0-alpha.10064268. saved aside before and after 
> images and did a compare:
> 
> 

Thanks.

Did you happen to capture the CPU times for the two renders?

Did you use -j, +ss and +wt1 on both renders?

Were you using area lights?

---
Your compare image rekindles thinking about color / intensity and AA 
approaches; Rendering large and scaling down vs AA or in combination.
The aa +ag flag/setting. A big pile of subtle trade-offs.

Where the previous am3 implementation was sort of working / stopping on 
the threshold test (and not the sample limit) there was too a probable 
color result change due the uberpov to v3.8 threshold test change.

Further, that test could get done after a conversion to grey scale 
(luminosity) instead - which might work better for what it's trying to 
do at the expense of CPU time in the threshold test. I'm not sure what 
impact to the render due sampling depth such a change would have.

All said. Let me play devil's advocate for a bit with anti-aliasing 
methods. I took the biscuit scene and played with am3 until I thought it 
was rendering the the ridges on the biscuits well.

Now I do these three renders with my current v3.8 based povr:

--- am3
povr2 biscuit.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
438.641
Pixels:  202500   Samples:  37917505   Smpls/Pxl: 187.25

--- am2
povr2 biscuit.pov +am2 +a0.015 +r5 +w450 +h450
413.702
Pixels:  216225   Samples:  48143226   Smpls/Pxl: 222.65

--- am1
povr2 biscuit.pov +am1 +a0.0 +r9 +w450 +h450
133.385
Pixels:  216000   Samples:  16402500   Smpls/Pxl: 75.94

Attached is an image comparing am1 to am3 in the top row; multiplying 
the differences by 5. In the bottom row comparing am2 to am3; again 
multiplying differences by 5.

What does it all mean? Lots of things I guess. I am comforted that the 
updated scenes match well for color and intensity across all three 
methods with the am3 fix.

I also tried v3.8 at commit 74b3ebe for grins expecting a really long 
run time (maybe with a color shift to explain yours). Instead I got:

p380 biscuit_v38.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
408.578s  (The posted fix costs time)
Pixels:  202500   Samples: 0   Smpls/Pxl: 0.00

I didn't use +ss but still the images compare well fixed to non-fixed. 
What this confirms is the pre-fix code was 'sometimes' working (no 
domain errors).

I looked at the code at commit 551338 (your release) and it matches that 
at 74b3ebe - also not an explanation for your color difference.

Extra credit to those of you asking why only am3 gets the image pixel 
count right...

Bill P.


Post a reply to this message


Attachments:
Download 'storyaamult005.jpg' (587 KB)

Preview of image 'storyaamult005.jpg'
storyaamult005.jpg


 

From: Ash Holsenback
Subject: Re: am3 test image
Date: 26 Sep 2020 08:03:31
Message: <5f6f2e13$1@news.povray.org>
On 9/25/20 9:00 AM, William F Pokorny wrote:
> On 9/24/20 2:31 PM, Ash Holsenback wrote:
>> image is a comparison of the tracetask.cpp fix that bill ask us to 
>> try... working with 3.8.0-alpha.10064268. saved aside before and after 
>> images and did a compare:
>>
>>
> 
> Thanks.
> 
> Did you happen to capture the CPU times for the two renders?

stock povray rendered it at 9 min 24 sec... lol the fix did it at 9:22

> 
> Did you use -j, +ss and +wt1 on both renders?

indeed

> 
> Were you using area lights?

not this time... i'll be getting to that eventually because that's 
exactly how i'm using am3... adaptive 0 on the area lights and rely on 
am3 to do the rest

> 
> ---
> Your compare image rekindles thinking about color / intensity and AA 
> approaches; Rendering large and scaling down vs AA or in combination.
> The aa +ag flag/setting. A big pile of subtle trade-offs.
> 
> Where the previous am3 implementation was sort of working / stopping on 
> the threshold test (and not the sample limit) there was too a probable 
> color result change due the uberpov to v3.8 threshold test change.

i think that might explain the results i was seeing in my compare image

> 
> Further, that test could get done after a conversion to grey scale 
> (luminosity) instead - which might work better for what it's trying to 
> do at the expense of CPU time in the threshold test. I'm not sure what 
> impact to the render due sampling depth such a change would have.

after your comment here i've done some digging... thanks for the nudge

> 
> All said. Let me play devil's advocate for a bit with anti-aliasing 
> methods. I took the biscuit scene and played with am3 until I thought it 
> was rendering the the ridges on the biscuits well.
> 
> Now I do these three renders with my current v3.8 based povr:
> 
> --- am3
> povr2 biscuit.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
> 438.641
> Pixels:  202500   Samples:  37917505   Smpls/Pxl: 187.25

your am3 settings are similar to what i'm using

> 
> --- am2
> povr2 biscuit.pov +am2 +a0.015 +r5 +w450 +h450
> 413.702
> Pixels:  216225   Samples:  48143226   Smpls/Pxl: 222.65
> 
> --- am1
> povr2 biscuit.pov +am1 +a0.0 +r9 +w450 +h450
> 133.385
> Pixels:  216000   Samples:  16402500   Smpls/Pxl: 75.94
> 
> Attached is an image comparing am1 to am3 in the top row; multiplying 
> the differences by 5. In the bottom row comparing am2 to am3; again 
> multiplying differences by 5.
> 
> What does it all mean? Lots of things I guess. I am comforted that the 
> updated scenes match well for color and intensity across all three 
> methods with the am3 fix.
> 
> I also tried v3.8 at commit 74b3ebe for grins expecting a really long 
> run time (maybe with a color shift to explain yours). Instead I got:
> 
> p380 biscuit_v38.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
> 408.578s  (The posted fix costs time)
> Pixels:  202500   Samples: 0   Smpls/Pxl: 0.00

hmmmm... i didn't see much time diff between fixed and not. i wonder if 
it that's tied to the fact that i never could reproduce the issue that 
Ton brought up... fwiw i'm dual core intel g2120 i believe. running leap 
15.1

> 
> I didn't use +ss but still the images compare well fixed to non-fixed. 
> What this confirms is the pre-fix code was 'sometimes' working (no 
> domain errors).
> 
> I looked at the code at commit 551338 (your release) and it matches that 
> at 74b3ebe - also not an explanation for your color difference.

if someone could add to this and maybe explain... i'm lost on that one

> 
> Extra credit to those of you asking why only am3 gets the image pixel 
> count right...

inquiring minds wanna know

> 
> Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: am3 test image
Date: 27 Sep 2020 09:15:47
Message: <5f709083@news.povray.org>
On 9/26/20 8:03 AM, Ash Holsenback wrote:
> On 9/25/20 9:00 AM, William F Pokorny wrote:
...
>> Did you happen to capture the CPU times for the two renders?
> 
> stock povray rendered it at 9 min 24 sec... lol the fix did it at 9:22
> 

Thanks. If you see much lower times with no AA (set threshold negative), 
It's likely for your scene '+am3' was running previously too. I suspect 
for some who previously got good results, method 3 was running to a stop 
at max samples and not the threshold. What run times these renders had 
would depend mostly on +r depth - something which can still sort of 
(confidence setting in play) happen, if the threshold is set small 
enough.

...
>> Were you using area lights?
> 
> not this time... i'll be getting to that eventually because that's 
> exactly how i'm using am3... adaptive 0 on the area lights and rely on 
> am3 to do the rest
> 

I know there is an odd interplay between area lights and AA, but I have 
never gotten my head around what's really happening.

Two adaptive algorithms fighting for what they think is right?

Why do you think am3 will behave better for such situations?

...
> 
> hmmmm... i didn't see much time diff between fixed and not. i wonder if 
> it that's tied to the fact that i never could reproduce the issue that 
> Ton brought up... 
>

Probably. Why your render works could be the compiler, settings when 
compiling, hardware. I don't know and don't plan to burn more time on 
it.

>>
>> I looked at the code at commit 551338 (your release) and it matches 
>> that at 74b3ebe - also not an explanation for your color difference.
> 
> if someone could add to this and maybe explain... i'm lost on that one
> 

The release at which you run - 3.8.0-alpha.10064268 - is in fact git 
commit 551338. The release name is just a name (a git tag). I run v3.8, 
and base povr off of a later commit. On seeing your color change, I 
thought maybe Christoph had made some change after 551338 which might 
explain it. He'd not - at least not in the method 3 core code.

>>
>> Extra credit to those of you asking why only am3 gets the image pixel 
>> count right...
> 
> inquiring minds wanna know
> 
...

I don't myself know! :-) It's been this way since v3.7 at least and it's 
a question of which I'm occasionally reminded.

I vaguely recall methods 1 & 2 doing stuff like always taking 4 pixels 
initially or throwing center samples away. Don't remember exactly, but 
these might be the cause. But then, I ask myself why should these pixels 
be counted with the base pixel count and not as additional pixels due 
the sampling method... It probably blurs the samples per pixel calculation.

Anyone know why the different base pixel counts on activating am1 or 
am2?

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: am3 test image
Date: 27 Sep 2020 10:01:12
Message: <5f709b28$1@news.povray.org>
On 9/27/20 9:15 AM, William F Pokorny wrote:
> I vaguely recall methods 1 & 2 doing stuff like always taking 4 pixels 
> initially or throwing center samples away. Don't remember exactly, but 
> these might be the cause. But then, I ask myself why should these pixels 
> be counted with the base pixel count and not as additional pixels due 
> the sampling method... It probably blurs the samples per pixel calculation.

Just hit me it does mess up the samples/pixel calc. That am1 test I did:

--- am1
povr2 biscuit.pov +am1 +a0.0 +r9 +w450 +h450
133.385
Pixels:  216000   Samples:  16402500   Smpls/Pxl: 75.94

Should have a samples/pixel value of >= 81. (9x9)

Anyway...

Bill P.


Post a reply to this message

From: Ash Holsenback
Subject: Re: am3 test image
Date: 29 Sep 2020 06:38:30
Message: <5f730ea6@news.povray.org>
On 9/27/20 9:15 AM, William F Pokorny wrote:
>>> Were you using area lights?
>>
>> not this time... i'll be getting to that eventually because that's 
>> exactly how i'm using am3... adaptive 0 on the area lights and rely on 
>> am3 to do the rest
>>
> 
> I know there is an odd interplay between area lights and AA, but I have 
> never gotten my head around what's really happening.
> 
> Two adaptive algorithms fighting for what they think is right?
> 
> Why do you think am3 will behave better for such situations?

not sure that it is .... the issue that was found just reminded me that 
am3 probably needed more of a test drive.


Post a reply to this message

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