Page 1 of 8

Tiled OIDN Denoising

Posted: Fri Mar 08, 2019 12:36 am
by pepe
13BB21BF-0F46-4F52-85B2-3B16F589583E.jpeg
2832F4FA-FC6F-4756-8F96-E782F70C33DD.jpeg
5268F958-E258-46F7-BCDE-299C098B9AD1.jpeg
Looking for universal settings.

Render time 45 min 2400x1350 only cpu i7 4790 @16g RAM

Engine - tile path cpu
Sampler - tile path sampler 32/8
Multipass 0.8/0.4/32
Clamping - 0.8
Light strategy - uniform
Path depts - T20(4/6/10)

OIDN

Halt condition 630 sample

PhotonGI 2000/32

Indirect cache 1000/9”/4/10/0.05


Why so much black in indirect cache?

At this rez OIDN taks 1 min at 4k it takes more than 10 min.
Why takes so much ram?

Re: LuxCoreRender v2.2alpha0 released

Posted: Fri Mar 08, 2019 6:46 am
by lacilaci
Don't know why there are those black areas in the debug view...
Why do you use tilepath? From my experience it is always slower than normal pathtracing. And why uniform light strategy?
About ram usage during denoising. I have 32gb ram so I don't have a problem with 4K renders, however I'm doing some product shots that are 5Kx5K and they don't fit ram during denoising so it slows down a lot (in linux it even crashed until I made swap file 16GB) but it's not that terrible on ssd.
I didn't make a proper comparison but I'm pretty sure optix wasn't that memory hungry at all so I'm not sure what's going on.

Re: LuxCoreRender v2.2alpha0 released

Posted: Fri Mar 08, 2019 11:28 am
by Dade
lacilaci wrote: Fri Mar 08, 2019 6:46 am I didn't make a proper comparison but I'm pretty sure optix wasn't that memory hungry at all so I'm not sure what's going on.
I assume it is just Odin to need a not trivial amount of ram. We could use the command line tool to investigate exactly how it uses for each resolution, if the amount is linear with the resolution increase, etc.
We could even try if we can do "tile denoising": split the image in tiles and denoise each single tile (but I bet it is not possible because some seam would pop up).

Re: LuxCoreRender v2.2alpha0 released

Posted: Fri Mar 08, 2019 11:36 am
by CodeHD
Dade wrote: Fri Mar 08, 2019 11:28 am We could even try if we can do "tile denoising": split the image in tiles and denoise each single tile (but I bet it is not possible because some seam would pop up).
It might work to denoise overlapping tiles and merge them with a crossover function.

Re: LuxCoreRender v2.2alpha0 released

Posted: Fri Mar 08, 2019 11:44 am
by Dade
CodeHD wrote: Fri Mar 08, 2019 11:36 am
Dade wrote: Fri Mar 08, 2019 11:28 am We could even try if we can do "tile denoising": split the image in tiles and denoise each single tile (but I bet it is not possible because some seam would pop up).
It might work to denoise overlapping tiles and merge them with a crossover function.
Yes, it may work and overall it is a quite clever idea. I think it is worth trying (if someone want give it a try, let me know).

Re: LuxCoreRender v2.2alpha0 released

Posted: Fri Mar 08, 2019 12:10 pm
by B.Y.O.B.
CodeHD wrote: Fri Mar 08, 2019 11:36 am It might work to denoise overlapping tiles and merge them with a crossover function.
Sounds good.
If you divide the image into horizontal stripes, you don't even need to copy the input AOVs into temporary buffers.

Re: LuxCoreRender v2.2alpha0 released

Posted: Fri Mar 08, 2019 7:49 pm
by CodeHD
I tried it and it seems to work. I used the 8K image again that i mentioned in a previous post.

OIDN full image, approx. 32GB ram + 32GB swap, took about 1m30s
4 slices, approx. 16GB ram, about 0m25s in total

I can't immediately see any seams in that image. I will clean up the code a bit, and prepare some (better examined) examples in a smaller size, 8K is a bit large for upload :D
(But first I will order a pizza, figuring out the right array indices made me forget that I had dinner on the stove... :roll: )

Re: LuxCoreRender v2.2alpha0 released

Posted: Fri Mar 08, 2019 10:54 pm
by CodeHD
Alright, here we are:

https://owncloud.gwdg.de/index.php/s/KERTDrvOAtGkVEF

The folder contains my python script, and an image if you want something for a quick test in three resolutions (1500x1000, 200% and 400%), all have 10S/p.

I worked with 16bit Tiff files because I had errors in the installation of openexr for python (so I didn't bother). Also I didn't include albedo and normals for this test, becasue I wasn't shure about normalisation (using tiff, the image itself needed it to run properly :?: ). But that should be a trivial thing to add.
If you want to run my script, keep that in mind. Also you will definitely need the first three arguments: the path where your image lies, file name, and the path to the oidn executable. The rest is explained in the docstring.

As an example I have attached the output-jps for the lowest resolution case.
The difference image is between the sliced oidn and the normal oidn.
A few pixels have a large relative difference, but the majority is below 1% difference. In any case below the difference of denoised and the true image with more samples ;)

Interestingly, in both column- and row-slicing, one slice has exactly zero difference to the single denoise... :?:

Re: LuxCoreRender v2.2alpha0 released

Posted: Sat Mar 09, 2019 11:01 am
by B.Y.O.B.
It seems to work.
Maybe test it on a few more images, and if there are no problems, implement it? :)
https://github.com/LuxCoreRender/LuxCor ... dn.cpp#L40

Re: LuxCoreRender v2.2alpha0 released

Posted: Sat Mar 09, 2019 6:21 pm
by CodeHD
B.Y.O.B. wrote: Sat Mar 09, 2019 11:01 am It seems to work.
Maybe test it on a few more images, and if there are no problems, implement it? :)
https://github.com/LuxCoreRender/LuxCor ... dn.cpp#L40
I am still working my way through the code (and my lack of C++ skills), but this looks like something I could try.

Regarding other images to test, maybe you (and others) could provide me with some? I don't really have many scenes myself, so I could only test on simple stuff and it would be better to have some diverse scenes.

And last, a question about the code: Am I right in assuming that the link you quoted, plus the code below for the viewport denoise are the only two places where OIDN is called? I don't think we need to implement it for the viewport, I just want to know if that is how it works ;)

https://github.com/LuxCoreRender/BlendL ... ort.py#L92