LuxCoreRender Forums

You can replace the denoise.exe binary, yes.

marcatore wrote: ↑Tue May 14, 2019 9:27 amwe should download the last build for viewport rendering...right?

B.Y.O.B. wrote: ↑Tue May 14, 2019 9:45 am You can replace the denoise.exe binary, yes.

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.

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.

really? Did you encounter problems?
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)

Yes, on my Linux the denoiser failed to start with errors about missing symbols in the library.
Did not test on Windows.

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

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

Since there were no further comments, I just made a pull request

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.

B.Y.O.B. wrote: ↑Wed Jun 12, 2019 11:56 pm 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.

All good, thanks for writing the Blender feature!

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 ?