Tiled OIDN Denoising
Re: Tiled OIDN Denoising
You can replace the denoise.exe binary, yes.
Re: Tiled OIDN Denoising
Correction: You can't do this, because denoise.exe uses the same shared library (libOpenImageDenoise) as LuxCore. And if you would replace libOpenImageDenoise, this would create conflicts with final render denoising in LuxCore.
You will have to leave everything as it is and wait for us to update to the new OIDN release.
Re: Tiled OIDN Denoising
really? Did you encounter problems?B.Y.O.B. wrote: ↑Fri May 17, 2019 12:20 pm Correction: You can't do this, because denoise.exe uses the same shared library (libOpenImageDenoise) as LuxCore. And if you would replace libOpenImageDenoise, this would create conflicts with final render denoising in LuxCore.
You will have to leave everything as it is and wait for us to update to the new OIDN release.
I downloaded the new oidn two days ago and used it without problems so far (although I did not use Albedo and Normal AOVs, and only Blender and not standalone)
Re: Tiled OIDN Denoising
Yes, on my Linux the denoiser failed to start with errors about missing symbols in the library.
Did not test on Windows.
Did not test on Windows.
Re: Tiled OIDN Denoising
With Windows 7 it just throws countless errors in system console...
"Warning: SetThreadGroupAffinity failed" But works, as results look fine (did same with 0.8.2)
eg:
@ Preview @ Render
"Warning: SetThreadGroupAffinity failed" But works, as results look fine (did same with 0.8.2)
eg:
@ Preview @ Render
Re: Tiled OIDN Denoising
I have finally taken the time to update the tiled OIDN (before being on travel again for weeks... )
Changes as usual to these files, you can have a look before I make a pull request:
https://github.com/CodeFHD/LuxCore/blob ... l_oidn.cpp
https://github.com/CodeFHD/LuxCore/blob ... tel_oidn.h
https://github.com/CodeFHD/LuxCore/blob ... mparse.cpp
I have changed two things:
1) The computation of the output array, i.e. the tile overlapping. Benefit: far fewer lines of code. Downside: Probably not faster or more memory efficient though, although I do not believe it will be significant compared to the OIDN time anyways.
2) The nTiles vs nPixel mechanic:
The function itself still uses an nTiles approach (now separate for x and y dimension). The input is now in number of pixels, and as a first step it is converted to a number of slices in each dimension. I do it this way to make shure there is no leftover strip of few pixels, smaller than the overlap region.
Let me know what you think
Changes as usual to these files, you can have a look before I make a pull request:
https://github.com/CodeFHD/LuxCore/blob ... l_oidn.cpp
https://github.com/CodeFHD/LuxCore/blob ... tel_oidn.h
https://github.com/CodeFHD/LuxCore/blob ... mparse.cpp
I have changed two things:
1) The computation of the output array, i.e. the tile overlapping. Benefit: far fewer lines of code. Downside: Probably not faster or more memory efficient though, although I do not believe it will be significant compared to the OIDN time anyways.
2) The nTiles vs nPixel mechanic:
The function itself still uses an nTiles approach (now separate for x and y dimension). The input is now in number of pixels, and as a first step it is converted to a number of slices in each dimension. I do it this way to make shure there is no leftover strip of few pixels, smaller than the overlap region.
Let me know what you think
Re: Tiled OIDN Denoising
Since there were no further comments, I just made a pull request
Re: Tiled OIDN Denoising
Sorry for not replying so long.
I tested your changes locally and it works good.
I also have the code for BlendLuxCore ready to expose the tile size so it can be changed by the users, if need be.
I tested your changes locally and it works good.
I also have the code for BlendLuxCore ready to expose the tile size so it can be changed by the users, if need be.
Re: Tiled OIDN Denoising
Tiled denoising will be integrated into the next OIDN release according Attila: https://github.com/OpenImageDenoise/oid ... -502442748
It also offered some hint for our current in house implementation (you can find the information in the link). Do we use a 128 pixel overlap ?
It also offered some hint for our current in house implementation (you can find the information in the link). Do we use a 128 pixel overlap ?