Interlace detection and processing for anime interested, accessible, important

andy

Hi everyone,

Some of you may know that I have been working on an algorithm for Source Detection or interlace detection, which is now accessible through MeGUI. See mediawiki/wi...lace_detection for details if you are interested. It has information on the algorithm as well as where to get it.

Based on the advice I've picked up around the place, I put together my algorithm. It uses IsCombed() as an important metric, but it also takes into account motion between frames when doing this, so that things aren't taken to be progressive simply because they are static. In effect, sections with duplicate frames are simply ignored.

And therein lies the problem. While this strategy works well with real-life sources, anime is a different issue. Since anime is often only produced at 8fps or 12fps, there will often be a lot of duplicate frames, and this algorithm will just ignore those sections. This can mean that it ends up using very little data and coming up with bad conclusions. I need some better way to deal with it.

So, finally, here is my question: Can someone tell me how they recognise interlace patterns in anime when looking at sections of frames, and can someone also say how an appropriate way to deal with these results is? If you recognise that you actually have a 12fps source, do you (T)Decimate it down to 12fps, do you use (De)Dup or do you leave it alone?

I'm sorry about my ignorance -- I don't encode any anime, so this world is a totally new one to me. Also, most of the guides that I find on this are based around real-life sources, not anime.

Thanks for your help,

berrinam

*Bump*

I know it's a very vague question, but any kind of answer would be much appreciated. Since I am someone who has never encoded any anime, and I don't have any, either, it is a bit hard for me to deduce theoretically.

I'm just really asking how people generally process their sources.

Thanks again,

berrinam

A couple of friends like to use yatta and manually decimate every single cycle. I just add tfm and spot-check, if there's any issues add a tdeint+eedi2 sucker punch.

Everything I touch is hybrid for some strange reason, so it's always two-pass vfr decimation. The timecode output usually lets me know if I'm dealing with something close enough to pure to just force it. (The way I tell something's pure interlaced visually is that tfm w/pp=0 does nothing.)

I also spend too much time on each project, though, heh.

@berrinam
Are you thinking on further developments on your standalone tool?
I think it would be very usefull to my SynthEditor... by the way... do you think you could add a quot;Field Orderquot; detection on Interlaced stuff?
One other question... I made a few tests on your latest release and I found that it, sometimes, gives me different results from the one I get with DGIndex (speaking of MPEGs, of course)... if you want I can get you a sample.

thank you.

edit: by the way... some cli options would be great too


Originally Posted by foxyshadisA couple of friends like to use yatta and manually decimate every single cycle.

In an automated situation that's pretty much impossible, though, right? Sounds excessive anyway.

I just add tfm and spot-check, if there's any issues add a tdeint+eedi2 sucker punch.

Let me just clear this up (I'm being slow to make sure I don't make any assumptions I shouldn't) -- anime is natively progressive, so firstly we assume that any combing should result from a re-ordering of fields, which we can correct via TFM. If we STILL have combing, then you add a deinterlacer specialising in line-based interpolation (tdeint+eedi2) to basically postprocess the field-matching. Is this what you are saying?

That sounds like a simple enough algorithm.... but what happens to telecining? Running a telecined cartoon through TFM should result in progressive-looking frames with a slightly jerky motion sequence. Is the idea in this case that anime has so low motion anyway that the jerkiness isn't noticable?

Everything I touch is hybrid for some strange reason, so it's always two-pass vfr decimation.

You haven't mentioned decimation yet.... I'm confused; why do you need to decimate?

I also spend too much time on each project, though, heh.

Well, once I perfect Source Detection for anime as well, you won't have to

link I posted in my first post here. It has details about the algorithm, accessing the code in MeGUI, limitations, etc.
by the way... do you think you could add a quot;Field Orderquot; detection on Interlaced stuff?

It's been there for a while.

One other question... I made a few tests on your latest release and I found that it, sometimes, gives me different results from the one I get with DGIndex (speaking of MPEGs, of course)... if you want I can get you a sample.

Well, I'm pleased your interested in it, for starters. There are a few things to be aware of, though:You should really use it through MeGUI, though, because I haven't updated the other one for ages.
DGIndex works quite differently from my app; namely, DGIndex simply uses flags from the stream, whereas my app analyses the video and deduces it's stuff from that. The end result is that hard telecines will be detected by my algorithm, but not DGIndex's
My algorithm is quite sensitive and also only analyses 1% of the video (this can be changed). It can be misled by false results in Decomb's IsCombed function, which forms the main part of the analysis. This can lead to things being declared hybrid when they in fact aren't. I have three ideas for solving this issue:moving from IsCombed to IsCombedTIVTC, leading to better matches. From my tests, this has worked very well.
Desensitizing the algorithm, so that it doesn't detect so many things as hybrids. This also has the consequence of not detecting so many hybrids.
Analysing more of the video. This trades speed for accuracy.But leaving those aside, I am always interested in finding results from other people's tests. Thank you for the offer; it would be nice if you could tell me what you think it is vs. what DGIndex says vs. what my algorithm says. Also, if your sample is interesting, it would be nice if we could mediate a way of sending it to me.

Thanks for your support,

berrinam


Originally Posted by berrinamIf we STILL have combing, then you add a deinterlacer specialising in line-based interpolation (tdeint+eedi2) to basically postprocess the field-matching.

Yes, precisely, though tfm's pp alone is good enough for quick work for many.

I then use TDecimate in two passes (modes 4 amp; 5) to analyse the hybrid nature and return a continuous non-jerky stream + timecode file. It's a habit I got into from summer and autumn, when I worked on a lot of insane 24p telecine/30p/60i mixed material. (Might make interesting test cases for your filter, if I can make rips of them again.) Even if it's pure film or video, it won't hurt, though I add an override in that case to be certain.

I have my own templates, so it's pretty quick.