ExBlend; similar to DOCI?

[jmac698]

StainlessS,
I noticed your ExBlend sounds very similar to my DOCI. I noticed that my two interlaced frames had the chroma only blended. This is similar to the blend pattern as you describe. My luma is perfect however, so I wouldn't call it a true blend. If your luma is blended as well, then we have different filters.
I thought my problem stemmed from my capture card recording in YV12 which blends chroma in pairs of lines. Your problem may be from some type of pulldown.
Anyhow, take a look at my filter. And if they're the same, I just wasted a day :)
Otherwise, if you wanted to add my algorithm, it would be even better!
It's possible to automatically detect which problem it is. My problem should have numerically exact chroma in pairs of lines. Note that I get the problem even on "YUY2" files; not sure how that happened, I used Huffyuv, maybe some hidden RGB->YUY2 conversion happened so I lost the fact that I could only record in YV12.

Capturing and Editing Video > Avisynth Development > New filter; Destruction of Chroma Interlacing

[StainlessS]

Hi Jmac698

Think I made a big mistake there in the description for ExBlend().
Now believe that what ExBlend fixes is 3:2 pulldown that has been blend
deinterlaced and then vertically downsized to half height. The results
are indistinguishable from perfectly blended frames as described for
ExBlend(). ExBlend will not touch 3:2 pulldown blend deinterlaced
that has NOT been downsized.
I had a clip that someone wanted cleaned up, I mistakenly assumed that
it used the ExBlend() description of blended frames and knocked up a script
to fix that problem. I then found that the clip kept going out of sequence
and needed some kind of detector. I was not at the time a regular visitor
to Doom9, and only ever sought filters etc from WarpEnterprises. Not finding
a filter to fix the problem, I eventually dug out a compiler and ExBlend is
the result. This was my first coding (not counting a little bit of VB) in about 14
or 15 years, but it does exactly what I wanted from it and even surpassed my
expectations. I later found a script in the old downloadable Avisynth site
that turned out to be almost identical to the script I had done. Searching
the site I found a link to that particular script that had the name of the author
in it, it was ActionMan133. In Actionman133's writeup, he also made the blended
frames assumption that I had done and so this reinforced my theory as to the cause.
Have recently seen a thread on-site where he obviously re-assessed and came to
the 3:2 blend deinterlaced, resize, opinion. I dont really have much NTSC footage
myself (thank goodness) and have not really had that many samples to try ExBlend
on but those that I have had, ExBlend performed brilliantly. I think that for non
downsized stuff, the only way to go is probably srestore script, srestore (I think)
detects using AverageLuma whereas the ExBlend filter actually does a sort of test
deblend to detect. This allows srestore to detect the 'almost blends' produced by blend
deinterlacing but requires a certain amount of clean up of the produced frames.
As Exblend detects what looks like perfectly blended frames, the results do not
really require and extra clean up and in many cases the resulting deblended frames
look cleaner than those on either side. I have been toying with the idea (but not
tried it out yet) that vertically downsizing by half, a 3:2 pulldown clip with
blend deinterlacing, only for the detection in ExBlend mode=1, and then doing
the second pass (mode=2) at full size, this would though not produce clean output
as they were not true blended frames, perhaps I could do some kind of cleaning,
I think that it could potentially be faster than srestore but of course the cleaning
would add extra cost in time.
ExBlend(), detects only on luma but deblends both luma and chroma. I did at one point
have it detect on both luma and chroma, I even tried detect purely on chroma, it worked
just fine on perfect, uncompressed clips but was rubbish if compressed.
We do have different filters, I shall have a closer look at your problem, and I like that you
made a simulator clip, that is definitely the way I like to work, get it working on perfect
clip first and then start worrying about compression artefacts etc.
I personally use HuffYUV, v2.1.1 Multi-Threading Patch v1.0 Including CCESP Patch, and
configured (for progressive) "Convert to YUY2", "Predict Left (fastest)",
"Field Threshold=800" or thereabouts and use "Fast Recompress" in VirtualDubMod.
Dont hold your breath but I will try and do an Exblend Mod, do you speak C++ ?, if so then
would supply you modded source, would not want to incorporate into ExBlend, also
dont know how prevalent your problem is.
Also, could you just post about 30-40 MB sample for me to play with.
Again, dont hold your breath. :)

[jmac698]

S, thanks for reply. I like your thinking, the scientific approach is model the problem, invent the algorthm, and refine. A good theoretical basis is very powerful and leads you more than halfway to practical performance.
Really though I wonder how it's like in PAL-land, you still have a lot of interlacing problems? I thought NTSC would be the worst.
I have a blend really but just on chroma; however the same idea could fix luma+chroma blends. I have a 50% blend so I just subtract from one good field to get the other. Mine should work on vertically resized material as well.
I'm not so good at C++, but I think your source would be an inspiration to me, to write filters better. I only compiled sample3 from SDK so far and made filter that uses two clips. Let's continue this under Development.
And I just compared all lossless codecs for realtime operation, FFV1 or UTVideo were best for me. See Capture.