DGDenoise

[Sherman]

People could smell it from miles away. Peww!

[Curly]

Who puts foinature in the kitchen? Is that a frog thing?

[Britney]

Frogs don't have kitchens, do they?

[Guest 2]

Nope. The low bits are filled with zeros anyway when upconverting the bit depth.

And if I feed it with UHD 10/12 bit video, it work on YUV420P16 internally with 16 bit precision, right?

[Guest 2]

Frogs don't have kitchens, do they?

We prefer to eat raw food. Whatever it comes. Popstars too.

[Rocky]

And if I feed it with UHD 10/12 bit video, it work on YUV420P16 internally with 16 bit precision, right?

Yes. of course. But I doubt you gain much by feeding it YV12 converted to YUV420P16, versus just processing in YV12.

[Britney]

We prefer to eat raw food. Whatever it comes. Popstars too.

Goodness gracious, you want to eat me? No! But I do appreciate you still putting me in the star category. Maybe we can hang out.

[Guest 2]

But I doubt you gain much by feeding it YV12 converted to YUV420P16, versus just processing in YV12.

Well, it actually does, both in speed and size.

Test on extract from Eternals BD, x265 -crf 22 --preset slow.

Code: Select all

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\2_35 Eternals\eternals.dgi",ct=140,cb=140,cl=0,cr=0)
DGDenoise(strength=0.15, cstrength=0.15, blend=0.1, cblend=0.1, searchw=9)

encoded 4488 frames in 983.53s (4.56 fps), 1220.50 kb/s, Avg QP:25.91

Code: Select all

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\2_35 Eternals\eternals.dgi",ct=140,cb=140,cl=0,cr=0)
ConvertBits(16)
DGDenoise(strength=0.15, cstrength=0.15, blend=0.1, cblend=0.1, searchw=9)
fmtc_bitdepth (bits=10,dmode=8)

encoded 4488 frames in 945.80s (4.75 fps), 1185.53 kb/s, Avg QP:25.94

[Rocky]

You have to clear the windows cache between the two encodes. Need a special utility for that, or reboot.

[Boulder]

It's faster because x265 works faster if the bitrate is lower.

[Rocky]

Why is the bitrate lower?

[Boulder]

The increased precision might cause a stronger denoising effect, or it simply stabilizes the image more and x265 is able to utilize reference frames better. It would also be interesting to know if the frame type decisions also change - I'd expect them to be different.

[Selur]

Any plans to add DGDenoise to Vapoursynth too?

Cu Selur

[Rocky]

If you take care of my request in the link below, I will do it.

https://www.rationalqm.us/board/viewtop ... 0a0#p16782

[Selur]

No problem. Done.
btw. is there an option in the board software (could find it) to enable that I get an email when I get a notification?

Cu
Selur

[Rocky]

Great thanks. At the bottom of the thread hit the wrench pulldown and select subscribe topic.

[Selur]

I'm subscribed, but I don't get any email notifications.
(yes, I did check my spamfolder)
I'll switch to another email and see if that helps.

Cu Selur

[Guest 2]

I'm subscribed, but I don't get any email notifications.

I have (had?) the same problem too.

[Selur]

Thanks for letting me know it's not just me. (Changing the email didn't help.)

Cu
Selur

[Rocky]

admin will look into it.

[Rocky]

As promised here is a stand-alone Vapoursynth native (API4) version of DGDenoise. If it works fine for you, I will release it officially.

https://rationalqm.us/misc/DGDenoise_selur.rar

[thechaoscoder]

Cool

I noticed some minor things:
- strength/cstrength can go over 1.0? Documentaion says range is 0.1-1.0, but it accepts 8.0
- typo in error msg: DGDenoise: searchw must be 5, 7, or 90
- Normally function names in VS start with a capital letter. To keep it consistent with the rest I would suggest dgdenoise.DGDenoise()
or even better dgdenoise.Denoise(), <-- we already know it comes from dgdenoise via namespace

[Rocky]

Greetings thechaoscoder! Thank you for the feedback.

- strength/cstrength can go over 1.0? Documentation says range is 0.1-1.0, but it accepts 8.0

The documentation says "Typically 0.1-1.0", so I'll leave it as is. It's inconsequential.

- typo in error msg: DGDenoise: searchw must be 5, 7, or 90

Fixed.

- Normally function names in VS start with a capital letter. To keep it consistent with the rest I would suggest dgdenoise.DGDenoise()
or even better dgdenoise.Denoise(), <-- we already know it comes from dgdenoise via namespace

I changed it to DGDenoise(). I prefer to leave the DG prefix to show that it is the same algorithm as the one in DGDecodeNV.

The RAR file was updated on line.

[thechaoscoder]

The documentation says "Typically 0.1-1.0", so I'll leave it as is. It's inconsequential.

Another small thing:
YUV444P8 - YUV444P16 are also accepted + Output is in YUV444P* then.
Perhaps the error message and docs need to be updated?

DGDenoise: input must be YV12 or YUV420P16

Doc: The input clip must be in the YV12 or YUV420P16 format. DGSource() delivers YUV420P16 when the source stream has a 10/12/16-bit depth.

[Rocky]

I need to reject the 444 formats as the filter is not designed for them, and the result is undefined. Do you need 444 support?