Tiled OIDN Denoising

Discussion related to the Engine functionality, implementations and API.
CodeHD
Posts: 182
Joined: Tue Dec 11, 2018 12:38 pm

Re: Tiled OIDN Denoising

Post by CodeHD » Sat Apr 27, 2019 6:54 pm

Alright, I'll be getting back to work now :)
Starting by trying to understand/implement the property parseing from the config file.
kintuX wrote:
Wed Apr 10, 2019 11:23 am
OK. No problem, gave it a first punch - compiled it :D (Windows x64 LuxCore tiledOIDN binaries here).
First, "blind" test done :? (I think - everyone is welcome to confirm, if it's working or not)
What was your own result from the blind test, actually? Did it work for you? (Maybe you did some more tests by now?)

CodeHD
Posts: 182
Joined: Tue Dec 11, 2018 12:38 pm

Re: Tiled OIDN Denoising

Post by CodeHD » Sun Apr 28, 2019 11:13 am

Ok it was indeed quite simple to include, despite the fact that I haven't followed all the code yet to determine how the prefixes are constructed :D

I have now included the number of stripes, the number of pixels of overlap and the threshold (in number of pixels) for switching between the standard and sliced oidn. Default values are 8, 50 and 1920*1080*4. Any (new) comments on these being good values, or any ideas for other values that should be possible for the user to define?

I have also noticed an issue with the hotel-scene I curently use to test it. I attached the config file I use.
It appears form the console output that OIDN is performed twice, and I don't see why exactly that happens...

Code: Select all

[Elapsed time:  68/0sec][Samples   20/20][Convergence 100.000000%][Avg. samples/sec  0.61M on 4973.4K tris]
[LuxCore][70.640] Outputting film: RGB_IMAGEPIPELINE_0.png type: 2
[LuxCore][70.890] Outputting film: ALBEDO.exr type: 31
[LuxCore][71.062] Outputting film: AVG_SHADING_NORMAL.exr type: 32
[LuxCore][71.219] Outputting film: SHADING_NORMAL.exr type: 8
[LuxCore][71.390] [IntelOIDNPlugin] Applying sliced OIDN!
[LuxCore][71.390] [IntelOIDNPlugin] Creating OIDN filter instance
[LuxCore][71.390] Stripe: 0
[LuxCore][71.422] IntelOIDNPlugin executing filter (stripe 1)
[LuxCore][71.812] IntelOIDNPlugin apply (stripe 1) took: 0.4secs
[LuxCore][71.812] IntelOIDNPlugin copying output buffer (stripe 1)
[LuxCore][71.812] Stripe: 1
[LuxCore][71.922] IntelOIDNPlugin executing filter (stripe 2)
[LuxCore][72.328] IntelOIDNPlugin apply (stripe 2) took: 0.4secs
[LuxCore][72.328] IntelOIDNPlugin copying output buffer (stripe 2)
[LuxCore][72.344] Stripe: 2
[LuxCore][72.453] IntelOIDNPlugin executing filter (stripe 3)
[LuxCore][72.828] IntelOIDNPlugin apply (stripe 3) took: 0.4secs
[LuxCore][72.828] IntelOIDNPlugin copying output buffer (stripe 3)
[LuxCore][72.844] Stripe: 3
[LuxCore][72.953] IntelOIDNPlugin executing filter (stripe 4)
[LuxCore][73.265] IntelOIDNPlugin apply (stripe 4) took: 0.3secs
[LuxCore][73.265] IntelOIDNPlugin copying output buffer (stripe 4)
[LuxCore][73.344] [LinearToneMap] Defined symbols:
[LuxCore][73.344] [LinearToneMap] Compiling kernels
[LuxCore][73.359] [LinearToneMap] Kernels cached
[LuxCore][73.359] [LinearToneMap] Compiling LinearToneMap_Apply Kernel
[LuxCore][73.359] [LinearToneMap] Kernels compilation time: 14ms
[LuxCore][73.359] Outputting film: RGB_IMAGEPIPELINE_1.png type: 2
[LuxCore][74.187] Outputting film: RGB_IMAGEPIPELINE_0.png type: 2
[LuxCore][74.437] Outputting film: ALBEDO.exr type: 31
[LuxCore][74.594] Outputting film: AVG_SHADING_NORMAL.exr type: 32
[LuxCore][74.765] Outputting film: SHADING_NORMAL.exr type: 8
[LuxCore][74.953] [IntelOIDNPlugin] Applying sliced OIDN!
[LuxCore][74.953] [IntelOIDNPlugin] Creating OIDN filter instance
[LuxCore][74.953] Stripe: 0
[LuxCore][74.969] IntelOIDNPlugin executing filter (stripe 1)
[LuxCore][75.312] IntelOIDNPlugin apply (stripe 1) took: 0.3secs
[LuxCore][75.312] IntelOIDNPlugin copying output buffer (stripe 1)
[LuxCore][75.312] Stripe: 1
[LuxCore][75.422] IntelOIDNPlugin executing filter (stripe 2)
[LuxCore][75.812] IntelOIDNPlugin apply (stripe 2) took: 0.4secs
[LuxCore][75.812] IntelOIDNPlugin copying output buffer (stripe 2)
[LuxCore][75.812] Stripe: 2
[LuxCore][75.922] IntelOIDNPlugin executing filter (stripe 3)
[LuxCore][76.312] IntelOIDNPlugin apply (stripe 3) took: 0.4secs
[LuxCore][76.312] IntelOIDNPlugin copying output buffer (stripe 3)
[LuxCore][76.312] Stripe: 3
[LuxCore][76.437] IntelOIDNPlugin executing filter (stripe 4)
[LuxCore][76.765] IntelOIDNPlugin apply (stripe 4) took: 0.3secs
[LuxCore][76.765] IntelOIDNPlugin copying output buffer (stripe 4)
[LuxCore][76.844] Outputting film: RGB_IMAGEPIPELINE_1.png type: 2
Attachments
render.cfg
(1.56 KiB) Downloaded 33 times

User avatar
B.Y.O.B.
Developer
Posts: 3017
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Tiled OIDN Denoising

Post by B.Y.O.B. » Sun Apr 28, 2019 3:26 pm

CodeHD wrote:
Sun Apr 28, 2019 11:13 am
I have now included the number of stripes, the number of pixels of overlap and the threshold (in number of pixels) for switching between the standard and sliced oidn. Default values are 8, 50 and 1920*1080*4. Any (new) comments on these being good values, or any ideas for other values that should be possible for the user to define?
Great, nice progress!
About the "nTiles" property: Until now LuxCore properties are all lowercase. I don't know if that's an important thing though - Dade?
Support LuxCoreRender project with salts and bounties

User avatar
Dade
Developer
Posts: 3398
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Tiled OIDN Denoising

Post by Dade » Sun Apr 28, 2019 3:43 pm

B.Y.O.B. wrote:
Sun Apr 28, 2019 3:26 pm
About the "nTiles" property: Until now LuxCore properties are all lowercase. I don't know if that's an important thing though - Dade?
Yes, no upper cases pls.

Does the code still use strips instead of tiles ?

In this case, you should probably switch to tiles because the original idea of using strips (i.e. no memory copies) is gone while tiles have the really huge advantage of having a fixed memory usage (while strips are still coupled with image width).
Support LuxCoreRender project with salts and bounties

CodeHD
Posts: 182
Joined: Tue Dec 11, 2018 12:38 pm

Re: Tiled OIDN Denoising

Post by CodeHD » Sun Apr 28, 2019 4:22 pm

Dade wrote:
Sun Apr 28, 2019 3:43 pm
B.Y.O.B. wrote:
Sun Apr 28, 2019 3:26 pm
About the "nTiles" property: Until now LuxCore properties are all lowercase. I don't know if that's an important thing though - Dade?
Yes, no upper cases pls.

Does the code still use strips instead of tiles ?

In this case, you should probably switch to tiles because the original idea of using strips (i.e. no memory copies) is gone while tiles have the really huge advantage of having a fixed memory usage (while strips are still coupled with image width).
no problem for me to have a lowercase parameter, didn't think about this being a convention here.

I guess you are right about the tiled approach. I think it would only really become an issue for >16K images, but better implement it to be future proof... I think I would leave the settings as one "ntiles" parameter that then gets squared (ntiles rows, ntiles columns), to be safe from accidental user input like 13 tiles, requiring another function to clean it up to something non-prime ;)

kintuX
Posts: 477
Joined: Wed Jan 10, 2018 2:37 am

Re: Tiled OIDN Denoising

Post by kintuX » Sun Apr 28, 2019 4:26 pm

CodeHD wrote:
Sat Apr 27, 2019 6:54 pm
Alright, I'll be getting back to work now :)
Starting by trying to understand/implement the property parseing from the config file.
kintuX wrote:
Wed Apr 10, 2019 11:23 am
OK. No problem, gave it a first punch - compiled it :D (Windows x64 LuxCore tiledOIDN binaries here).
First, "blind" test done :? (I think - everyone is welcome to confirm, if it's working or not)
What was your own result from the blind test, actually? Did it work for you? (Maybe you did some more tests by now?)
Yes, it worked fine, but i didn't do any further test as i find it too time consuming to play with standalone.
Had also same thought about tiling as Dade noted above. Gives much better control to end user.

PS (noticed you posted)
Great!
And for "Path Tiled" rendering, i assume the same?
Then 16K+ images will become quite easy to achieve!

CodeHD
Posts: 182
Joined: Tue Dec 11, 2018 12:38 pm

Re: Tiled OIDN Denoising

Post by CodeHD » Tue Apr 30, 2019 9:29 pm

Just a little update to end the day:
I have now written the code for tiled denoising, but I will have to go through the same procedure as for the stripe-code, i.e. find my errors with the buffer array indexing. Apparently something is going quite wrong at the moment as you can see in the following example :D
RGB_IMAGEPIPELINE_1.png

CodeHD
Posts: 182
Joined: Tue Dec 11, 2018 12:38 pm

Re: Tiled OIDN Denoising

Post by CodeHD » Thu May 02, 2019 9:48 am

Done.

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 included another keyword for testing. If you set film.imagepipelines.[...].oidnbench = 1 in the render.cfg, it will first execute the tiled and then the single OIDN. This makes it easier to compare performance for large renders without having to re-render everything. I also added timing counters over the entire function, not only each filter execution to include the buffer-writing and overlap computation.

Two quick performance meaurements on the LuxMark-Hotel scene:

At 3840x2160 (not exceeding my RAM):
tiled OIDN 7.5s, single OIDN 5.5s. For comparison, the render-time to 20 Samples was 270s on an i5-9600K (0.7% penalty)
At 7680x4320 (exceeding my RAM):
tiled OIDN 26s, single OIDN 74s. For comparison, the render-time to 20 Samples was 1185s on an i5-9600K (4% gain)

Are there any more sugegstions for now?

P.S.: It seems to me that the line that caused OIDN to be executed twice was:
periodicsave.film.outputs.period = 600
which appears to be executed even if the total rendering time is below 600s.

User avatar
Dade
Developer
Posts: 3398
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Tiled OIDN Denoising

Post by Dade » Thu May 02, 2019 10:51 am

You should fill a GitHub pull request :idea:
Support LuxCoreRender project with salts and bounties

User avatar
Dade
Developer
Posts: 3398
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Tiled OIDN Denoising

Post by Dade » Tue May 07, 2019 10:27 am

Dade wrote:
Thu May 02, 2019 10:51 am
You should fill a GitHub pull request :idea:
The code is now on the main branch.

CodeHD, can I ask you to modify the nTiles/pixelThreshold mechanic ?

My idea is to have a fixed and user specified tile size instead of a variable tile size based on image dimension. This is has the advantage of requiring a fixed (and user specified) amount of ram for the Oidn execution. A tile size parameter (i.e. X pixels) should replace nTiles/pixelThreshold parameters.

So BlendLuxCore can offer a combo box to select the type of Oidn execution:

- Normal;
- 0.25GB tiles;
- 0.5GB tiles;
- 1GB tiles;
- 2GB tiles;
- 4GB tiles;

This allow the user to check how much free ram he has to run the denoiser and select the most appropriate option. Theoretically, this process could be even automated.
nTiles/pixelThreshold mechanic instead requires some trial and test to find a suitable number of tiles to use to not run out of memory. This can be quite cumbersome because when running out of memory, you will probably have to kill the Blender process.
Support LuxCoreRender project with salts and bounties

Post Reply