Support forum for DG Tools

Current DGDenoise.txt states:

DGDenoise currently requires RGB32 input and mod 8 dimensions. Crop after DGDenoise()
if you need to. A later version may remove these limitations.

Is this still true, thought the limitation was removed.

It is still true. The previous "fix" caused a regression. I am working on resolving this for a following release.

Would it be better to add borders or resize using Pointresize to archive mod8?

AddBorders is best. This limitation will be removed in the next version.

Homer Simpson time

Can anyone tell me the error in this basic script, please

LoadPlugin("C:\Program Files (x86)\dgdecnv\DGDecodeNV.dll")
DGSource("I\input.dgi")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\DGDenoise\x32\DGDenoise.dll")
ConvertToRGB32()
DGDenoise().AssumeFPS(24000,1001)

Error in line 2

Do you really have a directory named "I", or did you mean "I:" to indicate a Windows drive letter?

I is the drive letter, short for input, output drive would be W, short for working
Just found it "logical" for my uses

Blond moment might be over
Gotcha, I forgot the ":" indicating drive letter

Homer time

LoadPlugin("C:\Program Files (x86)\dgdecnv\DGDecodeNV.dll")
DGSource("I:\input.dgi")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\DGDenoise\x32\DGDenoise.dll")
ConvertToRGB32()
DGDenoise().AssumeFPS(24000,1001)

Error in line 3
Cannot load module DGDenoise.dll

Help, what did I do wrong this time

@gonca

First, you have to use Avisynth 2.6 or Avs+. Next, check that you have DGDenoise.dll and DGDenoise.ptx together and that your path to them in the script is correct. Also you have it in the plugins directory AND you try to load it manually. Do one or the other.

If after fixing these things you still have an issue please post a screenshot of the error.

I have uploaded a new version that fixes the crop issue. You may now crop as desired before invoking DGDenoise.

admin wrote:@gonca

First, you have to use Avisynth 2.6 or Avs+. Next, check that you have DGDenoise.dll and DGDenoise.ptx together and that your path to them in the script is correct. Also you have it in the plugins directory AND you try to load it manually. Do one or the other.

If after fixing these things you still have an issue please post a screenshot of the error.

Despite the folder name it is Avisynth 2.6.0.6
The new version with DGDenoise.ptx works properly
Thanks for the patience and help from both of you.
Normally I can do simple scripts (nothing fancy) but this time I seem to have a major blonde period
Now I can start testing your new plugin
Again, thanks for the patience and help

Good to hear that you have it working, gonca my friend. I have several brain farts per day, so don't get down on yourself.

admin wrote:

Guest 2 wrote:Do you plan to create a new DGDecodeNV with DGFilter as option in same dll?

I'm considering it, but wonder about the point if there is already a stand-alone filter.

I am not a programmer but I think that could mean less gpu calls and overhead.

Plus, I know it's not a culprit, you would get more licenses.

Sure, Guest 2, there could be a small performance gain from combining them, but really I think it would be too small to be worth it. If the standalone filter was continued as well I would then have two codebases to maintain. Developers hate that! Nevertheless, I have not excluded the possibility. Higher on my list now is to add a bilateral filter kernel and support for YUV spaces to the standalone filter.

If I wanted to leverage it for more licenses, I could simply add the protection to the standalone filter. My licensing is enough to get me some pocket change for new computers, software, etc. I'm not hoping to get rich off of it, nor would that even be possible given the small niche that I occupy. Hacking around with these technologies is a fine way to avoid terminal boredom.

btw. the new version seems to run fine in Vapoursynth too, used: for a quick test.

Great, thanks for the report, Selur.

I have a native YV12 version working and will combine the two into one filter that accepts both spaces. That could be imported into DGDecodeNV as Guest 2 suggested, if I don't mind maintaining two codebases.

I should probably dilate the edge map. I want to make a bilateral kernel also.

I'm really grokking this CUDA stuff now.

Some preliminary testing done
Haven't had a chance to check quality of output but compressibility vs fps is really impressive
Don't think my cpu is even being taxed
Quick thought, if you don't mind
separate codes --- easier to maintain --- option for user to have or not and possible easier integration (use) with other software
But you are the boss of the software
Re license along the way
Good scotch ain't cheap

gonca wrote:Good scotch ain't cheap

Sad but true. Same for good bourbon.

Some early testing done on DGDenoise
Find that strength=0.5 is quite good,all other settings on default
DGDenoise is really fast
Have AVSMeter results if you wish to see them
Also have bmp of frame 185 for comparison, if you wish to see it, along with some other data

Thanks for your test results, gonca.

I've been looking into the actual filtering quality, comparing it carefully to KNLMeansCL. It became clear to me that the "quick NLM" algorithm from nVidia is surely much faster but it creates what are to my mind nasty, unacceptable artifacts. The normal NLM is no faster than KNLMeansCL and produces almost identical results. Again we see that there is no free lunch. Therefore, I have decided not to proceed with the current filter design. However, I do plan to modify it and integrate it into DGDecodeNV. The integrated functionality will be the KNN kernel. This will give decent and fast noise reduction.

You know best
I did notice loss of detail, noticeable, even at strength+0.5
Results were okay but ...
When you integrate into DGDecNV you might want to consider some kind of license for extra functionality or maybe o donation system.
Don't expect much and you can"t be disappointed
We finally have one thing in common --- good scotch and bourbon ain't cheap

It's the artifacts that are the concern; there is no loss of detail versus KNLMeansCL for equivalent strengths.

OK, back to quantum physics for a while.

Bottoms up.

Loss of the detail was not meant as a comparison to another filter, but to original.
Quantum physics or binary mathematics, glass full -- glass empty (1--0)

admin wrote:The integrated functionality will be the KNN kernel. This will give decent and fast noise reduction.

Please keep the three filters, or at least full NLM. KNN is a simplified version of NLM and almost useless in any situation so that we will be back using KNLMeansCL.

OK, why not. KNN or full NLM, but no quick NLM.