deen.dll MarcFD

[GhostAFRippEr]

"I am looking for the source code of deen.dll created by MarcFD in order to port it to 64-bit. None of the denoisers I have used worked as efficiently as this one. I've tried them all—SMDegrain, MDegrain, KNLMeansCL, MiniDeen, dfttest, and FFT3DFilter—but I couldn't get results as high-quality as I did with deen.dll

[ChaosKing]

IIRC it was never open source.
But there is MiniDeen https://forum.doom9.org/showthread.php?t=176554

[real.finder]

IIRC it was never open source.
But there is MiniDeen https://forum.doom9.org/showthread.php?t=176554

he already mention MiniDeen :)

anyway, GhostAFRippEr, you have only two options:-

1- ask prunedtree/MarcFD in IRC (if he still use it, I think in #darkhold in Rizon)

2- Reverse engineering the .dll yourself :) like how SEt did it with aWarpSharp2 or TurboPascal7 with others prunedtree/MarcFD plugins

[ChaosKing]

Which version of "the best" deen is the latest, could you give me a link?

According to avs wiki, we have 2 versions and the older one is the better one?

Deen beta 2 is the older version, unfortunately is also the most known and used version (most of the scripts that use Deen use syntax that's specific to beta 2).
Deen v1.0 beta 1 is the updated version and it includes these changes:

Original meth parameter renamed to mode
Original mode parameter renamed to rad
New modes "c2d", "w2d", "w3d" ("m2d" is no longer supported)
ti (temporal influence) is now controlled independently by tthY and tthUV (luma/chroma), input value is now an integer (use to be float).
New parameters: min, scd, fcf, borderfix

Be aware that using the updated version as a drop-in replacement without adjusting the parameters to match the original can result in different behavior.

[qyot27]

1.0 beta 1, because it supports the w modes.

At this point I think it's sufficient to say that anyone complaining that the older version was the 'better' version wasn't talking about the quality (the wiki page doesn't mention that at all), but because the parameter naming changed and maybe some of the defaults, and people simply didn't want to update their scripts. After 23 years, IMHO it's perfectly safe to ignore that.

Thing is, deen was an offshoot of Convolution3D, which already has been updated and ported to modern AviSynth+ by pinterf (https://github.com/pinterf/Convolution3D). Back in 2003, most plugins likely didn't even include C/C++ reference implementations of the code, and used non-portable, MSVC-specific dialects of MMX, ISSE, etc. assembly directly. Knowing that deen was mostly just adapting and refining aspects of Convolution3D (the early comments on it basically just seemed like it was doing it faster...i.e. assembly optimizing, not so much algorithmic tweaking) would perhaps make more sense to just take hints from the description of the additional modes and base the work off what pinterf already did to bring up Convolution3D. It'd be way more transparent and portable, and way faster than either waiting for the original code to be released or to re-implement everything from scratch.

[DTL]

To save more from temporal artifacts with moving pictures I think it can be combined with standard motion compensating with mvtools (or other if present) and use typical interleave->process->selectevery sequence in script. At the times of active development of this filter mvtools not yet exist for AVS (?).

Though its proceessing may be close to something like 2D smoother + temporal smoother like vsTTempSmooth.

[ChaosKing]

I had some Fable tokens left. Here's a 64bit recomp of Deen v1.0 beta 1.

The process took around 70min on linux+wine for a bit exact output (pls test). + 40min for benchmarks & AVX2.

Without optimizations: 4-6x slower (depends on the mode)
With some AVX2 SIMD: 5-7x faster

1080p Source
Configuration │ Original MMX │ Recomp x86 AVX2 │ Recomp x64 AVX2 │ x64 AVX2 + 8T │
├───────────────┼───────────────┼─────────────────┼─────────────────┼───────────────┤
│ c2d rad2 │ 106 fps │ 740 fps │ 673 fps │ 508 fps not sure why, could be wine related │
├───────────────┼───────────────┼─────────────────┼─────────────────┼───────────────┤
│ c2d rad7 │ 13 fps │ 79 fps │ 82 fps │ 221 fps │
├───────────────┼───────────────┼─────────────────┼─────────────────┼───────────────┤
│ c3d rad2 │ 38 fps │ 221 fps │ 228 fps │ 370 fps │
├───────────────┼───────────────┼─────────────────┼─────────────────┼───────────────┤
│ w3d rad2 │ 27 fps │ 165 fps │ 157 fps │ 333 fps │
├───────────────┼───────────────┼─────────────────┼─────────────────┼───────────────┤
│ a3d rad2 │ 37 fps │ 147 fps │ 146 fps │ 306 fps │

Benchmarks are done on a Ryzen 9600x Linux via Wine.

There's a new parameter DEEN_THREADS=X

Binaries in attachment.

[real.finder]

I had some Fable tokens left. Here's a 64bit recomp of Deen v1.0 beta 1.

source code? :)

also since you did work on deen, maybe you can help with https://github.com/HomeOfAviSynthPlusEvolution/MiniDeen/issues/4 ?

[ChaosKing]

Added src, will push on github soon.

Since msg7086 / MeteorRain is active again maybe he will add it with help of AI. I have to wait for my weekly reset :o

[MeteorRain]

I still have 47% let me fire up Astra.

[MeteorRain]

source code? :)

also since you did work on deen, maybe you can help with https://github.com/HomeOfAviSynthPlusEvolution/MiniDeen/issues/4 ?

Would a modern implementation of Deen’s original `c2d` algorithm meet your needs, or do you specifically want a variant that follows MiniDeen’s existing behavior? If you have a reference script or expected behavior for SoftSharpen, could you share it?

Here is Astra’s analysis:

MiniDeen already uses a spatially constant threshold, so removing distance-based threshold reduction would not produce a new mode. Based on MiniDeen’s source and the available analysis of Deen, the key differences are:

- Deen’s `c2d` replaces rejected neighbors with the center value and averages over a fixed number of samples.
- MiniDeen excludes rejected neighbors from both the sum and the sample count, and gives the center sample an effective weight of three.

Adding `c2d` therefore requires changing the averaging rule, not just the threshold behavior. A modern Deen implementation could provide that algorithm directly, though it would not necessarily reproduce the original DLL’s rounding and boundary behavior exactly.

[real.finder]

I didnt made SoftSharpen so if I did update it, the new update should not give different output

I have received complaints in the past regarding even the slightest changes; therefore, my policy when modifying any existing script is to preserve its original behavior while adding new features (such as support for more color formats or additional functionality).

if the behaviour changed then the function name should be changed (SoftSharpen2, or SoftSharpenMod), and these changes might not appeal to long-time users in the first place, notice how the OP is prefer original deen even if minideen exist, minideen IIRC is act like deen but dont has all the options (which I think why GhostAFRippEr didnt like minideen)

[MeteorRain]

OK so what I can do now is -
- Integrate deen and minideen into neo-smo
- Fix bugs and crashes
Fixing bugs and crashes makes it non bit-identical (due to no longer reading from padding or invalid memory, etc), but algorithm keeps the same.

Then we can talk about how we want to deal with c2d. Because if the original SoftSharpen uses deen, then you want a new deen, not a minideen with new mode?

[MeteorRain]

https://forum.doom9.org/showthread.php?t=187140

Support original deen algorithms as described in the specs ChaosKing uploaded above. Not bit-identical, not bug-for-bug replication. Parameters need to be changed to new names.

[real.finder]

OK so what I can do now is -
- Integrate deen and minideen into neo-smo
- Fix bugs and crashes
Fixing bugs and crashes makes it non bit-identical (due to no longer reading from padding or invalid memory, etc), but algorithm keeps the same.

Then we can talk about how we want to deal with c2d. Because if the original SoftSharpen uses deen, then you want a new deen, not a minideen with new mode?

if the algorithm keeps the same, I think that will do it, similar to minideen

for SoftSharpen, I think new mode for c2d in minideen will be fine

but still some people want full deen like the OP

[real.finder]

The process took around 70min on linux+wine for a bit exact output (pls test). + 40min for benchmarks & AVX2.

a bit off topic but it's still prunedtree/MarcFD plugin, can you also see why aWarpSharp of aWarpSharp2 https://forum.doom9.org/showthread.php?p=1825745#post1825745 dont act like old aWarpSharp? if you can find why then aWarpSharp2 of aWarpSharp2 should not be changed, only aWarpSharp of aWarpSharp2 by default and if aWarpSharp2 of aWarpSharp2 get new parameter to change (not by default) that it will be fine, you can PR https://github.com/jpsdr/aWarpSharpMT/pulls if you find anything :)

[ChaosKing]

a bit off topic but it's still prunedtree/MarcFD plugin, can you also see why aWarpSharp of aWarpSharp2 https://forum.doom9.org/showthread.php?p=1825745#post1825745 dont act like old aWarpSharp? if you can find why then aWarpSharp2 of aWarpSharp2 should not be changed, only aWarpSharp of aWarpSharp2 by default and if aWarpSharp2 of aWarpSharp2 get new parameter to change (not by default) that it will be fine, you can PR https://github.com/jpsdr/aWarpSharpMT/pulls if you find anything :)

Zero testing by me, make a proper implementation in awarp2 if you like:
https://github.com/theChaosCoder/aWarpSharpMT/commits/original-beta1-compat/

I used the binary from here http://avisynth.nl/index.php/AWarpSharp

[real.finder]

Zero testing by me, make a proper implementation in awarp2 if you like:
https://github.com/theChaosCoder/aWarpSharpMT/commits/original-beta1-compat/

can you upload a binary so I can test?

[ChaosKing]

Check the release on github

[real.finder]

Check the release on github

thanks! seems good so far! but I think "original" parameter should be "true" by default in aWarpSharp (aWarpSharp(original=true))

and false for aWarpSharp2, obviously

can you do a PR in https://github.com/jpsdr/aWarpSharpMT/pulls ?

[ChaosKing]

Code needs some cleanup. It would be better if jpsdr would implement it himself. Not sure if he even wants the "original" behaviour.