OpenImageDenoise

Discussion related to the LuxCore functionality, implementations and API.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: OpenImageDenoise

Post by lacilaci »

yes yes... maybe bidir on gpu? :D
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: OpenImageDenoise

Post by Dade »

lacilaci wrote: Thu Feb 07, 2019 7:47 pm yes yes... maybe bidir on gpu? :D
In OpenCL v2.2 or CUDA, may be ... in OpenCL v1.2 ? I would prefer to shot on myself ... less painful.
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: OpenImageDenoise

Post by lacilaci »

Dade wrote: Thu Feb 07, 2019 10:29 pm
lacilaci wrote: Thu Feb 07, 2019 7:47 pm yes yes... maybe bidir on gpu? :D
In OpenCL v2.2 or CUDA, may be ... in OpenCL v1.2 ? I would prefer to shot on myself ... less painful.
Ok, I'm just asking, cause oidn made bidir also attractive in some cases.
So maybe best solution would be:

1. Pathtracing on OpenCL + cache + OIDN
2. BiDir on CPU + pathguiding + OIDN

I personaly think adaptivity should be revisited in general. I remember when good working adaptivity gave quite a boost to corona as well so it shouldn't be left at it's current state where it kinda helps a bit with caustics but otherwise it is not doing anything at all!
provisory
Posts: 235
Joined: Wed Aug 01, 2018 4:26 pm

Re: OpenImageDenoise

Post by provisory »

lacilaci wrote: Fri Feb 08, 2019 7:09 am I personaly think adaptivity should be revisited in general.
+1
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: OpenImageDenoise

Post by epilectrolytics »

lacilaci wrote: Fri Feb 08, 2019 7:09 am I personaly think adaptivity should be revisited in general.
Agreed, I see huge potential for a better synched combination of adaptivity and denoising.
Basically the path tracing has to stop way earlier (when the noise level is still high but manageable for OIDN) in the easy areas and then concentrate on the difficult areas until those get into "denoiseable" range.
So the threshold for adaptivity becomes relevant here and the question is if it can be tuned that way.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: OpenImageDenoise

Post by lacilaci »

epilectrolytics wrote: Fri Feb 08, 2019 8:40 am
lacilaci wrote: Fri Feb 08, 2019 7:09 am I personaly think adaptivity should be revisited in general.
Agreed, I see huge potential for a better synched combination of adaptivity and denoising.
Basically the path tracing has to stop way earlier (when the noise level is still high but manageable for OIDN) in the easy areas and then concentrate on the difficult areas until those get into "denoiseable" range.
So the threshold for adaptivity becomes relevant here and the question is if it can be tuned that way.
Exactly,

Evenly distribuded noise means even denoising quality accross image.
This also means that in theory you can do a quick crop render to estimate needed samples amount for final render and that means you can exactly predict time and quality of the rendering.

Currently, shadowy area with lot of gi noise and reflection will need way more samples than the rest of image even with adaptivity, and I've seen bunch of situations where adaptivity made it worse since it seemingly actually prefered bright/high power areas.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: OpenImageDenoise

Post by Dade »

Note: Oidn suggests to disable adaptive sampling because it works better with uniform noise. So all this argument could just lead to Oidn not working anymore if we have a too aggressive adaptive rendering.

But aside this I want look again into adaptive samplers in the future.
Support LuxCoreRender project with salts and bounties
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: OpenImageDenoise

Post by epilectrolytics »

Dade wrote: Fri Feb 08, 2019 9:53 am Note: Oidn suggests to disable adaptive sampling because it works better with uniform noise.
I guess they are talking about tiling. If the noise estimation is based on tiles that will possibly irritate the algorithm.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: OpenImageDenoise

Post by lacilaci »

epilectrolytics wrote: Fri Feb 08, 2019 10:24 am
Dade wrote: Fri Feb 08, 2019 9:53 am Note: Oidn suggests to disable adaptive sampling because it works better with uniform noise.
I guess they are talking about tiling. If the noise estimation is based on tiles that will possibly irritate the algorithm.
Well from github I gathered that something like weighted sampling could create a correlation that could break denoiser.
For example metropolis is suggested to not to be used aswell but, in luxcore it breaks denoiser in very early stages of rendering, after a while it works again.
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: OpenImageDenoise

Post by epilectrolytics »

epilectrolytics wrote: Thu Feb 07, 2019 10:58 am This morning I downloaded all the latest builds and put them into BlendLuxCore addon:
Indeed it works with Path CPU and crashes with Path OCL.
My Windows says all drivers are "the best" but I installed the latest nVidia game ready drivers anyways: no change, still crashes.
After exporting the scene for LuxCoreUI I found:
From the commits of 2.6.2019:
b21b129 (oidn fix) works
d083c3c (albedo bounce) crashes
53d96c0 (bidir bounce) crashes

Update:
Just tried to render without the wood texture and it works!
With texture it crashes (Texture provided in link above).
Also I can render Cornell scene with PathOCL just fine.
Maybe this should be moved to User support and continued over there?

Update2:
Further testing revealed that generally materials with image textures cause the latest builds to crash when rendered with PathOCL (Win10Pro).
FIXED!
Latest build LuxCore of 2019.2.8. works again!
Thanks guys!
:D
Post Reply