one sampling pattern might not be enough

[Phasma]

thanks! exactly these are the reasons why I did not choose DR as a plattform for all of this. backburner however also seems sketchy and has it's limitations. for example i can not submitt this all as one job with x tasks. bb only accepts tasks if they are actually different frames. like pokoy mentioned, this is only possible for absolutely static scenes. pre-render scripts that adjust the frame will cause backburner also to always add the same numbering at the filename and therefore the output will overwirite itself all the time. if i also change the filename in the pre-render script backburnern has somehow issues writing these files at all (i think it is because in the job metadata there are still different filenames saved...) so for now I have to submit in a loop which takes some time if the scene is heavy - uncool. My Idea might be to have one dedicated job spawner in the farm where I just give instructions to...

[Phasma]

So I did another test. this time with adaptivity on all the time. I just compared it in the last example because we were not able to utilize adaptive sampling with our current render distribution method. As I am writing here for the sake of making the median avalible internally and for local renders, I think this comparison is much more important

so while the fireflies are handled a lot better, the general noise with the median is higher, just as romullus mentioned it before.

However I still think that this would be helpful. If you render scenes with a lot of blur, may it be motion blur, or out of focus areas, the image median renders these areas cleaner, and they sometimes would never clear up fully otherwise.

in the second example, again a simple teapot scene, I can throw 500 passes at this and the blur will not clear up. if I split it to 10x50 or 20x25 passes the results look much more usable (and of course it rendered a lot quicker on 10/20 machines in my case)

[romullus]

Just a random thought - since median merge result is mostly effective at suppressing fireflies, it would be interesting to see how it compares to lowering MSI parameter? Could you do additional test - single machine, 100 passes, but lower MSI. Maybe that would give you similar, or even better result than median merge?

[Phasma]

I already thought about this as well. however - especially in this case - fireflies tend to have a very high intensity and will not be cut of by a low value. but as you wanted me to try it specificly, I did it with a value of 5 (tried 10 also)

I can also try to play with GIvsAA - not sure if this could help...

but thanks for the hint

[Phasma]

here is 2vs64 GIvsAA

while 64 looks at least better, it took 2hours to finish those 500 passes. the image with a value of 2 rendered in 10 minutes :-D

-> and still not as good as median.

[maru]

1) When comparing different GIvsAA it is best to use a time limit (e.g. 10 minutes) and then compare the results. With lower GIvsAA you will get better quality of: AA, DOF, motion blur, fine textures at the cost of GI and direct light quality.
2) Your result look pretty much like clamped highlights. Are you saving your passes in a 32-bit format before blending them?
3) Can you try increasing Highlight clamping in the System tab (not Highlight compression in the VFB/camera!) and compare it with your method? You would have to use IR to find the optimal value. Too low values (like 1 or less) will completely clamp bright areas. Too high values will introduce fireflies. I would try with 2 and then increase until the clamping is barely visible on strong highlights.

[Phasma]

thanks for the input

reg:1)
true - didn't think of that
reg:2)
if I blend 32bit exr's I get the same result. the highlights look clamped as they get more and more "underrepresented" as different blades with different noise patterns cover them differently. so if at a specific x,y coordinate from one blade a strong highlight is shown but on most of the other machines there is none it averages out and leaves just a "clamped looking" highlight. highlights however that are bright on most if not all the machines stay intact and as bright as they should be.
wich brings me to 3)
if I introduce the highlight clamping in the system I will loose all the highlights, especially the strong ones like on the teapot in the foreground although they are the kind of "prooven highlights" (they are shown in every image from every blade) that are sampled good and I dont have to worry about - however - you are right. I am able to reduce the background noise of the bokeh balls using the highlight clamping. I would have to render 2 or more images however and manually paint in the areas I want in photoshop (as i would loose some of the other highlights that do not cause any sampling problem)

[Mohammadreza Mohseni]

really an interesting topic. I will surely test this method.

[Ondra]

Hi, are you using any sort of highlight compression? Because if yes, this is basically simulating the "subpixel mapping" that was used in VRay back in the days, but was abandoned because it decreases image quality (removed DOF and MB related highlights). The basic idea of the method used in astronomy is used in all realistic ray tracers since day 1 and is done in an optimal way, that you cannot improve upon by doing it manually.

[Phasma]

Hi

if you mean the color mapping highlight compression - then yes. i can however set this to 1 as a test and see what comes out then

basically i also thought that this technique musst be inherent to path tracing and progressive rendering. how else would different passes not just overwrite the previous one. also if i median merge more and more images together the effect of the result clearing up will also get less and less noticable - same with the progressive rendering in general. however - and thatswhy I wrote in the title that "one sampling pattern might not be enough" - it seems that the patterns that corona renders with are not too different. if i render without the sampling pattern locked - the results are really different from each other. I mean at the end, all what these out of focus highlighs really need is some more different rays to clear up but somehow very often these regions do never fully develop. they seem to be stuck in one sampling pattern.

[Ondra]

Corona tries to keep the sampling pattern the same across multiple renders and we jumped through a LOT of hoops to do this, on purpose. It improves noise situation in animations, and helps reproducibility (when there is some random bug after many passes).  Yes, it also means you cannot average images yourself after render. But don't worry - during single rendering, when resuming rendering, and when doing DR, the sampling pattern is automatically unlocked.

When averaging images, the out of focus highlights are not really cleared, they are removed from the image because of the image clamping. If you average images without postprocessing applied, you should get +- the same result as when you just let it render in single image.

Also note that thanks to the blue noise sampling and DMC, Corona actually picks better noise patterns across passes than you could achieve with purely random sampling - either in real world photography, or re-rendering the image multiple times with sampling pattern unlocked. You can switch between DMC and purely random per-pixel sampler in experimental settings to see how much improvement this is bringing.

[Ondra]

you can also achieve the same effect with highlight clamping in system->VFB render settings

[Phasma]

I could not beliefe it but it is true

when rendering exr and with highlight compression set to 1 - both (100 and 10x10) look basically the same.

so I could still ask for my feature to be implemented I thought... but this would mean that the internal image blending within the vfb would need to be done with highlight compression turned up or in general at a lower bit depth. correct me if i am wrong here - but this would not be something I would like to have :-D

So median is something that can be added later when the color mapping is applied and can help reducing fireflies and is something nice to do when distributing stuff over multiple computers but nothing for the internal rendering process - because it basically does this automatically already on non color mapped images properly.

If that is all correct - we can close the thread :-)