Re: OpenImageDenoise
Posted: Sun Feb 03, 2019 7:16 am
And last example with super heavy GI noise...
I'll stop spamming now
I'll stop spamming now
Show your work, get help, participate in development
https://forums.luxcorerender.org/
Looks very promising, thanks for your testing (and general insisting)!lacilaci wrote: Sun Feb 03, 2019 6:47 amsometimes there's a gradient on the object that doesn't make sense and becomes completely black, losing details that would help denoiser!
Ok thanks for clarifying!Dade wrote: Sat Feb 02, 2019 10:46 pm Well, the correct one is SHADING_NORMAL while the AVG_SHADING_NORMAL has some meaningless data on edges (like explained by B.Y.O.B. some post ago). But I guess Intel Denoiser uses normal AOV as an hint of where to smooth and where not.
Yes it is kinda weird that they don't provide example of the required inputs. I've seen people having same issues with nvidia denoiser addon where no one could figure how those passes should look like and since they weren't actual renderer devs (unlike Dade!) they couldn't even create those aov's.epilectrolytics wrote: Sun Feb 03, 2019 7:29 amLooks very promising, thanks for your testing (and general insisting)!lacilaci wrote: Sun Feb 03, 2019 6:47 amsometimes there's a gradient on the object that doesn't make sense and becomes completely black, losing details that would help denoiser!
Normally normal values fall in the range from -1 to +1, times three directions (xyz).
When this is translated to rgb without correction, all the negative values are clipped and appear black.
So for an AOV in some image format there should be some correction like (x+1)/2.
Maybe OIDN cannot deal with negative values and needs a corrected image.
I've seen other early adaptors are also struggling with how to configure the normal pass.
I don't really understand why Intel has no information on these basic requirements.
lacilaci wrote: Sun Feb 03, 2019 7:40 am
I don't know if the avg normal pass could get more improved, but even at this state albedo +avgnormal are providing excelent preview quality and
I wouldn't worry even using this for final renders
I've tried the latest compilation from Azure it showed the same error. Luxcoreconsole was working apparently, but where should it put the output image?alpistinho wrote: Sun Feb 03, 2019 1:29 am I've added the initial support for the library but couldn't test since LuxcoreUI was refusing to load any test scene, being unable to parse the PLY files included.
There were also errors during texture parsingCode: Select all
[LuxCore][254.269] /home/daniel/Documents/lux2/LinuxCompile/LuxCore/scenes/simple [SDL][254.269] Reading scene: ./simple.scn [SDL][254.269] Material definition: whitematte [SDL][254.269] Material definition: redmatte [SDL][254.269] Material definition: blumatte [SDL][254.269] Material definition: greenmatte [SDL][254.269] Material definition: whitelight [SDL][254.269] Camera type: perspective [SDL][254.270] Camera position: Point[10.951, -20.663, 8.017] [SDL][254.270] Camera target: Point[0, 0, 1] [SDL][254.270] Camera clipping plane disabled RPly: Error reading 'x' of 'vertex' number 0 RenderConfig loading error: Unable to parse PLY file './simple-mat-cube2.ply'
Any idea of what could be causing this?Code: Select all
[LuxCore][25.422] /home/daniel/Documents/lux2/LinuxCompile/LuxCore/scenes/luxball [SDL][25.423] Reading scene: ./luxball-copper.scn [SDL][25.423] Material definition: shell [SDL][25.423] Material definition: whitematte [SDL][25.423] Material definition: luxtext [SDL][25.423] Material definition: blacktext [SDL][25.423] Material definition: whitelight RenderConfig loading error: Syntax error in texture name: 0,75 0,75 0,75
![]()
The code is at https://github.com/Alpistinho/LuxCore in the intel_oidn_denoise branch
Thanks
Why are these numbers using commas instead of decimal points? This might be the issue (i.e. locale).
Just opened the file and they're not using commas. It must be related to this bugB.Y.O.B. wrote: Sun Feb 03, 2019 11:28 amWhy are these numbers using commas instead of decimal points? This might be the issue (i.e. locale).
https://github.com/LuxCoreRender/LuxCore/issues/103
Code: Select all
daniel@daniel-desktop ~/Documents/lux2/LinuxCompile/LuxCore/bin $ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=pt_BR.UTF-8