CCD - Camcorder Color Denoise (Chroma spatial denoiser) - AVISynth+ version

[zybex]

CCD - Camcorder Color Denoise (Chroma spatial denoiser) - AVISynth+ version

Hello to all.

@Guest
@tritical
@pinterf
and other respected filter makers

Who can and knows exactly how:
Please make a version for AVISynth+ (x64 + MT) of VirtualDub filter "CCD - Camcorder Color Denoise" by Sergey Stolyarevsky.

http://acobw.narod.ru > Camcorder color denoise
http://acobw.narod.ru/file/ccd.zip

Sources here:
https://forum.doom9.org/showthread.php?p=1916925#post1916925

This filter "CCD" works much more correctly, and really suppresses chroma noise within the frame, without creating graphic artifacts, unlike the filter "Cnr2".

It would be very useful to have it in the form of a filter for AVISynth+ so that we can work using x64 + MT and directly in the YV12 color space without the need for double conversion YV12> RGB32> YV12.

Screenshots of some frames before and after processing by the filter "CCD - Camcorder Color Denoise" I attached.
CCD-Screenshots.zip (3.1 МБ) - PNG
https://mega.nz/file/ag5GFC4J#LWgqMqtp4Co9BEGxGPZemafhuYfuTLG3k5OaQ0BDOJI

[StainlessS]

In all probability, the filter you mention relies on RGB to do its thing, YUV conversion would likely not work as well or at all.
User Guest, has now undergone his latest transmogrification into videoh, and I suspect that he is currently on a 30 day 'vacation'.
Tritical, long time missing.

[zybex]

i believe nothing is impossible

[Atak_Snajpera]

i believe nothing is impossible

I would not be so sure... Try slamming the revolving door ;)

[StainlessS]

Try slamming the revolving door ;)
Maybe not impossible, maybe just improbable. https://www.cosgan.de/images/smilie/froehlich/r075.gif

Zybex,
Asking for anybody to emulate CCD without some source code is also improbable outcome [unless you know specifically and can point to method used]

This has problem in x64 but works in x86


# 64 bit VDF fails with error 0xC1, but filter works OK in VDUB2 x64, possible AVS+ VDubFilter.dll problem.

# VDub GUI "Show Noise" and "Disable" args not available external to VDUB, ie not usable in Avisynth.
# VDF accepts only RGB32
Function VD_CCD(clip clip, int "threshold", bool "multithreading",bool "ShowNoise",Int "preroll") {
threshold = Default(threshold,30) # Default 30 as in Vdub
multithreading = Default(multithreading,true) # Default true
ShowNoise = Default(ShowNoise,False) # Simulated
preroll = Default(preroll,1) # We've given default of 1 frames pre-rolled, maybe only 0 needed.
Assert(clip.IsRGB32,"VD_CCD: Need RGB32")
LoadVirtualdubPlugin("D:\VDUB\ccd_32bit.vdf", "_VD_CCD", preroll) # Change Path to VDF
# LoadVirtualdubPlugin("D:\VDUB\ccd_64bit.vdf", "_VD_CCD", preroll) # Change Path to VDF ## Getting Error OXC1 for 64 bit VDF plugin
result = clip._VD_CCD(threshold,multithreading?1:0)
return (ShowNoise) ? result.Subtract(clip) : result
}

SHOWNOISE=False

AviSource("D:\parade.avi")

# Added, FIX WEIRD stuff
MOD=16
Crop(0,0,Width/MOD*MOD,height/MOD*MOD)

ConvertToRGB32(matrix="rec601")
VD_CCD(shownoise=SHOWNOISE)


NOTE, the VDF is 8 bit RGB32 only.

EDIT: Added ShowNoise simulated arg, not sure if working ok. [test clip giving weird result]

Here wierd results, weird at top of frame, maybe again VdubFilter.dll problem [there is some color variation in the main grey block]
https://i.postimg.cc/fL36jVC7/ccd-00.jpg (https://postimages.org/)

EDIT: VD_CCD(threshold=0,shownoise=true) should provide no change, but gives same weird problem at top of frame.
https://i.postimg.cc/G22c03Q9/ccd-01.jpg (https://postimages.org/)

EDIT: This fixed problem if before the function call, weird stuff gone [MOD=8 dont fix it]

MOD=16
Crop(0,0,Width/MOD*MOD,height/MOD*MOD)

[StainlessS]

Added AMP arg,


# 64 bit VDF fails with error 0xC1, but filter works OK in VDUB2 x64, possible AVS+ VDubFilter.dll problem.

# VDub GUI "Show Noise" and "Disable" args not available external to VDUB, ie not usable in Avisynth.
# VDF accepts only RGB32
Function VD_CCD(clip clip, int "threshold", bool "multithreading",bool "ShowNoise",Bool "Amp",Int "preroll") {
threshold = Default(threshold,30) # Default 30 as in Vdub
multithreading = Default(multithreading,true) # Default true
ShowNoise = Default(ShowNoise,False) # Simulated
Amp = Default(Amp,True) # Amplify if ShowNoise
preroll = Default(preroll,1) # We've given default of 1 frames pre-rolled, maybe only 0 needed.
Assert(clip.IsRGB32,"VD_CCD: Need RGB32")
LoadVirtualdubPlugin("D:\VDUB\ccd_32bit.vdf", "_VD_CCD", preroll) # Change Path to VDF
# LoadVirtualdubPlugin("D:\VDUB\ccd_64bit.vdf", "_VD_CCD", preroll) # Change Path to VDF ## Getting Error OXC1 for 64 bit VDF plugin
result = clip._VD_CCD(threshold,multithreading?1:0)
return (!ShowNoise) ? result : (!amp) ? result.Subtract(clip) : result.Subtract(clip).Levels(128-8,1.0,128+8,0,255,coring=false)
}

THRESHOLD=30
SHOWNOISE=true
AMP =true

AviSource("D:\parade.avi")

# FIX VDubFilter.dll Weird BUG, but not the x64 bug
MOD=16
Crop(0,0,Width/MOD*MOD,height/MOD*MOD)

ConvertToRGB32(matrix="rec601")
VD_CCD(threshold=THRESHOLD,shownoise=SHOWNOISE,amp=AMP)

https://i.postimg.cc/cHHXfPsV/ccd-02.jpg (https://postimages.org/)

NOTE, RGB Interleaved is internally upside down, so weird stuff at top of frame is actually near end of frame buffer.

EDIT: OOps, used AMP center 126, changed to 128 [subtract for YUV TV levels Y is 125.5 rounded to 126, but we are in RGB so need 128]

[zybex]

Asking for anybody to emulate CCD without some source code is also improbable outcome
I am not a programmer, but I was able to decompile the plug-in file "ccd_64bit.vdf" using the program:
Snowman
https://derevenets.com

[zybex]

My primary goal was to get the plugin to work directly in YV12 mode, without the need for ConvertToRGB32 operation.
Each color space conversion blurs the picture and distorts some colors, especially red.

[zybex]

So far i have found a way out:

As a replacement for the "CCD - Camcorder Color Denoise" filter in AVISynth, I selected the "TBilateral" filter parameters to make it work only to suppress Chroma noise.
With such a line, the result of "TBilateral" is almost identical to "CCD - Camcorder Color Denoise" with Threshold=20:

TBilateral (diameterL=3, diameterC=11, sDevL=0, sDevC=3.0, iDevL=0, iDevC=7.0, csL=1.0, csC=1.0, d2=false, chroma=true, gui=false, kernS=2, kernI=2, resType=0)

[zybex]

But the TBilateral filter is slow.

My next dream wish is:
So that in the fast-running filter DGDecNV> DGDenoise (fast stand-alone CUDA filter that implements NLM denoising)
made a separate adjustment of parameters for Chroma noise reduction.
Now there the noise reduction parameters for Chroma and Luma can only be the same, which does not allow to achieve an ideal result.

http://rationalqm.us/dgdecnv/dgdecnv.html
http://rationalqm.us/board/viewtopic.php?f=14&t=506

DGDenoise(clip c, float strength, float blend, bool chroma, int searchw, int device)

[Boulder]

You can run DGDenoise twice and use Mergexxx.

chromadenoise = DGDenoise(strength=whatever)
lumadenoise = DGDenoise(strength=whatever2)
lumadenoise.MergeChroma(chromadenoise)

[zybex]

You can run DGDenoise twice and use Mergexxx.

Thanks, I will try this option later.

But how to make DGDenoise work only with Chroma, without Luma ?

[StainlessS]

Using a decompiler to re-code a plugin would I think constitute Code Theft.
You would need to find Public domain or Open Source, source code, or algorithm.

DGDenoise for chroma, might try look here(I dont use DGdenoise):-

http://avisynth.nl/index.php/Swap
and here:- http://avisynth.nl/index.php/Extract

[zybex]

the filter you mention relies on RGB to do its thing, YUV conversion would likely not work as well or at all.
Autor of CCD wrote at 2018:
"CCD uses the advantages of RGB, so translation into other formats is possible only in sham, inside you still have to translate into RGB."
(translated from Russian)

Nevertheless, I have already managed to achieve a very similar result directly in the YV12 mode using the special Chroma setting of the "TBilateral" filter, as I wrote above.

[Boulder]

Thanks, I will try this option later.

But how to make DGDenoise work only with Chroma, without Luma ?
chromadenoise = DGDenoise(strength=whatever)
MergeChroma(chromadenoise)

[zybex]

Using a decompiler to re-code a plugin would I think constitute Code Theft.
You would need to find Public domain or Open Source, source code, or algorithm.

Unfortunately for many years the author of CCD has not yet published either the source code or the algorithm of work.
I think that he uses the secret technologies of ancient or extraterrestrial civilizations :-)

Updated 18 June:
Sources here:
https://forum.doom9.org/showthread.php?p=1916010#post1916010

[zybex]

chromadenoise = DGDenoise(strength=whatever)
MergeChroma(chromadenoise)

Thank you, wise Boulder.

[zybex]

DGDenoise for chroma, might try look here:
http://avisynth.nl/index.php/Swap
http://avisynth.nl/index.php/Extract

Interesting option.
Thanks.
It remains only to figure out which combination of filter commands "Extract" and "Swap" need to be composed to process only Chroma through DGDenoise.

[Reel.Deel]

Interesting option.
Thanks.
It remains only to figure out which combination of filter commands "Extract" and "Swap" need to be composed to process only Chroma through DGDenoise.

DGDenoise only supports YV12 or YUV420P16. The following method allows you to denoise each chroma channel independently, sometimes one has more noise then the other.

For YV12 do something like:

Source

Y = Last
U = UToY().DGDenoise(strength=0.20, chroma=false) # chroma processing is already set to false by default
V = VToY().DGDenoise(strength=0.25, chroma=false)

YToUV(U,V,Y)


For YUV420P16 you have to use ShowU/ShowV (http://avisynth.nl/index.php/Extract) and CombinePlanes (http://avisynth.nl/index.php/CombinePlanes).

Source
ConvertBits(16)

Y = Last
U = ShowU(pixel_type="YUV420P16").DGDenoise(strength=0.20, chroma=false)
V = ShowV(pixel_type="YUV420P16").DGDenoise(strength=0.25, chroma=false)

CombinePlanes(Y,U,V, planes="YUV", source_planes="YYY", sample_clip=Y) # instead of 'sample_clip' you can also you pixel_type="YUV420P16"

[zybex]

For YV12 do something like
OK.
Many thanks.

[pinterf]

I'm not sure but it seems that the filter is processing (width*height) bytes of input, instead of (pitch*height) bytes?

Avisynth internally works with 64-byte alignment, and provides buffers as such. The structures passed to the filter contain pitch and even a modulo (pitch-rowwidth) number.

Artifacts on top of RGB32 means that the last X bytes are left unprocessed (packed RGB is top-bottom)

[StainlessS]

It does though work in x64 Vdub2 [EDIT: direct load of AVI]
https://i.postimg.cc/sXs8zgvV/Untitled-00.jpg (https://postimages.org/)

EDIT: I've given Shekh a poke, maybe he enlightens us soon.

EDIT: I've also tried with AVs script

AviSource("D:\Parade.avi")
ConvertToRGB32

VDub2 x64 and still no problem.

EDIT:
I'm not sure but it seems that the filter is processing (width*height) bytes of input, instead of (pitch*height) bytes?
More specific than prev given snippet, so above statement looks correct.

# FIX VDubFilter.dll Weird BUG, but not the x64 bug
# XMOD=16 YMOD=1 # OK
XMOD=1 YMOD=16 # BAD, Prob in XMOD

Crop(0,0,Width/XMOD*XMOD,height/YMOD*YMOD)

[pinterf]

It's just a feeling, I see that depending on the horizontal crop (starting from mod16, then crop(0,0,-1,0) .. crop(0,0,-15,0) filter is giving bigger and bigger unprocessed area at the frame end (visible on top).
Note that -1 is 4 bytes, and a horizontal crop of -15 is 60 bytes.
VDub filter can hint that it requires a buffer with a specific minimum alignment, which request is surely fulfilled by avisynth by having 64 byte aligned NewVideoFrame.
Can you test it with avs 2.6 and width -1, -2 and -3 crop values (it has 16 bytes alignment)?

[StainlessS]

Can you test it with avs 2.6 and width -1, -2 and -3 crop values (it has 16 bytes alignment)?
Clarify, Avisynth 2.60 standard x64 ?

[pinterf]

32 bit. I can see the problem with 32 bit version as well. No difference between 32 or 64 bit versions with my AviSynth+, both have black (total and partially filled) lines.

[StainlessS]

Hmmm, 32 bit looks ok here.

This is weird [AVS std 2.60 x86]

# 64 bit VDF fails with error 0xC1, but filter works OK in VDUB2 x64, possible AVS+ VDubFilter.dll problem.

# VDub GUI "Show Noise" and "Disable" args not available external to VDUB, ie not usable in Avisynth.
# VDF accepts only RGB32
Function VD_CCD(clip clip, int "threshold", bool "multithreading",bool "ShowNoise",Bool "Amp",Int "preroll") {
threshold = Default(threshold,30) # Default 30 as in Vdub
multithreading = Default(multithreading,true) # Default true
ShowNoise = Default(ShowNoise,False) # Simulated
Amp = Default(Amp,True) # Amplify if ShowNoise
preroll = Default(preroll,1) # We've given default of 1 frames pre-rolled, maybe only 0 needed.
Assert(clip.IsRGB32,"VD_CCD: Need RGB32")
LoadVirtualdubPlugin("D:\VDUB\ccd_32bit.vdf", "_VD_CCD", preroll) # Change Path to VDF
# LoadVirtualdubPlugin("D:\VDUB\ccd_64bit.vdf", "_VD_CCD", preroll) # Change Path to VDF ## Getting Error OXC1 for 64 bit VDF plugin
result = clip._VD_CCD(threshold,multithreading?1:0)
return (!ShowNoise) ? result : (!amp) ? result.Subtract(clip) : result.Subtract(clip).Levels(126-8,1.0,126+8,0,255,coring=false)
}

THRESHOLD=30
SHOWNOISE=false
AMP =false

AviSource("D:\parade.avi")

ConvertToRGB32(matrix="rec601")

# FIX VDubFilter.dll Weird BUG, but not the x64 bug
#XMOD=16 YMOD=1 # OK
#XMOD=1 YMOD=16 # BAD
#Crop(0,0,Width/XMOD*XMOD,height/YMOD*YMOD)

# Here, 488x360

Crop(0,0,-1,0) # FINAL result still shows 488x360 ??? [EDIT Oops, 488 not 448]


VD_CCD(threshold=THRESHOLD,shownoise=SHOWNOISE,amp=AMP)

info


I have to leave very soon, got to hit the shop before it shuts.

EDIT: If Switch on SHOWNOISE, then fails at subtract due to different size frames.

EDIT: Avs+ v3.61 test 8 x86 returns width 487 as it should, so looks like Avs 2.60 std has bug in VDFilter.

[shekh]

EDIT: I've given Shekh a poke, maybe he enlightens us soon.


Not sure what you expect, surely a filter can have bugs. We dont know if x64 version was built from same source :)

[StainlessS]

OK Shekh, was hoping that you might have some magic words to say, thanks for taking a look.

Clarify, Avisynth 2.60 standard x64 ?
I guess I got myself a bit confused there, thats what happens when you are bout 12 hours past your bedtime and are attempting to do bout 17 things at once.
I had to go back and read thread from start to figure out what the problem was/problems were.
The 64 bit problem that I am having is that I cannot load x64 plugin, with error 0xC1.
x86 problem is the weird stuff at top of frame.
Also, I had gotten it into my head that VDFilter.dll calls VDub/VDub2 when it just has some kind of emulation layer for VD.

Anyways, had some sleep now and hopefully have un-confused myself, a bit.

[pinterf]

Anyway, without seeing the filter's source code it's waste of our time.

[StainlessS]

Also found out why I had problems with x64, I was trying to load x64 plug into x86 app, :(

Anyways, tried

THRESHOLD=30
SHOWNOISE=false
AMP =false

AviSource("D:\parade.avi")
ConvertToRGB32(matrix="rec601")
# Here, 488x360
Crop(0,0,-1,0) # Now 487x360
VD_CCD(threshold=THRESHOLD,shownoise=SHOWNOISE,amp=AMP)
info # FINAL result still shows 488x360 ???

With avs standard v2.58, v2.60, v2.61, and all of them have problem in VDFilter showing width as 488 when we have cropped 1 pixel from RHS, should show 487.

Anyway, without seeing the filter's source code it's waste of our time.
OK.

[pinterf]

With avs standard v2.58, v2.60, v2.61, and all of them have problem in VDFilter showing width as 488 when we have cropped 1 pixel from RHS, should show 487.

If I remember well from my quick debug session, this filter reports that it supports v14 interface, while classic Avisynth only supports up to v6 (?). But I don't know what different behaviour it means.
Can you load Avisynth+'s vdubfilter dll into classic Avisynth?

[StainlessS]

Can you load Avisynth+'s vdubfilter dll into classic Avisynth?

v2.58, "Not a v2.5 avisynth filter" [or words to that effect].
v2.60,2.61, Seems to Work OK, prev error script returns 487x360 as it should. [and also same rubbish at top of frame for the bugged vdf filter].
So in v2.60/2.61 standard, LoadPlugin on Avs+ VDFilter.dll, Installs AVS+ LoadVirtualDubPlugin() and fixes the erroneous 488x360 bug [produces correct 487x360], and seems to work just fine.

[zybex]

I talked with the author of the filter, informed him that we were going to create a remake of this filter under AVISynth+, and asked him to share the filter’s algorithm and / or sources, he said that he would send me some specific information in a couple of days when he returned from the trip.

[zybex]

Here are the filter sources:



The author of this filter Sergey Stolyarevsky kindly provided them to us.

And he promised to join our discussion on this topic in a few days.

==================
Updated fixed version here:
[url]https://forum.doom9.org/showthread.php?p=1916925#post1916925

[pinterf]

Here are the filter sources:

https://mega.nz/file/uxxXCYwT#CthrV9yqNh5rog95WUxMM9VLWtvfvSbFJhPTbuDsNw8

The author of this filter Sergey Stolyarevsky kindly provided them to us.

And he promised to join our discussion on this topic in a few days.
Good. After having a quick look into the source I noticed that pixels are addressed as (y*width + x) and not (y * pitch + x) which explains why passing a buffer with an (64 byte) aligned pitch will not be processed entirely. So - if I'm right - Sergey can fix it quickly.

[zybex]

Updated fixed version CCD V1.9 (Sources + Binaries)

https://mega.nz/file/GsYlQayQ#LO7qq8hOmWXlglzlvFY-AlWX6F5hqKuQRCamtUe0lO4

[StainlessS]

Cheers Sergey Stolyarevsky and Zybex.

[Sergey 1400]

Hello! I am Sergey Stolyarevsky, the author of the filter. Version 1.9 solved the problems?

[zybex]

Version 1.9 solved the problems?

Hi, Sergey.
Glad to see you on the forum.

pinterf now on vacation until about July 11:
https://forum.doom9.org/showthread.php?p=1916864#post1916864

[StainlessS]

Hello and welcome to the forum Sergey 1400
https://www.cosgan.de/images/smilie/musik/n080.gif

[richardpl]

Using a decompiler to re-code a plugin would I think constitute Code Theft.

This is simply not true at alll.

[StainlessS]

Well it certainly aint doin' it yourself.

[EoE]

Whilst it isn't an AviSynth port, I have now ported CCD to Vapoursynth (as a plugin) which you may find useful. See here (https://github.com/End-of-Eternity/vs-ccd).

[GMJCZP]

After all, is there a version of this plugin for Avs?

[kedautinh12]

No, still waiting for someone interesting about project

[EoE]

I may look into backporting the plugin to avs since there is a lot of interest. I haven't used Avisynth much, or the Avisynth API at all though, so I would probably need some help testing ect.

[kedautinh12]

Thanks, can you add support HBD, luma and more yuv colors space???

[kedautinh12]

you can make the plugin work in both https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest (this is backport of vs DFTTest and now it's work on both)

[anton_foy]

I may look into backporting the plugin to avs since there is a lot of interest. I haven't used Avisynth much, or the Avisynth API at all though, so I would probably need some help testing ect.

Nice! I also am interested in a CCD version for AVS+, I can help out with testing or more. Is there any info on how to port from vs to avs+ around here somewhere? Couldn't find much here on the forum.

[richardpl]

Just use chromanr from ffmpeg, it does not modify Y plane, and does not do color conversion to/from rgb.