Looking for detection

[actionman133]

Hi all,

I'm currently working on a script that will restore films to the full frames from the ones that are blended on NTSC VCD's. AFAIK, there is no dedicated filter for this, and I felt like challenging myself too.

The script works with the principle that for every 4 film frames (alphabetically), they are distributed across 5 film frames (numerically) like so:

VCD frame 1 2 3 4 5
Film frame aa bb bc cd dd

Frame 3 is a 50:50 blend of frames b and c. So we get frame 2 (which is wholely frame b), 'reduce it' by 50% (with levels), and subtract it from frame 3. This leaves us with a 50% frame c. Repeat the process with frame 4, to get another 50% frame c. Blend those two versions of frame c together and you get the restored frame c. Frames a, b and d pass through unchanged.

While the script that I have developed works very well on my perfect test footage, I am aware that the blending order does change in many VCD's, usually on cuts to different angles.

Here is my code at the moment. Feel free to post possible improvements. Right now, I am concerned with technical quality; cleaning the video can be done with other filters.


Function NTSC_VCD_DeBlend (clip Last) {

First = SelectEvery (5, 0)
Second = SelectEvery (5, 1) # Get the full frames to pass through
Fourth = SelectEvery (5, 4)

Third1 = Subtract (SelectEvery (5, 2), Second.Levels (0, 1, 255, 128, 255)).Levels (0, 1, 127, 0, 255)
Third2 = Subtract (SelectEvery (5, 3), Fourth.Levels (0, 1, 255, 128, 255)).Levels (0, 1, 127, 0, 255)
Third = Overlay (Third1, Third2, mode = "blend", opacity = 0.5) # Extract the third frame from both blends, then combine.

Interleave (First, Second, Third, Fourth) # Re-integrate the restore frame with the orignal frames
}


What I am looking for is something to help detect where the blended frames are, since right now it just assumes the 3rd and 4th frames are blended.

I think I remember once upon a time about a filter that does detect blended frames and makes the frame numbers available, but I can't remember what it is and I don't remember where I looked.

Can anyone help?

[scharfis_brain]

please look at this:

http://forum.doom9.org/showthread.php?s=&threadid=75869&highlight=blended+telecined

[actionman133]

Thanks for the link Scharfis. I still pursued creating this Deblender, even though it's already been done, and I've decided to take a different approach. I honestly don't know how the other one was done other than by reading it. My version is obviously much shorter (whether or not it's better, I can't tell).

This filter offers strength detection. Values range from 0-255. The higher the value the more likely it is to consider a frame to be blended. Values between 50 (for good material) and 70 (for noisier video) seem to be optimal.

A debug option is also there to help find the value for the Strength. It doesn't deblend, but it does tell you which frames it believes are blended and the necessary value to enter to deblend them.

The first part is very similar. Where mine differs is that the first ConditionalFilter replaces the first blended frame with the restored frame. Then to remove the second blended frame it compares the new video (with one restored frame) to the old video (with no retored frames). When it detects a restored frame - since it's the only change - it replaces the following frame with the restored frame.

And then, like the other guy's deblender, Decimate removes the duplicates.

I wouldn't mind someone trying this out to see how these two shape up. I've only done this under test conditions and I'm curious to see if this can work in 'real world' scenarios.

Thanks again!


Function DeBlend (clip Last, float "Strength", bool "Debug") {

Strength = Default (Strength, 50)
Debug = Default (Debug, False)
Finished = Last

Original = Loop.Trim (0, 3) + Last

First = Loop.Trim (0, 5) + Last
Second = Trim (First, 1, 0)
Third = Trim (First, 2, 0)
Fourth = Trim (First, 3, 0)

Third1 = Subtract (Third, Second.Levels (0, 1, 255, 128, 255))
Third2 = Subtract (Third, Fourth.Levels (0, 1, 255, 128, 255))
ThirdF = Layer (Third1.Levels (0, 1, 127, 0, 255), Third2.Levels (0, 1, 127, 0, 255).Trim (1, 0), op = "fast", use_chroma = true).ConvertToYV12
ThirdTest = Subtract (Third2.Trim (1, 0), Third1).ConvertToYV12

First1 = First.Trim (2, 0).ConvertToYV12

Once = ConditionalFilter (ThirdTest, ThirdF, First1, "YPlaneMinMaxDifference", "<", String (Strength))

Diff = Subtract (Original.ConvertToYV12, Once)
Diff = Diff.Trim (1, -1) + Diff

Finished = ConditionalFilter (Diff, Once.Trim (1, -1) + Once, Once, "YPlaneMinMaxDifference", ">", "0")
Finished = Finished.Trim (4, 0)

Debugging = ConditionalFilter (ThirdTest, First1, First1, "YPlaneMinMaxDifference", "<", String (Strength), True)

(Debug == True) ? StackVertical (StackHorizontal (Debugging, ThirdTest), StackHorizontal (First1, ThirdF)) : Finished

}

[scharfis_brain]

the other guy's deblender

Haha.
Please watch the thread more precisely, WHO was the creator of the deblender... :D

It seems you only compare once per cycle.
the 'other guy's' deblender does this with all frames of one cycle to increase stability.
also this deblender doesn't need a threshold due to the given comparision.

but make your tests do judge, which one has the better detection.

[actionman133]

Sorry Scharfis, I have the terrible habit of reading the posts but not the names or avatars. I hope you didnt take any offense, although judging by your response, you didnt seem to.


It seems you only compare once per cycle.
YOUR ;) deblender does this with all frames of one cycle to increase stability.


I thought mine did compare with all frames in the cycle with ThirdTest. Unless you're meaning something else and i'm not quite catching. Like I said earlier, I couldn't understand what was happening with the FrameEvaluates, so I'm not quite sure how your deblending works on a 'per-line' basis.

I have been trying to test these filters, but I only have one NTSC VCD, and both Deblenders work equally well. One thing that I have noticed with mine is that using DirectShowSource to input the MPEG, is that seeking is EXTREMELY slow. I know that's because seeking with DirectShow is inherently slow, however with the simple version in my first post, I had no such problem. I can't find any instance when I am referring to previous frames (which would explain constant seeking), so do you have any idea why it's suddenly slowing down? My computer is quite robust for the task (I can apply several complex filters to DVD footage in realtime in WMP)

btw, thanks for continuing to offer a hand after that little 'mishap'... it won't happen again :cool: