UnDot.dll

[exiztone]

Hello, I noticed Gordian Knot puts in UnDot.dll into its generated avs. I read the readme but I'm still unsure of what it does or when I need it. How will it help me?

Thanks :)

[Piper]

It's a very subtle denoiser written by trbarry some time ago and is often used to increase the compressibility of your source. It's effect is so subtle that you may have difficulty noticing a visual difference with or without it applied (at least I do when stepping through a somewhat noisy analogue source).

[exiztone]

Oooh, okay, thank you. :) I'm actually trying to compress Rear Window. It's from 1954 and even if the transfer was good, it is a little noisy. Would you recommend I use undot or not? If it will help to compress the movie without any visual loss that would be great! :)

[Piper]

As with anything, I would suggest using and testing it yourself. There's always some loss when applying any sort of denoising filter, whether or not it's acceptable to you is only something you can answer. If your goal is to archive your footage, then I personally wouldn't use any filters - even one that's considered as 'safe' as undot is.

[exiztone]

Well, I did two rips of Rear Window. One with UnDot.dll and the other without. I captured a few matching frames from each, but I couldn't see any difference with my own eye. What's the best way to see if it was effective?

[Poutnik]

Note that RemoveGrain(mode=1) is by algorithm and speed identical
to Tom Barrys Undot.(true for SSE capable CPU )
For SSE2/SSE3 CPU and Removegrain library
Removegrain(1) becomes faster then Undot.

[Audionut]

Well, I did two rips of Rear Window. One with UnDot.dll and the other without. I captured a few matching frames from each, but I couldn't see any difference with my own eye. What's the best way to see if it was effective?

Note the filesizes of each.

Removegrain is better IMHO.
Especiallly Removegrain(mode=2)

Also I believe that kassandro found something wrong with undot.