Tiled OIDN Denoising
Tiled OIDN Denoising
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
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.
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
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
Re: LuxCoreRender v2.2alpha0 released
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
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
(But first I will order a pizza, figuring out the right array indices made me forget that I had dinner on the stove... )
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
(But first I will order a pizza, figuring out the right array indices made me forget that I had dinner on the stove... )
Re: LuxCoreRender v2.2alpha0 released
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...
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
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
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
I am still working my way through the code (and my lack of C++ skills), but this looks like something I could try.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
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