Guys, keep your buns in your karma!
Yes, tile rendering is what I need first. My customers require a mini 9600 x 5400 size picture.
Tiled OIDN Denoising
Re: Tiled OIDN Denoising
Linux Plasma | Ryzen 5, 32Gb, SSD M2, GT 590 RX | BenQ 27 | Wacom One | Microsoft Ergo | Tie Guan Yin tea
http://dezigner.tilda.ws/
http://dezigner.tilda.ws/
Re: Tiled OIDN Denoising
After my last post I also rendered the hotel scene in 9600x5400. Interestingly, the speedup was "only" about the same as for 7680x4320 (but well, fast ssd cache used both times).
The OIDN executable needed 73GB memory to denoise the full image at 9600x5400.
EDIT: I only just realized that I hadn't posted the values for the hotel scene at all yet, so I should add them:
Re: Tiled OIDN Denoising
I have now written a first version in C++. However I still seem to have a problem with indexing when merging the tiles, and I can't get my head around it...
Code is here:
https://github.com/CodeFHD/LuxCore/blob ... l_oidn.cpp
It is probably not optimised enough yet... (I want to get it soerking first, then clean up ) - so sorry if it is a mess! Please also ignore the fact that the standard code is currently called "ApplySplit" and the tiled version "Apply", I swapped the names for testing as I don't know yet where to implement a switch.
This is a test render:
and this the tiled denoise
it appears wrong in two ways:
- The overlapped part taken fromt he output buffer is shifted .
- there is a seam a bit above where the failed merge is taking place.
As I am off for tonight I thought I'd post it here for you guys to have a look at and hopefully find my error.
Code is here:
https://github.com/CodeFHD/LuxCore/blob ... l_oidn.cpp
It is probably not optimised enough yet... (I want to get it soerking first, then clean up ) - so sorry if it is a mess! Please also ignore the fact that the standard code is currently called "ApplySplit" and the tiled version "Apply", I swapped the names for testing as I don't know yet where to implement a switch.
This is a test render:
and this the tiled denoise
it appears wrong in two ways:
- The overlapped part taken fromt he output buffer is shifted .
- there is a seam a bit above where the failed merge is taking place.
As I am off for tonight I thought I'd post it here for you guys to have a look at and hopefully find my error.
Re: Tiled OIDN Denoising
Ok, I found the error.
Still have some seam going on though, I will investigate that now...
Still have some seam going on though, I will investigate that now...
Re: Tiled OIDN Denoising
Love glitches, love the work you do... keep fighting
BTW
Up to how many splits this tiling can do?
ie. What happens if number of splits is equal or exceeds number of pixels? Crash, glitch, warning or no work done?
Man, am eager to test it
BTW
Up to how many splits this tiling can do?
ie. What happens if number of splits is equal or exceeds number of pixels? Crash, glitch, warning or no work done?
Man, am eager to test it
Re: Tiled OIDN Denoising
Who said I won't keep fighting?
Regarding the number of splits: It would depend on how this feature is exposed to the user, but it should not be a problem in practice.
- WIth an overlap region of 50-100 pixels, as I have been using, you would need your total image height to fall in a similar range for this to be an issue. I.e. something like a 200px high image.
- You will not need tiled OIDN for images 200 pixels high. That is, unless you do something strange like 100.000 x 200. But in that case the implementation as stripes would fail regardless, and you would really need tiles.
- Finally, I wouldn't give the user too much control over the number of stripes. At the moment, I am thinking of fixing it to 8 stripes, starting at a certain resolution of slightly below 4K. That would allow users with 16GB to use it on resolutions up to approx. 9600x5400 (10K) and keep the stripe height large enough at lower resolutions (2048/8 = 256).
- The no. of stripes could be determined dynamically, but soon above 10K you will run into the issue of stripes being too wide. If we really get user feedback that we need more headroom on the high end, it is probably easier to implement tiles rather than find some stripe setting that makes for a good compromise.
Re: Tiled OIDN Denoising
I am still stuck with the current state. I currently get this output with stripe-denoise:
You can clearly see the remaining noise.
It is important to note that this happens above the overlap. The overlap region itself seems fine. I have run it with each half of the crossover-function set to zero to check only the respective stripe, everything fine there.
The OIDN shouldn't have any knowledge about the overlap region, so I don't understand this... Maybe it is my lack of proficiency in C++ to miss some issue with the buffer arrays?
I had the idea that the filter retained some knowledge from the previous run, so I re-assigned it in each loop iteration, but that changed nothing. (Maybe it needs to be deleted, but I do not see that option in the C++ API?)
Updated Code again here:
https://github.com/CodeFHD/LuxCore/blob ... l_oidn.cpp
You can clearly see the remaining noise.
It is important to note that this happens above the overlap. The overlap region itself seems fine. I have run it with each half of the crossover-function set to zero to check only the respective stripe, everything fine there.
The OIDN shouldn't have any knowledge about the overlap region, so I don't understand this... Maybe it is my lack of proficiency in C++ to miss some issue with the buffer arrays?
I had the idea that the filter retained some knowledge from the previous run, so I re-assigned it in each loop iteration, but that changed nothing. (Maybe it needs to be deleted, but I do not see that option in the C++ API?)
Updated Code again here:
https://github.com/CodeFHD/LuxCore/blob ... l_oidn.cpp
Re: Tiled OIDN Denoising
Does that noise happen, if you don't give albedo and normal passes?