Page 11 of 32

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 7:16 am
by lacilaci
And last example with super heavy GI noise...

I'll stop spamming now

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 7:29 am
by epilectrolytics
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!
Looks very promising, thanks for your testing (and general insisting)!

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 adopters are also struggling with how to configure the normal pass.
I don't really understand why Intel has no information on these basic requirements.

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 7:31 am
by epilectrolytics
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.
Ok thanks for clarifying!

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 7:40 am
by lacilaci
epilectrolytics wrote: Sun Feb 03, 2019 7:29 am
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!
Looks very promising, thanks for your testing (and general insisting)!

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.
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.

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 (hell, so far I was using nvidia denoiser in ldr mode with beauty only and it kinda worked)

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 8:25 am
by Sharlybg
So now we should change the renderer name to Luxcore Realtime Engine. No ?

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 8:33 am
by FarbigeWelt
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

Looks like honey‘s dripping from the mouth of a most realistic reviewer.

Thnks for all the preparing testikg steps before alpha‘s done.

Feels like a second Xmas coming this year 😍.

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 11:04 am
by alpistinho
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.

Code: 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'
There were also errors during texture parsing

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
Any idea of what could be causing this? :oops:
The code is at https://github.com/Alpistinho/LuxCore in the intel_oidn_denoise branch
Thanks
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?

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 11:28 am
by B.Y.O.B.
alpistinho wrote: Sun Feb 03, 2019 11:04 am Syntax error in texture name: 0,75 0,75 0,75
Why are these numbers using commas instead of decimal points? This might be the issue (i.e. locale).
https://github.com/LuxCoreRender/LuxCore/issues/103

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 11:29 am
by alpistinho
Giving the scene to LuxcoreUI as a command line argument makes it render correctly.

I've set-up a second image pipeline but it doesn't change the image in any way, even though it becomes very slow and something is happening.

Re: OpenImageDenoise

Posted: Sun Feb 03, 2019 11:32 am
by alpistinho
B.Y.O.B. wrote: Sun Feb 03, 2019 11:28 am
alpistinho wrote: Sun Feb 03, 2019 11:04 am Syntax error in texture name: 0,75 0,75 0,75
Why are these numbers using commas instead of decimal points? This might be the issue (i.e. locale).
https://github.com/LuxCoreRender/LuxCore/issues/103
Just opened the file and they're not using commas. It must be related to this bug

EDIT:
I should probably change my LC_NUMERIC. The standard here is using commas as decimal separator

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