"Shadow edge" Filter: it's possible :)

[Kurosu]

Hi all, here I go for my first post here!

Reading OUTPinged_'s post (http://forum.doom9.org/showthread.php?s=&threadid=32901) on how some shimmer can happen on video captures, I came with the idea of a filter I've implemented. This is mainly experimental ground, therefore "slow as hell" :D but source is included to give you an idea. It's released under a license (first time for me), the GNU LGPL license. If you want me to clarify my notes on that matter, you're welcome. It is hear to respect the originals authors of avisynth and Visual C++.

You could read the text provided in the archive, but I list the "features":
- choice of the kernel type used for edge detection (first isn't very effective)
- edge detection threshold (values -1, -2, -3 will try to find a good value), yet the detection doesn't have to be that precise (it seems not all edges have to be chromafiltered)
- temporal chromasmooth strength (if you see the code, you'll understand it's more of a fancy name :) )
- choice of a spatial chroma smooth type (not strength, all available options lead to different function

I've attached the DLL to have moderators approval, but you may also get it from my "site". :rolleyes:

One last note: I'll be away tuesday for like 20 days. I may reply, but I won't be able to update the dll.

Note: sorry for the earlier post

[OUTPinged_]

It works flawlessly on my test clip with default settings.

I dont have dvd atm but i will test it sooner or later.

Thank you for writing such a flexible tool.


note to everyone: use it _before_ resizing.

[Guest]

@OUTPinged_

Any chance of posting small before and after pics? Thanks.

(BTW, about your mouth clip. I'm working on improvements to the field matching to address this. May take some time.)

[OUTPinged_]

Here it is (yes, the result is incredible).

Basically the worst part of a source in this clip is a heavy shimmering of a rainbow. I can post a clip on http if somebody wishes for it.

[OUTPinged_]

@DG:

err... There wasnt anything wrong with decomb and this clip until i tried to use mode=2 for telecide. With mode=0 it is supposed to work ok.

[Guest]

Indeed, the result is impressive. Well done, Kurosu!

(OUT, then you just got "lucky" that Decimate threw out the badly matched frame. The field matching should not have emitted it.)

[Marc FD]

Whow !!
impressive.

@Kurosu
a new coder, and a french one :)

i can take long holidays now :D

(EDIT : out topic @outpinged : i recognise the CowBoy Bepop End credits. right ??)

BTW, when i think on it, i remember i used Cnr2 on rainbow artifacts (VHS tapes like CowBoy Bepop & Blue sub. no 6) and there were all gone.
Have you tested ??

[Defiler]

Sugoi!

[Kurosu]

Well, just before I leave, some news for you guys out there. :D

@MarcFD
Hehe... Yeah, I thought it would be better that I try and write one myself, otherwise you would have even less time for your filters.
Btw, your version wasn't working on my comp, rewrote it a bit and went fine, so if you like I can send you the "new" code (I don't think I should attach it, it's your tool anyway ;) )

@OutPinged_
Indeed, I try to write it for unresized videos, but looking more closely to it, I think it's the better way. Alas black borders may produce some bad results. I'll see if it usefull to add an "area of interest" (macroblock wise).

@all
Spatial filtering could may be do by DCTing/dropping high frequencies values/iDCTing... I think it's too computational, and my filter is already sluggish :)

- There's room for speed improvement. I don't know assembly language, so I can't optimize the processing that way.
- considering that most people will encounter "rainbow effect" on MPEG-like video, I'm trying to optimize the way it works using that fact: if rainbow, whole macroblock U/V planes are screwed => _heavy_ filtering. But that will change most parameters (I dropped selection of kernels, no more autothreshold for edge detetction): the plugin has to be rewritten. I have sort of branched/forked from the original version, but I don't think the previous branch won't evolve much...
- if you look closely to U/V planes using see() from MarcFD , you'll see that in fact it also filters needlessly some parts of the picture

The worst part of this work is that it seems to raise no questions :D

I think anyway that temporal averaging has better chances to clean the source than spatial one: haven't tested it extensively after I solved the bug, but something like .AntiBlink(3,-2,0,[1-4]) would let much rainbow artifacts left. Btw, there is no scene change detection, so temporal smoothing can smooth with wrong values... ChromaSmoothing is done a particular way ([1-3] are just region averages, 4 is a blur) and so settings [1-3] may produce strange results. Therefore, use them very scarcely (3 should the best one, stronger filtering than 4 is required). Yeah in fact, the strongest is 1, the weakest is 4...

I attach a version where I think I fixed some strange artifacts (don't ask why they were there, it was a shame I let them!). Maybe cosmetic, but the first one was so unreliable... :rolleyes:

One final word is on the license: I rushed a bit to set it up, so it might no be done the proper way. Anyway, I found a page where to compile dlls with gcc: using its port to windows and/or for instance djgpp, one can withdraw the use of MS VC++, and use a real GPL license ( not sure on how should be the license when providing a DLL compiled with MS VC++). Or so I think... At last minus high optimizations from Intel/MS compilers :D

[OUTPinged_]

@Kurosu:

The best part about your filter is that it works on my test clips =)

The spatial part is questionable and imo a detection of a non-temporal rainbow type can be done by an algo similar to one's used in interlaced lines detectors, and you will have to take into account U and V pixel values.

I think i had a PAL DVD with static rainbow, if i will find it i will probably introduce a torture clip that will most likely be tough for your plugin.

[Ezzelin]

Here's a torture picture. I can't seem to get this rainbow noise out, and I would be very impressed if anything could. Still, that doesn't mean it can't be done. :D I can send a huffy of more rainbow beard action if anybody wants it.

[Taranli Maren]

Using trigun as my test clip, I attempted to use this filter. In the intro though, I got a lot of what I can only describe as color ghosting. I've tried a number of settings, and they all do it, though setting the differential filter to 1 makes it less, its still there. Here is a picture of what it does with differential filter 2 and 3. (Notice the cloak)

http://zhentarim.cjb.net/pictures/color_ghosting.png

I've been using Tim Park's smart smoother IQ for a while now, and its been working well, though it is incredibly slow (since you have to use it twice in a row most often). Would not spacial smoothing work better than temporal for this, since it doesn't always *blink* a single frame or two.

[Kurosu]

Hi all,

I can't fix those known problems for now (maybe in 2 weeks). They come from the fact I don't use scene change detection (and I think it's difficult when it only matters on a small part of the picture), and mostly because the algorithm I use is very primitive: find edge, temporalsmooth it (spatial removes almost no rainbow effect).

I have redesigned a bit the detection of those rainbow effects, it matches much better them (like 90% and only 20% badly detected, while the previous one is a bit ugly: test with range [3rd parameter? I'm a bit out of it atm] -1 to see the edges which will be used to detect rainbow effects.

If the new design doesn't help much, I may add something to detect changes (SAD) in the filtered macroblock. Please post those troublesome videos, but be aware I won't be able to use for the next 2 weeks.

Sorry for the ones that had high hopes in this filter, it's only experimental, and I was just intending to demonstrate my ideas on the matter.

@Taranli Maren
The first differential filter seems better, because it does a worse job at detecting the edges :D
I diagnose the problem as following: there are edges there, and I wasn't testing before if there was really rainbow effect. I fear that doing too many tests may slow down much the filter. Anyway the ghosting effect comes from the fact the cloack is moving fast. Temporal smoothing is needed to diminish this temporaly random effect, and here, it uses parts that have changed. Problem is that changes here are as important in chrominance as in luminance: detecting this change may not be easy.

[ErMaC]

I agree - the problem is that the red cape was there before, and now it's not and instead there are edges there... so the smoother sticks red there.

What could be done is the smoother could look in both temporal directions - one frame ahead and one frame behind, or more - and choose the chroma from the frame which more closely matches the chroma of the current frame.

From what I understand, this is basically just a temporal smoother paired with edge detection - like I suggested in a thread about Don's new filters a week or so ago (no I'm not claiming the idea). Why not take Don's edge detection (which appears to be fast) and then simply pair it with one of the current temporal smoother plugins (which also appear to be optimized). Or am I missing something obvious and/or I'm just stupid? I can't rule out either possibility. :D

[Guest]

@ErMaC

I'm already working on that and have a beta out there already. It's called DGdnr(). There are still several important issues to be worked out.

See here:

http://forum.doom9.org/showthread.php?=&threadid=32298&highlight=DGdnr

[Taranli Maren]

@neuron2
Is your filter going to be able to smooth chroma?

[Guest]

It would be optional. But be aware that there is no guarantee that the obstacles will be overcome. I am currently researching into edge detection and I can't predict if a good solution will emerge.

[Kurosu]

@Taranli Maren

Could you post a sequence clip ?

@To Neuron2, or any person working around that matter...
If you observe closely the UV bands, you can see there are 2 points easy to notice:
- it changes frequently
- it has an high activity
- it happens mainly on macroblocks

The first point can be discarder, because a scene change produces the same result. However the second can prevent from applying a heavy temporal smoothing on edges that shouldn't.

In addition, to prevent ghosting effects, if an inter-frames comparison is needed, then it should be done on Y.

The last point drives me to the conclusion that 2 filters could be written:
- one especially used for DCT-based coders
- one that would try (because it seems harder) to do the same job but at much finer level...

I've implemented the first with my different remarks, I'm waiting now for a torture clip :)

[Defiler]

Kurosu:
In the other thread, I linked three versions of the same test sequence. I'm not sure if you say them:
XviD format, ~1MB:
http://hellninjacommando.com/misc/avisynth/rainbow.avi

HuffYUV, ~35MB:
http://hellninjacommando.com/misc/avisynth/rainbow-huffy.avi

HuffYUV, ~13MB:
http://hellninjacommando.com/misc/avisynth/rainbow-huffy-60.avi

I hope these help. They were some of the most obvious rainbows I had sitting around.

[Taranli Maren]

@Kurosu
I've emailed you a link to the file. It actually has a little bit of the color ghosting from the source, but nothing like what the image showed. I can also send you a clip of some incredibly bad cross-coloration, from the Armitage III OVA. R2 dvd.

[High Speed Dubb]

Could anyone post a sample of PAL video with rainbows or dot crawl?

Pretty please? :)

[Kurosu]

@Defiler
I was already using your clip, which is usefull. However, the main problem is now that high motion provokes ghosting artifacts, due to the heavy temporal smoothing (averaging in fact)necessary to kill rainbow effects. I still haven't tested the 60fps version, but I don't think that will be much different from the previous clips.

@Taranli Maren
Thanks, I'm dl'ing it. I think it will be a good test for the ghosting artifacts.

@High Speed Dubb
Never Twice the Same Color :)
However I have rarely see PAL material with this problem, unless it was a NTSC master awfully transfered to PAL (some DVD editors, more particularly regarding anime, let the DVD player hardware do their job...)
Anyway, I haven't such material.
Btw, if you have links or docs (OutPinged_ had some, but in Russian) dealing with the problem of aliasing between Y "carrier" and U/V ones in analog signal, it could be of great help to design a better filter. The one is a bit dumb :D

(hope that time my post will be recorded)

[Kurosu]

@Defiler
No particular enhancement using the 60fps clip.

@Taranli Maren
Your clip has no rainbow artifacts. However it was useful, because one can see that the filter tends to filter areas which don't show such rainbows.

@All
Using those 2 videos (from Taranli Maren and Defiler), setting the filter to... filter perfectly Defiler's clip provokes ghosting artifacts in Taranli Maren's clip. But settings avoiding ghosting artifacts in his clip does a worse job on Defiler's clip. So this filter is far from perfect.

The solutions I may use when processing the video, macroblock-wise:
- only filter pixels with high luma (Y), because chroma variations there are more sensitive. This will prevents areas with edges, but sufficiently dark to not show rainbows, to stay unfiltered.
- looking at the U/V planes, maybe I should count the number of pixels where variations are higher than a chroma threshold. Because it's more their number than the intensity that reveals the rainbow effects. Moreover, it may be possible to only use that criterium (not the edge one) on those kind of videos.

Considering other videos (not macroblock-wise), I still wonder how to do an easy job on them...

I'm opened to any idea ;)

[kyousuke]

i tested it, it's very impressive with a good setting.

just one thing, be careful about the color degradation with the 4th int parameter.
i tested the four parameters, the 0,1 and 2 gave good result on my video (band of brothers) but the 3 changed the colors too much if i remember well. for the 4th, i forgot ^^;

i'm sure that your next version will be better, more and more.

congratulation
see ya! :D

[Kurosu]

I'm maybe posting too much and should test more before posting, but I come with a total new setup. More explainations in the previous posts, and of course the avisynth.txt, cleaned this time.
Beware, it's macroblock based, so myabe it has now a too strong effect for your needs.

Basically, it still doesn't test motion, but should be more accurate. However, it will be very picky with the 2 first values (see text file for setting it up). So, visually, a maybe less effective result, even with more testing, but a lot less possible degradations (or so I hope).

I'm still searching a good metric to test if the macroblock has rainbow, but the one used seems ok...

Good luck with testing

[Guest]

Bump due to delayed approval of attachment.

[High Speed Dubb]

@Kurosu,

Take a look at the online chapter from The Engineer's Guide to Decoding & Encoding
http://www.snellwilcox.com/reference/pdfs/edecod.pdf

[um... except that it seems to be down right now -- would you like me to email it to you?]

That’s a good description of each of the color encoding formats, as well as ways to separate them from the luma signal.

There’s an especially interesting looking algorithm for PAL color separation (called a “diagonal comb filter”) near the end of the document — But I don’t trust myself to program it right without some actual test material to work on.

So based on theory, PAL should have color crosstalk problems, too. But apparently they’re less visible. One interesting thing I’ve noticed from the boards is that people in the US tend to talk about problems with rainbows, while people in Europe tend to notice problems with chroma noise. I suspect this is due to the color encoding differences.

On a related topic — Here’s one way to avoid artifacts with this. Instead of using just information for the past few frames, keep a field-sized array which tracks how much each pixel has shown evidence for crosstalk. Slowly decay the old values for evidence, and add in the new ones. When the cumulative amount exceeds some threshold, you can decide to smooth the chroma (and luma, for that matter). This isn’t an easy approach, and it will miss any crosstalk that is only in a couple of frames, but it works well for any crosstalk in stationary areas.

[Kurosu]

@High Speed Dubb

Thanks for the very interesting link, and sorry for the late reply. As your idea even more underlines, I fear that there isn't a good method: I'm considering 16x16 blocks (because videos I had were only affected on entities of that size), you're dealing with PAL signal properties. I'm not familiar with those considerations, but I'll look more closely: maybe a good idea will pop up :)

Concerning your idea:
- to detect possible crosstalk, I count how many pixels are likely to be crosstalks. Looking at the blocks in UV planes clearly show high activity. I simply count the number of pixels which derivative (calculed by Robert's filters) is higher than a certain threshold, then consider a threshold number of pixels for which the block is considered as to be temporally smoothed (the more sample the better, if no ghosting artifacts :( )
- your idea would likely give a more precise result by only affecting some pixels, not the whole 16x16 block. However, the only material I have is from MPEG source. Maybe people from the capture and TV encoding forums could provide us with more general "rainbow artifact" (not shadow ^^;). As a result, I dunno. All the matter involved is "when can we consider that a pixel is a crosstalk". My MPEG source show a block basis:
Original image (http://kurosu.inforezo.org/avs/RGB0.png)
Y Plane (http://kurosu.inforezo.org/avs/Luma0.png)
U Plane (http://kurosu.inforezo.org/avs/Chroma0.png)
- I'm not convinced by the the spatial smooth. I put some sort of spatial smoothers (blur, then filling with average on parts of the 16x16 block) but their result are awful. Just imagine a logo or something of the like with a lot of chroma activity (high frequencies I mean), detected as crosstalk. Smooth it. Yuk...

My idea is to expect that the crosstalk is due to a random signal added to the UV planes. Then, by temporal smoothing it, you will reduce it. The next idea is to use local information, like Y values, to do a sort of deconvolution to remove the aliasing due to Y signal. Fact is that I dunno if people would be interested in a very good filter but slow as hell. Anyway the doc you pointed out will certainly be really helpfull. I tried to find such a doc. Moreover, i've bookmarked the whole site for "theory basis" :D

Btw, I had no answer like effective/uneffective, bugged, hard to setup and the like on my lattest build... I think I'll do for my own sake some additionnal developments, but is there anyone that would like improvements? Or should I crosspost to the capture forum ?

[ronnylov]

I tried the macro block based antiblink on a captured PAL movie. It works very well except in the scene changes. I get blocks with different colours that not look very nice the 2 frames before and 2 frames after each scene change.

I attach an image of how it looks on a frame before a scene change.

[Kurosu]

Good! Feedback, I love feedback :)

I prepared something to verify scene changes (very basic at start) and was waiting for such a report. Drawback: even slower (unless you feel speed is ok :p )

I'll give news whenever the results are ok with my sample clips.

[ronnylov]

Well, I found out that it worked better if I used noise filtering after antiblink instead of before. I also changed to Antiblink(3,32,2,4) for dirty sources. It seems that my analogue TV capture needed this setting. Now the blocks is not as visible but there is still some kind of smearing at scene changes. I attach an image right after the scene change above. The color of the blue wall and the faces are left on the first frame after the scene change and after 2-3 frames the picture is normal again.

My capture resolution was 528x576 and my destination is 704x576 DVD (I did not have enough hard disc space to capture full resolution this time).

I used this script:
--------------------------------------------
SetMemoryMax(40)
#
LoadPlugin("E:\Download\Videoverktyg\Avisynth Plugins\Convolution3D\Convolution3D.dll")
LoadPlugin("E:\Download\Videoverktyg\Avisynth Plugins\Antiblink\AntiBlink.dll")
#
source=SegmentedAviSource("G:\AVI_IO Capture\capture.avi").trim(0,201588)
#
# Macroblockoptizing of film (plus top letterboxing)
Film=Crop(source,17,131,492,312)
Film=LanczosResize(Film,672,320)
Film=Antiblink(Film,3,32,2,4)
Film=Convolution3D(Film,0,6,16,6,16,2.7,0)
Film=AddBorders(Film,16,128,16,0)
#
#
# Macroblockoptimizing of subtitles (plus bottom letterbox)
Text=Crop(source,54,445,420,80)
Text=LanczosResize(Text,560,80)
Text=Antiblink(Text,3,32,2,4)
Text=Temporalsoften(Text,3,32,128)
Text=AddBorders(Text,80,0,64,48)
#
# Display the subtitle below the film
Return(StackVertical(Film,Text))
---------------------------------------------

[Kurosu]

Well, I found out that it worked better if I used noise filtering after antiblink instead of before.

You're totally right. the video should be unfiltered/untouched when fed to AntiBlink. In order to speed the whole think and have better results, I don't test edges anymore: I just look at the activity of the 16x16 block (as described in the .txt in the archive) in the U plane. Using a spatial (and certainly a temporal filter) such at SpatialSmoothMMX, Convolution3D and such will reduce the effectiveness of the detection, unless you set them for only affecting luma (Y).

For the ghosting artifact, that's quite simple: I don't test scene change when temporal smoothing. when using Antiblink(3,32,2,4), you check if half of the pixels (32) from the 16x16 blocks have an activity higher than 3, then you ask to use the 2 previous pixels (in time axis) and the 2 next to do the temporal smoothing (last parameter has been disabled in this release for it is bugged). Therefore, a scene change occuring in one of those frames will affect the pixels used for tempsmooth.

I'll be using luminance for scene change detection: using chroma is ineffective because of the rainbow effect.

btw, I set up the filter for not filtering the x first and x last frames of the video (x being your tempsmooth strength).

[Defiler]

It seems to me that these rainbow edges have a couple of distinct characteristics:
1. They occur in areas of high luminance. If you've got a black rainbow, you can't see it.
2. They have high frequencies in chroma-space.
3. They change drastically from frame to frame.

What would happen if you did a Fourier transform on all the blocks in chroma-space to find all the blocks with lots of color frequency data, masked out all the areas that fell below a certain luminance threshold, and then compared that to adjacent frames?
Sounds a bit like the "correlation surface" that the really advanced motion estimators use.

[Kurosu]

Hi Defiler,

1. More visible indeed. In the current filter, I skip pixel which luminance is beneath 31
2. True: that's why I try to find by detecting how much pixels are likely to be from a rainbow artifact. I call that activity, and it's even more visible in U/V planes
3. I agree, therefore the "AntiBlink" :)

Your ideas are great. If you remember earlier antiblink.txt coming within the archive, you know I was thinking of dct or whatever mean to access frequency components. Three ways then:
- using normal pixels value and track the pixels with too much variations in chroma planes (for instance, by looking at previous and next frames). That is High Speed Dubb. it could however be highly sensitive to motion (scene change detection)
- do a DCT/FFT on the 16x16 block and see if frequency values are more or less regularly distributed (something close to physic white noise - maybe testing high frequencies would be sufficient as you said), then filter most away. This would do spatial smoothing. However, the error is most disturbing because it "blinks". A temporal smoother seems better there
- another way still not explored, maybe lying in the document High Speed Dubb linked. Maybe a more computational exepnsive processing is needed, but it would yield quite better result, as we would know more precisely what to remove.

The FFT/DCT solution is a good one, could benefit from using existing optimized code (XviD for instance), but I don't consider myself as a seasoned programmer: the code isn't optimized at all, and won't certainly be.

Unless forgiving souls would point me some online usefull resources and bear with my annoying questions :D

Notice that this filter is more geared towards particular sources. I've now seen such result due to typical aliasing (grid lines) on pal video (therefore, High Speed Dubb, tell me if you want some - I don't use them but I'll capture some). But the files I want to work with for now (unless someone really want me to do test on a particular file) are of the previous type.

For now I'm working on ghosting artifact and rewrite quite a bit the code. But more bugfix to do, then :/

[High Speed Dubb]

Kurosu,

Yeah, it does look like color crosstalk in compressed material is different than crosstalk in broadcast video. With NTSC, regions of crosstalk can be pretty much any shape (though they tend to be tall and thin, following vertical lines in the picture). The changes caused by compression probably mean that any spatial comb filters will fail. (And I haven’t had any luck getting one working for broadcast material, either.)

Yes, the method I described is very susceptible to motion, but that’s easy to fix — just check that the pixel value at field t=-4 is sufficiently similar to the pixel value at field t=0. (That’s for NTSC — I think it should be t=-8 and t=0 for PAL.) Combine that with reasonable values for the “is it shimmering” threshold and motion artifacts are avoided. (But it does cause problems with strobe effects — That’s probably unavoidable since the algorithm is pretty much designed to detect strobing.)

I agree — moving to frequency space is worth a try. It could even be pretty cheap to do for broadcast material, since you’re just looking for a single specific frequency (the color carrier frequency). But from the pictures, I’m not sure whether compressed material will still have the same signal.

And yes, it would be great if you’d capture some PAL color artifacts. I’m pretty sure there are still some problems with what I’ve written for PAL.

[Kurosu]

@All
I'd like some (can be short, like 25 frames, of any sources) videos sequences with both "rainbow" effect and motion (like ronnylov's) to check how the new code does its job. I urge everyone interested in the matter to provide High Speed Dubb appropriate sequences, as his work is directed in another direction than me. Both works concern everyone having trouble with "rainbow" artifacts.

@High Speed Dubb
I'd like to go slowly from the simple observations-ideas I had to more general ones. Indeed I've worked on material that were particuliarly fitting what I attempt to filter. But I don't know if it should be pixel-wise or block-wise. Both "activity" basis and High Speed Dubb's ideas are good ideas of what's happening. I guess that his idea is more general and more suited to artifact coming from video captures.
About the fix: I guess you're speaking in terms of luminance, calculating something like SAD for motion estimation.

Regarding the frequency analysis, this is going to be my next step. When analysing the causes of the rainbow artifacts (aliasing of Y signal and U or V), it seems some better results are possible there. And it would be a finer measure for my "activity thresholding", the one I'm using right now.

(I'm really doing long posts :D )

[ronnylov]

Hi Kurosu!

I would love to send you a short clip of the TV-captured movie but unfortunately I have already deleted my original capture because I needed the disc space for other capture. However I found that the final result after compression (MPEG2 on DVD-R) was very clean from the rainbows! And the scene change artifacts was hardly noticable in full speed playback. It compressed very well also.

I have a channel that produces rainbows at capture so I can try to capture something representative. How (where) should I upload the sample clips?

I capture with AIW Radeon and AVI_IO. In AVI_IO I can only tune the channels to fixed channel numbers but in ATI MMC capture software I can set the TV channel frequency more exact and thus get ride of some of the rainbow artifacts. I can try I short capture with both softwares on the same channel as a comparison. I don't capture longer clips with ATI MMC because of the file size limitation on FAT32.

[Kurosu]

@ronnylov
I'm very pleased you already find my filter usable in spite of the error you reported! Sometimes, for captures, I use _YUY2Clean() that gives pretty good results at removing little noise, but produce some effects of the kind. Btw, was your video subbed?

For uploading the video, I'm still wondering: I'll give you in private the details, and why.

In my case, I use an ATI Radeon Vivo DDR (7200 now, I think), and I let the taperecoder do the tuner work :D
I use VirtualDub as it gives me good performance, and I can tweak the program. I indeed don't capture anymore in MMC because of that limitation ( I really like the possibility in VDub to give different "spill drives").

[ronnylov]

Hi Kurosu!

Please post a link to the _YUY2Clean() filter.
I could not find it by a quick search in this forum
or searching internet.

I think "the error" I reported was that I used "wrong" parameters and that I did not filter after antiblink(). This filter needs another filter afterwards to remove the blocky edges. I can see the ghosting sometimes at scene changes but it is less annoying than the chroma noise I had on saturated colours and sharp edges before.

The rmPal filter in Virtualdub helps but it is not as efficient as your antiblink filter. RmPal does not remove the raimbows.

[Kurosu]

@ronnylov

for the thread (didn't test if it was still up). Additionally, it requires an Athlon or PIII comp (int SSE+MMX)
http://forum.doom9.org/showthread.php?s=&threadid=31092
I had also mistaken its correct name :rolleyes:

The error I was talking of is the ghosting, neither a wrong setup of the AntiBlink nor the order of filters. I have no appropriate video sequences to test it, and additionnaly, my pm to you was lost... I'll resend.

Just to keep you warm and help you wait, the filter syntax uses a difference between blocks to choose not to use a block in the filtering (depending on a threshold you'll have to use), and another threshold for the level of luminance above which to filter (dark pixels won't be filtered).

[Kurosu]

Some bad news (for now, I hope) after trying ronnylov's clip: it simply throws away the rainbow detection I use now. Used on an interlaced and noisy video capture, there are too many false detections whatever the settings are. I think an interlaced video may throw away any frequency-based solution as it radically changes the distribution of pixels. Obvious, but quite dangerous if the video hasn't been previously processed by decomb/greedyhma/ivtc (select your prefered ivtc/deinterlacing avisynth filter)

Additionnaly, the scene change threshold isn't that effective. Maybe some people could help me on that matter: I use Sum of Absolute Differences over a 8x8-pixels luma block (I've switched to that because blocks were 8x8 not 16x16 in what I've seen). But there may hardly be any difference on relatively constant blocks (while they have really change, the chroma changes may be due to a rainbow), therefore I maybe should increase the size of the block where I calculate SAD. I'm now just averaging the value, then comparing it to a threshold to set. Wouldn't it be more efficient to compare AD for a pixel to this threshold, then decide if a change has occured using the final value (ie when for instance 64 pixels out of 256 are considered to have changed makes the whole 8x8 or 16x16 block considered as changing) ?

For the good news, the idea Lindsey gave seems the best way out: insensitivity to interlacing, and some tests showed a sort of periodicity in the shimmering. I have SECAM and NTSC relatively stationnery video to quick test that, but I however hope I won't have to implement pattern guide... :D

I guess I'll have to drop the "spatial activity" now, and maybe reincorporate it back later if it happens that it has better results on some materials.

[High Speed Dubb]

Well, what I’ve worked out does work with interlaced material, but it isn’t really insensitive to it. I’m not sure the algorithm would work with progressive material. (There’s some code in there to handle progressive source, but I’ve never tried it on real video.) On the plus side, I think progressive material — unless it comes from line doubled interlaced stuff — shouldn’t show color crosstalk.

[ronnylov]

Originally posted by High Speed Dubb
Well, what I’ve worked out does work with interlaced material, but it isn’t really insensitive to it. I’m not sure the algorithm would work with progressive material. (There’s some code in there to handle progressive source, but I’ve never tried it on real video.) On the plus side, I think progressive material — unless it comes from line doubled interlaced stuff — shouldn’t show color crosstalk.

The clips from the movie "Devil's Advocate" I posted was progressive video from a PAL TV capture. It was not deinterlaced in any way but it still shows the crosstalk. But maybe this is "line doubled interlaced stuff"?

I found a method that removes the PAL shimmering but it does not help to remove the "rainbows", it actually makes the rainbows a little bit more visible. It "destroys" the interlacing in the chroma plane but as I see it is already destroyed in my PAL captures because of the shimmering in saturated colours. I downsize the heigth to half and then upsize to the full height again and only use the chroma and merge that to the original luma. It's the same method as the virtualdub filter rmpal use but I found "my method" using bilinearresize more effective. If I use verticalredceby2 I get the same results as virtualdub rmpal filter which don't remove all the horisontal colour lines. I don't like to use the virtualdub filter in avisynth so I used the following script to do it in avisynth:

#--------------------------
source=SegmentedAviSource("capture.avi")
#This source clip has 704x576 resolution
chroma=BilinearResize(source,704,288)
chroma=LanczosResize(chroma,704x576)
return(MergeChroma(source,chroma))
#--------------------------

[High Speed Dubb]

Yep — any PAL or NTSC capture starts out interlaced.

Your trick depends somewhat on the way the material was deinterlaced. If it’s done perfectly, though, it should work pretty well. It would lose chroma resolution, but also get rid of any chroma (but not luma) crosstalk. (But I don’t think this would work for NTSC unless you offset by one line before downsizing the chroma.)

[Tofusensei]

Heh, I know this thread is good and dead now...

But riding on these many more months of experience, what is generally accepted as the best method of cleaning up rainbows/dot crawl in analog captures? (While being limited to avs 2.5 and virtualdub filters, sorry guava comb ;_; )

[Wilbert]

sorry guava comb ;_; )
There's a way to use v2.0x plugins in AviSynth v2.5. See faq (get the LoadPluginEx.dll from the warpsharp package).