Problem with Large Image

[Giuseppe1971]

With HDR images greater than 2K (4K, 8K, etc ..) there are SERIOUS memory problems, the request for images from 4K up is excessive in the order of 15-69 GB, how can this problem get around ???

[atafra]

We just released v0.9.0, which reduces memory consumption by about 38%. We'll continue decreasing the memory usage in future versions.

BTW the memory usage scales linearly with the number of pixels, so there's nothing special happening at higher than 2K resolutions.

[Giuseppe1971]

Hello atafra,

This is GREAT news, the noise filter is fantastic but excessive memory consumption limited its use on a large scale, especially with VR images, this is your Achilles Heel but I'm glad you're facing the problem and I'm sure you will be able to solve it optimally.

In thanking you for the excellent work I greet you cordially...

Giuseppe

[Dade916]

LuxCoreRender users has experience the same problem denoising image for printing at very high resolutions (i.e. up to 75GB ram usage !).

We have solved the problem by implementing "tile denoising": we split the image in tiles and denoise each tile with Oidn. Tiles have overlapping borders in order to avoid any "seam" problem. The huge advantage of this solution is a fixed amount of memory usage (i.e. established by the tile size), no matter of the rendering resolution.

@atafra, this solution could be implemented back in Oidn as an option.

P.S. the forum thread were we have discussed/developed this idea is here: https://forums.luxcorerender.org/viewtopic.php?f=5&t=967#p11066

[Giuseppe1971]

Hello Dade916 ,

indeed, we too have solved exactly the same way as you described, of course with this solution I get a little extra time and for this reason we have put it as an option but we manage it automatically ..

Thank you for your report, have a nice day

Giuseppe

[atafra]

Tiled denoising will be integrated into the next OIDN release, significantly reducing memory usage.

However, please note that doing it manually has some potential pitfalls. First, the amount of overlap needs to be 128 pixels to perfectly avoid seams. Second, unfortunately this works correctly only for LDR images. For HDR images, OIDN computes an exposure value from the whole image, which is applied to all pixels (this is used only for internal processing, it will not affect the exposure of the denoised image). If you manually denoise the image in tiles, each tile will have a different exposure value, potentially causing seams. The native solution in OIDN will avoid this issue.

[Dade916]

Ok, good news, thanks Attila.

[CodeFHD]

Hello atafra, Jut to add a note to Dade's comment: In the LuxCore implementation, the overlapping regions are not simply averaged, but added with a crossover function, just a linear ramp. I did not see seams in any tests I did, so I didn't bother investigating further. I also didn't test various 2^n-pixel overlaps, as I implemented it with equal tile size rounded from the user input, minimizing the overlap region in order to not add too much time penalty. But it is of course good to have a solution that natively avoids it. Thanks a lot for the input!

And great to hear that you will natively adopt tiles for memory consumption, that will the implementation for users much more efficient!

[atafra]

There is no need for a crossover function for the overlapping regions, the pixels just need to be there. The 128 pixel overlap is computed from the amount of neighboring pixels affecting the computation of a pixel, rounded up to multiple of 32. However, pixels so far from the center have small weights, which explains why you didn't detect any seams with smaller overlaps.

[skrat]

@atafra That's a great new that tiling will be part of OIDN! Do you an approximate timeline for the next release?

[atafra]

We've just released v1.0.0 with tiling support, and significantly lower default memory usage for large images!

[CodeFHD]

Thanks for the note on the update! I have done a first test for LuxCoreRender and can confirm that it works well. The difference between a single and a tiled denoise is also lower than it was with our previous implementation.

[Giuseppe1971]

Thanks for the excellent work you have done, we are testing the new version and it seems that the automatic tiling method works like the one we implemented, if we encounter any problems we will let you know.

I know I am demanding, now it remains only to improve the speed of execution (joke of course !!!) ... Again congratulations for the work you have done, I wish you many successes ...

A greeting

Giuseppe

[pberto]

Hi @atafra, I coment here even if closed as it related. Since you mentioned that memory use is linear, do you have some metric to understand the amount of memory needed to denoise 1 megapixel with the RT filter and two aux passes (NOT pre-filtered) with v1.4.1? We are seeing large memory use with 8K images so it would be nice to understand what is expected. Thanks.

[atafra]

Hi! The memory use is not linear since v1.0.0, it actually should not exceed 3 GB, regardless of resolution. How much memory does it use it your case? The maximum memory usage can be set by the user, and it can be even less than 3 GB, however this would hurt performance. You can find more details about this feature in the documentation (maxMemoryMB filter parameter).

[pberto]

Without the maxMemoryMB parameter it used 7.5GB of ram on a machine with 8GB to denoise an 8K image (roughly 33 mega pixels).

I assume the smaller the parameter the more tiles, the more overlap, the more slowdown, correct? Is there a recommended value relative to the number of megapixels? If not we will set it to the machine memory size minus something.

[atafra]

The recommended value is the default one, only 3 GB. How did you get the measurement of 7.5GB? Are you sure that this does not include input/output buffers and applications memory as well? Are you using the latest version of Open Image Denoise?

[pberto]

Our "app" is purely a CLI tool that does 1 thing: denoise. There is no other app. v1.4.1. If we set the max memory value the memory stays within the limit. I will check again just in case and let you know.