Hi there,
I've realized something I wasn't aware until now and wanted to ask for your
opinion. I'm using partial rendering (don't know if it's the right term, I mean
rendering the image by chunks instead of in one pass) on a current project and
I've made a unit test to check if my automatic procedure reuniting all the
chunks give me the right result, i.e. give me the exact same image as the one
rendered in one pass. As you can guess, I don't get the same image and the
problem is not in my procedure.
So, I've made a simple test case to investigate further. What I've found is that
with antialiasing turned on, the image by chunk is different from the image in
one pass. Then I thought there should be some randomness in the subsampling used
for antialising, maybe the seed is different at each rendering. So I've compared
two renderings in one shot, and there was no difference, which leave me with no
clue.
That's not a very big problem to me, but I'm wondering if it's known, if it's a
bug, if I'm doing something wrong, ...
If you wish to check yourself: I'm using POV-Ray 3.6.1 on Ubuntu 16.04, the
simple test case I've used is

--- testPov.pov

camera {
  location 5
  look_at 0
}

light_source { 10 color rgb 1 }

background { color rgb z }

sphere { 0 1 texture { pigment { color x } } }

--- end of testPov.pov

--- testPov.ini

Input_File_Name=testPov.pov
Width=100
Height=100
Antialias=on

--- end of testPov.ini

--- Makefile

oneShot:
 povray testPov.ini -D +OoneShot.png

fourFragments: firstFragment secondFragment thirdFragment fourthFragment

firstFragment:
 povray testPov.ini +SC1 +SR1 +EC50 +ER50 -D -OfirstFragment.png

secondFragment:
 povray testPov.ini +SC51 +SR1 +EC100 +ER50 -D -OsecondFragment.png

thirdFragment:
 povray testPov.ini +SC1 +SR51 +EC50 +ER100 -D -OthirdFragment.png

fourthFragment:
 povray testPov.ini +SC51 +SR51 +EC100 +ER100 -D -OfourthFragment.png

--- end of Makefile

Result of rendering in attachment. First line, two rendering in one pass and
their difference. Second line, rendering in one pass, rendering by chunks, their
difference (no antialising). Third line, rendering in one pass, rendering by
chunks, their difference (with antialising, check the value of the pixels at the
limit of the sphere and the background, they are not [0,0,0]). Both Gimp and my
code give me the same differences so I'm confident the culprit is POV-Ray.

Regards,
Pascal

Post a reply to this message

Attachments:
Download 'partialrenderingdifference.png' (4 KB)

Preview of image 'partialrenderingdifference.png'

How about posting an actual difference picture instead of letting everyone guess
what you want to show? The pictures look all the same as far as I am concerned.

Also, why are you using the decade old 3.6?

>
> --- testPov.pov
>
> camera {
>   location 5
>   look_at 0
> }
>
> light_source { 10 color rgb 1 }
>
> background { color rgb z }
>
> sphere { 0 1 texture { pigment { color x } } }
>
> --- end of testPov.pov
>
> --- testPov.ini
>
> Input_File_Name=testPov.pov
> Width=100
> Height=100
> Antialias=on
>
> --- end of testPov.ini
>
> --- Makefile
>
> oneShot:
>  povray testPov.ini -D +OoneShot.png
>
> fourFragments: firstFragment secondFragment thirdFragment fourthFragment
>
> firstFragment:
>  povray testPov.ini +SC1 +SR1 +EC50 +ER50 -D -OfirstFragment.png
>
> secondFragment:
>  povray testPov.ini +SC51 +SR1 +EC100 +ER50 -D -OsecondFragment.png
>
> thirdFragment:
>  povray testPov.ini +SC1 +SR51 +EC50 +ER100 -D -OthirdFragment.png
>
> fourthFragment:
>  povray testPov.ini +SC51 +SR51 +EC100 +ER100 -D -OfourthFragment.png
>
> --- end of Makefile
>
> Result of rendering in attachment. First line, two rendering in one pass and
> their difference. Second line, rendering in one pass, rendering by chunks, their
> difference (no antialising). Third line, rendering in one pass, rendering by
> chunks, their difference (with antialising, check the value of the pixels at the
> limit of the sphere and the background, they are not [0,0,0]). Both Gimp and my
> code give me the same differences so I'm confident the culprit is POV-Ray.
>
> Regards,
> Pascal

Post a reply to this message

On 6/17/2019 11:08 AM, BayashiPascal wrote:
> Hi there,
> I've realized something I wasn't aware until now and wanted to ask for your
> opinion. I'm using partial rendering (don't know if it's the right term, I mean
> rendering the image by chunks instead of in one pass) on a current project and
> I've made a unit test to check if my automatic procedure reuniting all the
> chunks give me the right result, i.e. give me the exact same image as the one
> rendered in one pass. As you can guess, I don't get the same image and the
> problem is not in my procedure.
> So, I've made a simple test case to investigate further. What I've found is that
> with antialiasing turned on, the image by chunk is different from the image in
> one pass. Then I thought there should be some randomness in the subsampling used
> for antialising, maybe the seed is different at each rendering. So I've compared
> two renderings in one shot, and there was no difference, which leave me with no
> clue.
> That's not a very big problem to me, but I'm wondering if it's known, if it's a
> bug, if I'm doing something wrong, ...
> If you wish to check yourself: I'm using POV-Ray 3.6.1 on Ubuntu 16.04, the
> simple test case I've used is
> 
> --- testPov.pov
> 
> camera {
>    location 5
>    look_at 0
> }
> 
> light_source { 10 color rgb 1 }
> 
> background { color rgb z }
> 
> sphere { 0 1 texture { pigment { color x } } }
> 
> --- end of testPov.pov
> 
> --- testPov.ini
> 
> Input_File_Name=testPov.pov
> Width=100
> Height=100
> Antialias=on
> 
> --- end of testPov.ini
> 
> --- Makefile
> 
> oneShot:
>   povray testPov.ini -D +OoneShot.png
> 
> fourFragments: firstFragment secondFragment thirdFragment fourthFragment
> 
> firstFragment:
>   povray testPov.ini +SC1 +SR1 +EC50 +ER50 -D -OfirstFragment.png
> 
> secondFragment:
>   povray testPov.ini +SC51 +SR1 +EC100 +ER50 -D -OsecondFragment.png
> 
> thirdFragment:
>   povray testPov.ini +SC1 +SR51 +EC50 +ER100 -D -OthirdFragment.png
> 
> fourthFragment:
>   povray testPov.ini +SC51 +SR51 +EC100 +ER100 -D -OfourthFragment.png
> 
> --- end of Makefile
> 
> Result of rendering in attachment. First line, two rendering in one pass and
> their difference. Second line, rendering in one pass, rendering by chunks, their
> difference (no antialising). Third line, rendering in one pass, rendering by
> chunks, their difference (with antialising, check the value of the pixels at the
> limit of the sphere and the background, they are not [0,0,0]). Both Gimp and my
> code give me the same differences so I'm confident the culprit is POV-Ray.
> 
> Regards,
> Pascal
> 
> 
> 

You might try disabling "jitter" in the INI file.


Michael

Post a reply to this message

Frankly, I have been rendering scenes in partial batches for years, and 
I have never met that problem.

I have a very dim recollection that with older versions (pre-3.6?) that 
issue /could/ happen sometimes, but with the latest, 3.7 and 3.8 alpha, 
never, despite complex radiosity settings.

-- 
Thomas

Post a reply to this message

On 6/17/19 11:08 AM, BayashiPascal wrote:
> Hi there,
> I've realized something I wasn't aware until now and wanted to ask for your
> opinion. 
...
> 
Hi Pascal,
I had a little time this morning before being busy with real life. So, 
thought I'd play with what you posted but in the current v3.8 master 
branch as it's the only place anything might be updated.

I rendered your scene at 400x400 instead of 100x100. To my surprise 
using only the default +a type anti-aliasing I see a pixel or sometimes 
a few which are 1/255 by channel in magnitude different(1). In the 
400x400 render, and just +a, this happens with a single pixel at 231,218 
which isn't even on sub-render boundary. Using still method one but 
with: +am1 +a0.1 +r3 I see again that pixel and an additional 2 in the 
same column above it. All near the edge of the sphere so AA is in play. 
Weird. Guessing maybe some sub pixel offset when rendering sub blocks.

The image attached used the new to v3.8 +am3 mode. In the top row two 
different full renders are compared and they match exactly. In the 
bottom we compare the top left full to an image assembled by chunks. The 
multiplier on the differences is 4x. Looks like +am3 better brings out 
whatever the issue is.

Still, not sure I'll open up an issue. Something like this is going to 
be way down on anyone's to-do list. Opinions?

You could try +am2 in 3.6 as I've not see issues with it in 3.8. 
Probably also faster. The jitter off comments others made stands. I also 
tested with one thread to be sure threads>1 not a problem in v3.8.

Bill P.

(1) - Not thinking about it very much - in 3.6, if not using 
assumed_gamma 1.0, the differences might be a little more dramatic in 
the resultant image though probably still hard to see.

Post a reply to this message

Attachments:
Download 'chunksstory.png' (46 KB)

Preview of image 'chunksstory.png'

Hi,
Many thanks to everyone for taking time to reply/investigate.

> Thorsten Froehlich
The image I've posted is the actual difference. The difference being extremely
small it may be hard to see to the naked eye without zooming in but making it
easier to see would mean posting a processed image which is not the actual
difference and then irrelevant IMO to anyone wanting to investigate.
I was using 3.6 yesterday because it's the one installed on my main computer and
I'm lazy to install a newer one, my bad, sorry.

> Mike Horvath
Thanks. Disabling jitter actually solved the problem. But, I don't understand
then why the problem doesn't occur for two consecutive rendering in one shot
(just wondering, not a big problem to me as I said before).

> Thomas de Groot
Thanks. Tonight I've tried with another machine on which I have 3.7 installed. I
confirm the problem disappears, even with jitter enable.

> William F Pokorny
Thank you very much for your time. Yes, it's weird. If the difference is never
more than 1/255, that's surely not a big deal. But if the cause is unknown it
leaves the possibility for a greater difference under different circumstances.
My opinion is, partial rendering are probably not the common use case and I
would believe in the smallest difference anyway unless shown the contrary. If I
had to debug it myself I would give it a very low priority. Personally,
disabling jitter to make my unit test run fine in my project is perfectly ok to
me, so it's up to you.

Thanks again to every one.

Pascal


William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/17/19 11:08 AM, BayashiPascal wrote:
> > Hi there,
> > I've realized something I wasn't aware until now and wanted to ask for your
> > opinion.
> ...
> >
> Hi Pascal,
> I had a little time this morning before being busy with real life. So,
> thought I'd play with what you posted but in the current v3.8 master
> branch as it's the only place anything might be updated.
>
> I rendered your scene at 400x400 instead of 100x100. To my surprise
> using only the default +a type anti-aliasing I see a pixel or sometimes
> a few which are 1/255 by channel in magnitude different(1). In the
> 400x400 render, and just +a, this happens with a single pixel at 231,218
> which isn't even on sub-render boundary. Using still method one but
> with: +am1 +a0.1 +r3 I see again that pixel and an additional 2 in the
> same column above it. All near the edge of the sphere so AA is in play.
> Weird. Guessing maybe some sub pixel offset when rendering sub blocks.
>
> The image attached used the new to v3.8 +am3 mode. In the top row two
> different full renders are compared and they match exactly. In the
> bottom we compare the top left full to an image assembled by chunks. The
> multiplier on the differences is 4x. Looks like +am3 better brings out
> whatever the issue is.
>
> Still, not sure I'll open up an issue. Something like this is going to
> be way down on anyone's to-do list. Opinions?
>
> You could try +am2 in 3.6 as I've not see issues with it in 3.8.
> Probably also faster. The jitter off comments others made stands. I also
> tested with one thread to be sure threads>1 not a problem in v3.8.
>
> Bill P.
>
> (1) - Not thinking about it very much - in 3.6, if not using
> assumed_gamma 1.0, the differences might be a little more dramatic in
> the resultant image though probably still hard to see.

Post a reply to this message

On 6/18/19 10:31 AM, BayashiPascal wrote:
> Hi,
> Many thanks to everyone for taking time to reply/investigate.
> 
...
> 
>> William F Pokorny
> Thank you very much for your time. Yes, it's weird. If the difference is never
> more than 1/255, that's surely not a big deal. But if the cause is unknown it
> leaves the possibility for a greater difference under different circumstances.
> My opinion is, partial rendering are probably not the common use case and I
> would believe in the smallest difference anyway unless shown the contrary. If I
> had to debug it myself I would give it a very low priority. Personally,
> disabling jitter to make my unit test run fine in my project is perfectly ok to
> me, so it's up to you.
> 
...
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 6/17/19 11:08 AM, BayashiPascal wrote:
...
>>
>> The image attached used the new to v3.8 +am3 mode. In the top row two
>> different full renders are compared and they match exactly. In the
>> bottom we compare the top left full to an image assembled by chunks. The
>> multiplier on the differences is 4x. Looks like +am3 better brings out
>> whatever the issue is.
>>
>> Still, not sure I'll open up an issue. Something like this is going to
>> be way down on anyone's to-do list. Opinions?
>>
...
> 

I think I'll open up a github issue. I was seeing differences with 
jitter off and the +am3 differences peaked at 80/255 per color channel 
though usually smaller. Further, I remembered we already have bugs and 
feature issues open related to +sc, +ec, +sr +er control in:

https://github.com/POV-Ray/povray/issues/312

and

https://github.com/POV-Ray/povray/issues/279

This issue should be at least considered when someone gets to looking at 
either of those.

Bill P.

Post a reply to this message

On 18-6-2019 16:31, BayashiPascal wrote:
>> Thomas de Groot
> Thanks. Tonight I've tried with another machine on which I have 3.7 installed. I
> confirm the problem disappears, even with jitter enable.
> 

I confess that the difference seems so small that I probably would miss 
it completely in a scene. ;-)

-- 
Thomas

Post a reply to this message

If it wasn't for my automated test, neither would I have noticed it ! :-)

Pascal



Thomas de Groot <tho### [at] degrootorg> wrote:
> On 18-6-2019 16:31, BayashiPascal wrote:
> >> Thomas de Groot
> > Thanks. Tonight I've tried with another machine on which I have 3.7 installed. I
> > confirm the problem disappears, even with jitter enable.
> >
>
> I confess that the difference seems so small that I probably would miss
> it completely in a scene. ;-)
>
> --
> Thomas

Post a reply to this message

On 6/18/19 8:10 PM, William F Pokorny wrote:
> On 6/18/19 10:31 AM, BayashiPascal wrote:
...
> 
> I think I'll open up a github issue. I was seeing differences with 
...
> 

See: https://github.com/POV-Ray/povray/issues/377

Bill P.

Post a reply to this message