DGDenoise

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDenoise

Post by Rocky »

Yes, I duplicated it. It's not horribly bad as the value is changed only by 1 or 2 but it should be fixed.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDenoise

Post by Rocky »

Hehe. I got lucky and found the color shift problem 10 seconds after opening DGDenoise.cu for inspection. Gotta regression test and make sure it's theoretically correct (seems to be but wanna be thorough about it). Thanks for pointing it out. It may point to similar issues in my other CUDA filters, too, so I am really grateful for this report, Sharc. :salute:

The edge effect is another matter. It is insignificant for reasonable strength values. e.g., it is absent at cstrength 0.5 and really prominent at cstrength 5.0. Strength 0.9 is quite strong. Still, I'll look at that tomorrow.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDenoise

Post by Rocky »

Can you please test this? Both problems should be fixed. Thank you, Sharc. You are my knight in shining armor!

http://rationalqm.us/misc/DGDecodeNV_Sharc.dll

Rename it properly of course. This is the 64-bit DLL. Let me know if you need 32-bit. When you bless things, I'll make a slipstream.

BTW, DGBob() is the only other affected filter. That will be fixed too when I slipstream.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDenoise

Post by Sharc »

It's perfect now, thank you :hat:
And yes it would be great if you would include the 32 bit .dll in the official slipstream. I am still using much of 32 bit avisynth, so far.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDenoise

Post by Rocky »

Jolly good, I will make a slipstream later this evening after swimming. Thank you!
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDenoise

Post by Rocky »

Darn, I went to test things in 32-bit and found that the Release mode crashes but the Debug mode succeeds. That's gonna make debugging hard.

Can you please test the released DGDecodeNV.dll DGDenoise in 32-bit. Is it OK for you (other than the chroma shift)? I tried it but it crashed so I'm thinking I may have a 32-bit Avisynth+ issue, because if it was that broken someone would have told me. If it works for you please tell me your Avisynth+ version.

Thank you.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDenoise

Post by Rocky »

Looks like a problem in BlankClip (or maybe 32-bit VirtualDub), because BlankClip() crashes but DGSource() does not.

#source=BlankClip(color=color_magenta, width=720, height=576, pixel_type="YV12") # crashes in 32-bit release mode
source=DGSource("Alba.dgi") # OK in 32-bit release mode
b=source.DGDenoise(strength=1.0,cstrength=1.0,searchw=5)
interleave(source.Histogram("levels"),b.Histogram("levels"))

Please advise your test results.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDenoise

Post by Rocky »

Getting interesting now! This fails:

loadplugin("D:\Don\Programming\C++\DGDecNV\DGDecodeNV\x32\Release\dgdecodenv.dll")
source=BlankClip(color=color_magenta, width=720, height=576, pixel_type="YV12") #or any other color
b=source.DGDenoise(strength=1.0,cstrength=1.0,searchw=5)
interleave(source.Histogram("levels"),b.Histogram("levels"))

But this succeeds:

loadplugin("D:\Don\Programming\C++\DGDecNV\DGDecodeNV\x32\Release\dgdecodenv.dll")
tmp=DGSource("Alba.dgi") # not used
source=BlankClip(color=color_magenta, width=720, height=576, pixel_type="YV12") #or any other color
b=source.DGDenoise(strength=1.0,cstrength=1.0,searchw=5)
interleave(source.Histogram("levels"),b.Histogram("levels"))

So it looks like DGSource() initialization is doing something that DGDenoise requires. Investigating...
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDenoise

Post by Sharc »

I noticed another oddity:
It crashes when I load the script an run it the first time -> Access violation.
Then I have to change any of the DGDenoise parameters and from then onwards it works.
I had this before, but got so much used to this oddity that I just used it that way ... assuming it's on my system only :belly-laugh:
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDenoise

Post by Rocky »

You're a funny guy, Sharc! Love ya. You have the system from hell. Not!

Please immediately report access violations experienced with DG tools. Hey, I know it's a once-in-a-blue-moon thing, but do what ya gotta do. :twisted:

Sherman says we should just drop 32-bit. Oh, the impetuousness of youth.
User avatar
Curly
Posts: 712
Joined: Sun Mar 15, 2020 11:05 am

Re: DGDenoise

Post by Curly »

Tomorrow is another day.

And Sunday is a big occasion at the Moose Lodge. Albert has been invited to give the keynote speech. We're going to grill him about the DG situation during the Q&A. Natasha says it will be like squeezing blood from an orange. Anemic!
Curly Howard
Director of EAC3TO Development
User avatar
Britney
Posts: 145
Joined: Sun Aug 09, 2020 3:24 pm

DGDenoise

Post by Britney »

Leave Albert alone!

User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDenoise

Post by Rocky »

All right, it appears to be a bug in the older CUDA libraries I use (to support older cards). DGSource() always performs cuInit() but if the script doesn't use DGSource() then the other filters have to perform the cuInit(). I had code in them that calls cuDeviceGetCount() as the first thing. It is supposed to return CUDA_ERROR_NOT_INITIALIZED if cuInit() has not been previously called [by DGSource()]. If I get that error the filter calls cuInit(). OK, sounds great, and it works for 64-bit, but for 32-bit that call is crashing instead of returning the error code.

I have a workaround that is working and hope to make a slipstream later today. I have to first test all the filters in both 32- and 64-bit, as well as testing chains of filters with and without DGSource().
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDenoise

Post by Sharc »

I confirm that the 32 bit .dll no longer crashes here. All ok now :D
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

DGDenoise

Post by Rocky »

Great to hear. Thank you for your report and testing.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Green border

Post by Guest 2 »

I gave a try to DGDenoise as simple filter for anime:

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\1_33 Porco Rosso\porco.dgi",ct=24,cb=24,cl=0,cr=0)
ConvertBits(16)
DGDenoise(strength=0.5,cstrength=0.15,blend=0.1,cblend=0.1,searchw=9)
fmtc_bitdepth (bits=10,dmode=8)
Prefetch(6)

and it gave me a nice green border.

Any idea?

Image
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

DGDenoise

Post by Rocky »

Hmm, looks like chroma denoising is broken in DGDenoise() for P16. Get rid of cstrength (either remove it or set it to zero) until I fix this. Also, DGDenoise() accepts YV12 so you don't need the ConvertBits(), unless you need it for the rest of the script.

Is that a progressive bluray? If it's a DVD don't forget to decomb before denoising.

Good to see another Hayao Miyazaki fanboy. ;)
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

DGDenoise

Post by Rocky »

Please re-download DGDecNV 239 and update DGDecodeNV.dll. Should be fixed. Thank you for pointing this out. Chroma denoising was broken for all YUV420P16 streams.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

DGDenoise

Post by Guest 2 »

Rocky wrote:
Wed Feb 02, 2022 10:45 am
Also, DGDenoise() accepts YV12 so you don't need the ConvertBits(), unless you need it for the rest of the script.
Doesn't it work more precisely with higher bitplanes? If not, hint hint :)
Rocky wrote:
Wed Feb 02, 2022 10:45 am
Is that a progressive bluray?
Yup.
Rocky wrote:
Wed Feb 02, 2022 10:45 am
Good to see another Hayao Miyazaki fanboy. ;)
:agree:
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

DGDenoise

Post by Rocky »

Guest 2 wrote:
Wed Feb 02, 2022 12:18 pm
Doesn't it work more precisely with higher bitplanes?
Nope. The low bits are filled with zeros anyway when upconverting the bit depth.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

DGDenoise

Post by Guest 2 »

Rocky wrote:
Wed Feb 02, 2022 12:30 pm
Nope.
Please check the zip file because it seems you put x86 build in main directory instead of x64.

Edit: well, it seems fixed now :)
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

DGDenoise

Post by Rocky »

Guest 2 wrote:
Wed Feb 02, 2022 12:33 pm
Please check the zip file because it seems you put x86 build in main directory instead of x64.
Nah, probably PEBKAC on your side. Am I wrong?

Don't you hate it when you drop your last pistachio nut on the floor and can't find it? You have that unfinished feeling all day.
User avatar
Natasha
Posts: 150
Joined: Wed Nov 20, 2019 11:11 am

DGDenoise

Post by Natasha »

Blind squirrels can find acorns but full sighted Rocky can't find a pistachio. What's up with that?
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

DGDenoise

Post by Guest 2 »

Rocky wrote:
Wed Feb 02, 2022 12:46 pm
Nah, probably PEBKAC on your side. Am I wrong?
Perhaps :mrgreen:
Rocky wrote:
Wed Feb 02, 2022 12:46 pm
Don't you hate it when you drop your last pistachio nut on the floor and can't find it? You have that unfinished feeling all day.
Gremlins built an entire miniature car with all the stuff I lost under kitchen furniture. :lol:
User avatar
Bullwinkle
Posts: 338
Joined: Thu Sep 05, 2019 6:37 pm

DGDenoise

Post by Bullwinkle »

I dropped a load on the floor and had no problem finding it.
Post Reply