Request: someone please fix CNR2

[Boulder]

I'm sure there are a lot of people who process analog captures and would like to have a good and fast chroma denoiser. CNR2 v2.4 doesn't work with CCE and v2.51 is just broken, the value for scdthr has to be insanely high for the filter to do anything and then the filter misses all the scenechanges.

Here's the latest version (v2.51), which doesn't crash in CCE but due to the scdthr issue is unusable at the moment.

http://cultact-server.novi.dk/kpo/avisynth/cnr2_51.zip

Could someone please take a look at the filter?

[rfmmars]

Need to fix the link.

richard

[Boulder]

Hmm, it seems that sh0dan's not hosting the file anymore. Fortunately I've got it on my HD so here's a working link:

http://www.saunalahti.fi/sam08/cnr2_51.zip

[Wilbert]

If someone want to look at it, here are the v2.4 sources (the last one which actually works):

http://www.geocities.com/wilbertdijkhof/Cnr_v24.zip

[Video Dude]

Originally posted by Boulder
I'm sure there are a lot of people who process analog captures and would like to have a good and fast chroma denoiser.

GuavaComb gives good results and it is very fast.

[tritical]

Here you go.

Cnr_v261 (http://bengal.missouri.edu/~kes25c/cnr2_v261.zip)

Got bored and needed something to do :). It should work fine now, and I changed the scene change detection to a more straight forward approach. It works how scene change detection works in temporalsoften, (i.e. percentage of total change). Even added the option to consider luma only or both chroma and luma in the decision (previous versions considered both, though both v2.51 and v2.4 were slightly broken in different ways). If there are any problems let me know.

Note: I didn't get permission from the original author, but hopefully it is ok as I doubt this thread would have started if he was still active and able to fix it. Though, if anyone wants me to take the link down I gladly will.

[Boulder]

@tritical: Thank you Sir! I don't think MarcFD can complain, most of his filters are known to be troublesome at times and he hasn't done anything about that.

@Video Dude: GC is a nice filter but AFAIK it's for removing rainbows only, not for general chroma denoising. It also requires YUY2 data so I'd have to do the colorspace conversion in the middle of the script instead of the end. Thanks anyway:)

[AS]

Originally posted by Boulder
@Video Dude: GC is a nice filter but AFAIK it's for removing rainbows only, not for general chroma denoising. It also requires YUY2 data so I'd have to do the colorspace conversion in the middle of the script instead of the end. Thanks anyway:)

Actually, GC is mainly for dotcrawl removals. The temporal lock also happen to kill rainbows as a side-effect.

[tritical]

The temporal lock also happen to kill rainbows as a side-effect.
Actually, it is anything but a side-effect. GC works at filtering rainbows for the same reason it works on dot crawl... the method of filtering rainbows/dot crawl is exactly the same in stationary parts of the picture (where GC is suppose to work). For NTSC you average the pixels in the current frame with those 1 frame away which are exactly 180 degrees out of phase relative to the current frame (because of NTSC's 4 field color frame) and 2 frames away for PAL (PAL has an 8 field color frame). The reason GC tends to be more effective with filtering dot crawl is because "usually" the cross-luminance (dot crawl) oscillations tends to have less overall magnitude and tend to have somewhat more stable oscillation as compared to cross-chrominance (rainbowing) oscillations. That has a large impact on GC since it uses a max variation threshold and activation/recall settings.

[tritical]

Well, I sat down and benchmarked v2.6 against v2.4 using avstimer. I was pretty sure v2.6 would be faster but just wanted to make sure. This was the case for YV12 processing, as I got an average of roughly 300 fps over 10,000 frames with v2.6 and about 180-190 fps with v2.4. However, for YUY2 processing v2.6 was actually more then 50% slower then v2.4 :eek:. Since this was definitely not acceptable, I took another look at the YUY2 code and found some areas that were in need of a few changes speed wise. After making the changes it now runs full speed again :). Actually, YUY2 processing is very slightly faster in v2.6.1 then in v2.4 (5% or so... 90 fps vs 85 fps on my computer). The speed up for YUY2 processing is the only change between v2.6 and v2.6.1, there is no quality difference.

[Fizick]

Good work!

[codefish]

one late reply :)

@tritical: very good work; took a while for me to find this thread. After desperately trying to cnr2 my VHS-Caps I got a hint (link to this thread) on the german Forum which saved my day!
Do you (or does anyone) have connections to the people managing http://www.avisynth.org/warpenterprises/ ? I think the faulty 2.5-version of cnr2 should be replaced by your 2.61 as soon as possible because (in my opinion) it doesn't make sense to offer the 2.5-Version for download any longer.

saved-day-greetings from germany

codefish

[Wilbert]

The one at that site is v2.61?

[codefish]

take care: at first I thought the 2.6.1 was perfect until I checked motion - the default values have to be lowered significantly (compared to the 2.4) to prevent ghosting. I'm still experimenting, but still I say: good work, much better than the 2.5.1

The one currently to be found at warpenterprises is the v2.5.1 (@Wilbert)

[Wilbert]

I don't get why you say it's v2.5.1. Tritical's download above is v2.61 with size 73728.

The dll in cnr2_25_dll_20040630 from WarpEnterprises has the same size. It is v2.61 according to the readme.

[codefish]

urrh :confused: have I had smoked something wrong? I must really have confused something, or the 2.6.1 is available since some few days only. I was pretty sure that I've downloaded the 2.5.1 just one week ago. It reads cnr_25_dll_20031118.zip...
I do apologize for this false information. The information about the ghosting remains true however ...

correcting-myself-greetings

codefish

[hartford]

Yeah, the "defaults" do not work as advertized.

I'm waiting for a fixed version, ie, if I enter values as shown in readme.txt, they don't work.

[tritical]

v2.6.1 is exactly the same as v2.4 except for 4 things:

1.) Speed, 2.6.1 is quite a bit faster in YV12
2.) rounding differences (maximum of +- 1 change in pixel values)
3.) scene change detection method is different
4.) 2.6.1 doesn't crash

So if you are noticing big differences between v2.4 and v2.6.1 it is the scene change detection as it resets filtering after scene changes. The default for 2.4 is really low (it has a lot of false detections) compared to v2.6.1. However, the default settings for the other variables are pretty strong so the false scene change detections on moderate movement help prevent ghosting. If you want v2.6.1 to act more like v2.4 lower the scene threshold to 7 or 8. Both versions have a "log" option that allows one to see when the filter has detected a scene change.

I also ran a test on a 5000 frame clip to make sure this was true, and indeed the clips matched exactly (except for +- 1 due to rounding) after both versions detected scene changes in the same places.

[codefish]

so now to my experiences:
the defaults (doc-file) read:
Cnr2("oxx",8,35,192,47,255,47,255,false) which is really okay for the 2.4

approximately (I have not tested exactly, simply used my eyes cause they are what I'm finally filtering for :D ) the same results using 2.6.1 are achieved by the following settings:
Cnr2(mode="oxx",scdthr=8,ln=16,lm=192,un=23,um=255,vn=23,vm=255)

So it seems the n-values have to be halved for some reason. But then it works as expected. I didn't compare the SCDTHR however, I trust you (@tritical) with this :)

@hartford: try to halve the n-values and compare the results to the 2.4 please ... (using PNG to save a screenshot helps: if filesizes are about the same, then the result in this special case is about the same, too - my experience! Or use avscompare, to be found at doom9)

addendum: I only tested YUY2 because I'm filtering captures, and YUY2 (besides UYVY) is the only color space my capturing card supports.

[tritical]

After further testing I know what the difference is. The dll avialable from marc fd's website which is labeled 2.4 does not match the YUY2 output from the source for 2.4 that Wilbert linked to earlier in this thread. YV12 output does match however. So that means 2.6.1 matches the YUY2/YV12 output from the source linked to before and matches the YV12 output from the dll on marc fd's website. What was changed for YUY2 I don't know...

[codefish]

so that's not too bad I believe because halving the values just works fine for YUY2.. but one has to take care of input colorspace when using the filter, so I suggest if you plan to update the release someday, simply leave a note in the DOC (I am not a programmer so I won't easily be able to look for the "error" in the code which seems to be a forgotten multiplicator or divisor)

Good work, just to repeat once more :) you've helped me very much with your 2.6.1 !!!

analyzing greetz from germany

codefish

[tritical]

To be quite honest I'm not sure if it is an error. Even the source included with the dll currently on marc fd's site matches the output from the source wilbert linked to before and the output from 2.6.1 and does not match the output from the included dll itself. Also, the way YUY2 is handled in those sources seems to be correct to me. I guess I could simply change the defaults for YUY2, but I don't really see a reason too as users should be tweaking the settings for every source anyways :p.

[codefish]

I just checked the "original" CNR 1.1 for VDub (Gilles Mouchard), the defaults read 16, 21, 21 for the n-values - higher values start the filter to produce ghosts. Seems the defaults for cnr2 v2.4 have been chosen wrong... after seeing this (I did not check before I must admit) I also believe it's correct the way you "finalized" it. Shouldn't have compared it to the 2.4 ;)

Video processing can sometimes be rather confusing, but it's very much fun, too (I just started one year ago as a complete know-nothing...)

...and of course you're right, filters should be tweaked for every material which I usually do - cnr(2) was my only favourite which clearly showed that the defaults are just fine for anything I tested it with (but it's NEVER the only filter I use - it's for prefiltering VHS-Caps only!)

:thanks:

[royia]

What's the latest release of this plug in?
According to Trtical home page:
http://web.missouri.edu/~kes25c/
It's 2.61 - 30/06/2004.

Yet here:
http://avisynth.org/warpenterprises/
There's a CNRk version dated at 13/3/2005.

What's the difference?
Thanks.

[kedautinh12]

New Cnr2 port from vapoursynth support HBD
https://github.com/Asd-g/AviSynth-vsCnr2

[StainlessS]

Cheers kedautinh12, CNR2 was always a pretty good filter to have.

[romangal]

Cheers kedautinh12, CNR2 was always a pretty good filter to have.

Is there any differences comparing the last avisynth release? Or i just need to try a vapoursynth version? Thanks.

[kedautinh12]

Is there any differences comparing the last avisynth release?

It's support HBD and more colors space

[tormento]

New Cnr2 port from vapoursynth

I have tried to replace Cnr2 with vsCnr2 and I get the error that scdthr must be between 0 and 100, while my original cnr2 line was

Cnr2(mode="ooo", scdthr=255.0, ln=255, lm=222, un=255, um=255, vn=255, vm=255)

Have I to evaluate those numbers in scale between 0 to 100?

[kedautinh12]

I have tried to replace Cnr2 with vsCnr2 and I get the error that scdthr must be between 0 and 100, while my original cnr2 line was

Cnr2(mode="ooo", scdthr=255.0, ln=255, lm=222, un=255, um=255, vn=255, vm=255)

Have I to evaluate those numbers in scale between 0 to 100?

Why you set scdthr parameter very high value when default just 10??

[tormento]

Why you set scdthr paramete very high value when default just 10??
Not my script. :)

[kedautinh12]

Not my script. :)

Try compair between vsCnr2 and Cnr2 with value of scdthr

[Boulder]

With scdthr at maximum in either case, there will be zero scene changes detected. Normally that would be a very bad idea, but probably there's some logic behind that thinking in the original context.