repair bad deinterlacing

[hrgiger6]

every so often I come across an encode that has been deinterlaced with the wrong field order into a progressive file. I have heard that the fields can be recovered and the file repaired, can someone do this? what plugins and script would do the job here? (if it can be done at all.) before I started using avisynth I would have said it was impossible to fix, but now I am not so sure.



here is the whole 4 min. file recorded from a south american tv broadcast in 83, and unfortunately this is by far the best source of this available anywhere. should be a quick dl just click the very top link where it says "Download: bad deinterlacing.rar."

http://speedy.sh/NNf5B/bad-deinterlacing.rar

[Evil_Burrito]

If you want to take the time it is definitely possible to improve the video, but in my opinion I don't think it is possible to completely "fix" it. Because your source has problems on top of problems. For many of the problems you could use mvtools2. Read the documentation (thoroughly if it is your first time) and at the end there are some examples scripts that could be of help.
Like
To recreate bad frames by interpolation with MFlowInter:

super = MSuper()
backward_vectors = MAnalyse(super, isb = true, delta=2)
forward_vectors = MAnalyse(super, isb = false, delta=2)
inter = MFlowInter(super, backward_vectors, forward_vectors, time=50, ml=70)
# Assume bad frames are 50 and 60
trim(0,49) ++ inter.trim(49,-1) \
 ++ trim(51,59) ++ inter.trim(59,-1) ++ trim(61,0)

I did some quick work so you can see some possible results. The pictures are attached (note these were done at 3 am and I am tired).

[Evil_Burrito]

I wanted to point out that the worst issue (in my opinion) is the poor vhs capturing. It has lots of scenes that are completely missing frames/fields (plus jitter and vcr lines). Which are not necessarily due to bad deinterlacing. Yes, it looks similar to interlace artifacts (combing), but I don't think they are, because the lines are too thick. Although anything is possible, it could have been badly de-interlaced by hardware before it was even captured. I can't know unless I had more details about the source and the methods used.

You should check out these links to learn more from people who are more experienced than me.
http://forum.videohelp.com/threads/3...toring-old-VHS
http://www.digitalfaq.com/forum/vide...time-base.html

[ChiDragon]

Originally Posted by Evil_Burrito

Which are not necessarily due to bad deinterlacing. Yes, it looks similar to interlace artifacts (combing), but I don't think they are, because the lines are too thick.

Artifacts like this are caused by taking an interlaced source and resizing down with a scaler that expects progressive input.

[johnmeyer]

I think ChiDragon is correct about the cause. I was certain that Didée posted a script, back around 2009-2010, that was able to make an improvement on this sort of video, but after 30 minutes of searching, I can no longer find the post. If he is lurking, maybe he can reinvent his solution.

I thought I had archived it in my local script repository, but I can't find it here either. That's a bummer, because clients sometimes send me video that looks like this, and I am expected to fix it.

[2Bdecided]

Are you thinking of this?
http://forum.doom9.org/showthread.php?t=162599
Maybe not, because that was resized telecine, and the solution Didée posted was half a joke.

I don't remember a "proper" fix for this kind of thing, and I've been looking for a long time!

Even the kind of improvement that you assume might be possible hasn't been achieved yet AFAICT.

Cheers,
David.

[Evil_Burrito]

Thanks ChiDragon for the knowledge. You think it was resized while interlaced? I will keep it in my brain backup vault if by unlucky chance I see video like this again.

hrgiger6, have you made any progress? Or did you just want the forum to do all the work for you

[johnmeyer]

Originally Posted by 2Bdecided

Are you thinking of this?
http://forum.doom9.org/showthread.php?t=162599
Maybe not, because that was resized telecine, and the solution Didée posted was half a joke.

That was actually a response to a thread I started, and Didée's code was no joke: it worked perfectly. Also, the problems I was facing in that thread were not from improper re-sizing.

The thread I was thinking of -- and which I think may have been removed for some reason -- concerned exactly the problem shown in the OP's picture, and which happens when you re-size interlaced video without first de-interlacing. I remember the thread well because I posted a "solution" that I had used when helping a collector restore the entire 57-episode Johnny Cash show. My idea did make the video look better, but when I posted my code, Didée and other pointed out that it was the wrong fix because I didn't correctly identify the problem.

I then remember -- perhaps incorrectly -- that Didée posted some code that did a much better job of undoing the mess.

But since I can't find the post, my ancient memory cells are probably playing tricks on me.

[johnmeyer]

Ah ... when I wrote "Johnny Cash" in the last post, I realized I could use that to find the old post. I found it right away, and I now realize why it was so hard to find: it is in the middle of the huge QTGMC thread.

Here is a link to the point in that long thread where Sadie posted a clip (the link is now dead) that showed problems similar to what is shown in the single frame in the OP's post:

Bad Interlace Resizing

Several posts later, Didée provides a great example, using AVISynth code, of how that video got corrupted. Many posts after that, I posted my "solution" to help fix the problem:

Suggested "fix"

In the next post following mine, Didée immediately corrects my wrong thinking as to what caused the problem, but then states:

Your solution is good - since it's close to impossible to (sufficiently) revert the interlace-damage, keeping just one field & discarding the other is the next best thing you can only do. But the problem analysis definitely needed to be corrected.

So, I guess the OP could try the code I posted in that old thread. It might help a little. It did help with the video I was dealing with, but as others pointed out in that old thread, the video will never look great, and a lot of resolution will be lost.

BTW, if you keep reading the thread, you'll see the remains of an unfortunate exchange between Didée and me. It resulted from a misunderstanding when we were both posting at the exact same moment, and one of us went back and edited a post after the other had already read the original version. We ended up responding to things that were no longer there. When we realize what had happened, we kissed and made up ...

I have complete and total respect for Didée.

[hrgiger6]

Originally Posted by Evil_Burrito

hrgiger6, have you made any progress? Or did you just want the forum to do all the work for you

sorry, I am absolutely still working on it and I will post some results in a minute.
thanks EB for taking the time to help me on this, and everyone else here as well.

[hrgiger6]

well, I can't seem to see any difference using any of the scripts suggested. can anyone else?

the only way I see that this could be sort of repaired is to be able to define each field by its actual lines of resolution (e.g. 1-10, 21-30... for upper 11-20, 31-40... for lower), separate the fields and then interpolate the missing lines for each field back in creating progressive frames, resize, and re-interlace properly.

can this be done?

[johnmeyer]

I had a few minutes this morning and looked carefully at the clip, field-by-field, rather than frame-by-frame. It is very useful to look at the fields during the momentary flashes caused by the dramatic stage lighting. What happens is that you end up with portions of the previous field, as seen here:



The dark stripes are from the previous even field, before the flash happened.

Looking at this, it might be possible to take each even field and split it spatially into horizontal stripes. Then you could combine half the stripes from the current even field, and the complementary half of the stripes from the previous even field, and you might then have something that looks better. You'd then do the same thing with the odd fields, and then re-weave to get them back together as a frame.

I think something like this may have already been done. My starting point would be to use some of StanlessS' code.

[johnmeyer]

P.S. I think your best bet is to try to get a better copy of that 1983 Kiss "Creatures of the Night" concert in Rio. There are dozens of versions on YouTube and elsewhere, none of which seem to have this problem. You could just watch those and be done with it.

Also, unless you are absolutely in love with that particular concert, you can find dozens and dozens of clips from the rest of that tour, and create your own concert. Based on a quick, casual, perusal of clips, they used the same stage set and costumes throughout.

[hrgiger6]

Originally Posted by johnmeyer

I had a few minutes this morning and looked carefully at the clip, field-by-field, rather than frame-by-frame. It is very useful to look at the fields during the momentary flashes caused by the dramatic stage lighting. What happens is that you end up with portions of the previous field, as seen here:



The dark stripes are from the previous even field, before the flash happened.

Looking at this, it might be possible to take each even field and split it spatially into horizontal stripes. Then you could combine half the stripes from the current even field, and the complementary half of the stripes from the previous even field, and you might then have something that looks better. You'd then do the same thing with the odd fields, and then re-weave to get them back together as a frame.

I think something like this may have already been done. My starting point would be to use some of StanlessS' code.

right, exactly. I did this already with PS and is what I alluded to previously when I said could we define each field as being lines 1-10,21-30,41-50 etc. as being the upper field for example. if we could get this divided into fields properly, surely we could use some sort of smart deinterlacing on steroids that would treat the huge bars jutting out similar to the 'combing' on typical interlaced footage.

Originally Posted by johnmeyer

P.S. I think your best bet is to try to get a better copy of that 1983 Kiss "Creatures of the Night" concert in Rio. There are dozens of versions on YouTube and elsewhere, none of which seem to have this problem. You could just watch those and be done with it.

Also, unless you are absolutely in love with that particular concert, you can find dozens and dozens of clips from the rest of that tour, and create your own concert. Based on a quick, casual, perusal of clips, they used the same stage set and costumes throughout.

I have several very nice copies like the ones you speak of, but they are incomplete and definitely do not include the song in this clip 'God of Thunder.' there are at least 2 seemingly complete concerts on youtube but if you look at this clip http://www.youtube.com/watch?v=OMW8tGzeEA8@ 41:15 you can see why I am interested in this short clip, despite its major flaws. I have not been able to find a better quality copy of the complete concert, only the same edited show that everyone else has, in multiple versions.

only other source of footage from full concert


the clip I posted above with the discussed problems

I have tons of Kiss shows so that's not the problem, this is exceedingly rare footage in almost unspeakable quality except for those spots that cause all the trouble. if I can find a decent tranfer of that complete show, I'll just rotoscope those bars away using the other footage in the trouble spots of the affected frames. I don't think I will find the rare footage in a usable quality and the youtube quality is too poor to even consider.
if somehow avisynth could treat those huge bars in motion scenes as just huge interlacing artifacts maybe it could blend them somewhat? but I guess it can't do that because there are no fields that correspond to the bars anymore. I guess I can just redo each frame that has the bars by hand in PS, I was hoping to avoid that though.
btw this concert really is that special, featuring Vinnie Vincent on lead guitar and 3rd to the last concert with make-up (before re-uniting in the 90's) in front of 137,000 fans.

[johnmeyer]

OK, I wrote some "proof of concept" code. It is so crude that I hesitate to post it. However, it shows the basic three steps of the idea:

1. Create a clip for each even band, and a clip for each odd band.

2. When creating the odd bands, use a motion estimated clip that is halfway between the current band and the previous band.

3. Reassemble the odd and even clips.

Here is a clip of comparing the original (the top part of the stackhorizontal image) with the clip that results from what I describe above:



If you look at the portion of the two clips pointed to by the red arrows, the mic stand is now straight.

My approach is proof of concept only. Besides being a brute force approach (there must be a more compact, elegant way to code this), there are two major issues that must be solved:

1. The edges of the horizontal bands do not mesh smoothly. I either need to do a better job figuring out the exact scan line to use for each band, or I need to figure out how to recombine them with a little blur on the edges. That is beyond what I could figure out to do in the short time I spent on this.

2. The original clip should probably be used at scene changes, because this code actually introduces bands at each scene change, rather than removing them.

Here is the code (please keep your giggling to yourself):

source = AVISource("E:\fs.avi").KillAudio()
prev = selectevery(source,1,-1)

super=MSuper(prev,pel=2)
vfe=manalyse(super,truemotion=true,isb=false,delta=1)
vbe=manalyse(super,truemotion=true,isb=true,delta=1)
prev_est = mflowinter(prev,super,vbe,vfe,time=50)

clip1  = crop(source,0,0,480,9)
clip2  = crop(prev_est,0,9,480,18)
clip3  = crop(source,0,27,480,18)
clip4  = crop(prev_est,0,45,480,18)
clip5  = crop(source,0,63,480,18)
clip6  = crop(prev_est,0,81,480,18)
clip7  = crop(source,0,99,480,18)
clip8  = crop(prev_est,0,117,480,18)
clip9  = crop(source,0,135,480,18)
clip10 = crop(prev_est,0,153,480,18)
clip11 = crop(source,0,171,480,18)
clip12 = crop(prev_est,0,189,480,18)
clip13 = crop(source,0,207,480,18)
clip14 = crop(prev_est,0,225,480,18)
clip15 = crop(source,0,243,480,18)
clip16 = crop(prev_est,0,261,480,18)
clip17 = crop(source,0,279,480,18)
clip18 = crop(prev_est,0,297,480,18)
clip19 = crop(source,0,315,480,18)
clip20 = crop(prev_est,0,333,480,18)

test  = BlankClip(length=FrameCount(source), width=480, height=360, fps=29.97, color=$000000).converttoyuy2()
test1 = overlay(test ,clip1,0,0)
test1 = overlay(test1,clip2,0,9)
test1 = overlay(test1,clip3,0,27)
test1 = overlay(test1,clip4,0,45)
test1 = overlay(test1,clip5,0,63)
test1 = overlay(test1,clip6,0,81)
test1 = overlay(test1,clip7,0,99)
test1 = overlay(test1,clip8,0,117)
test1 = overlay(test1,clip9,0,135)
test1 = overlay(test1,clip10,0,153)
test1 = overlay(test1,clip11,0,171)
test1 = overlay(test1,clip12,0,189)
test1 = overlay(test1,clip13,0,207)
test1 = overlay(test1,clip14,0,225)
test1 = overlay(test1,clip15,0,243)
test1 = overlay(test1,clip16,0,261)
test1 = overlay(test1,clip17,0,279)
test1 = overlay(test1,clip18,0,297)
test1 = overlay(test1,clip19,0,315)
test1 = overlay(test1,clip20,0,333)

stackvertical(source,test1)

#return test1

Hopefully someone else (or the OP) can figure out how to solve these two problems. With a little help, I think this approach can solve the problems with this particular clip.

[hrgiger6]

WOW now we are really getting somewhere. last night I divided the video into fields using a mask I made in PS with bars 18 pxls tall to just black the other field out or turn it red for delogo (abysmal.) I just had no idea how to proceed. what you have done looks like possibly we could put another mask over the fine stripes and use a delogo (I haven't done anything like that with avisynth myself) or something to interpolate those fine glitches. of course you or someone else will have a better idea but it is definitely doable.
I really appreciate your hard work on this.

as one of the other posters said, this really is a problem that shows up fairly frequently, if we can figure out how to deal with this it will be a major accomplishment.

[hrgiger6]

I ran your script and it works amazingly well except in very fast motion areas. I made a repair mask for delogo which has 3 px red lines centered every 18 px. it was able to somewhat interpolate those areas with the very visible horizontal lines giving an improved appearance. however I am certain that avisynth would do a far better job but I am unfamiliar as to what script/plugins would be best to use.

test comparison of original file, your script and script w/ delogo applied

[johnmeyer]

Hmmm ... yes, my approach breaks down with vertical motion. Works very well with horizontal motion (as you show in the first of the two frames of the singer).

I don't know if there is a solution ...

[StainlessS]

Be aware if anyone tries AMSS0815's AvsInpaint via Reuf Toc's InPaintFunc.avs, it will be broken now under v2.6, due to a bug fix in
Levels(RGB), where Reuf Toc relied on the bug to create some kind of mask.
http://forum.doom9.org/showthread.ph...55#post1479855

[johnmeyer]

OK, this is an idea for how to make an improvement on my original attempt.

I think the idea of using motion estimation is still useful, but my original code (in my earlier post) applies the motion estimation to the entire clip. This doesn't work when there is vertical motion because the bands are affected differently when they move up or down into the area previously occupied by bands from another part of the image.

Therefore, a possible better solution would be to first create two clips using the "macro fields" that were created by the improper resizing. Macro fields?? OK, to define my made-up term, "macro fields" refers to the alternating 18-line horizontal blocks of pixels. The idea would be to do something similar to a "separatefields", but do this instead on each group of 18 horizontal lines. Then, assemble the odd horizontal groups of 18 lines into one "field" and the even blocks into a second "field." The motion estimation would then be applied to just the odd fields. Finally, the odd and even "fields" would be "weaved" back together, but in 18-line chunks.

This is similar to:

separatefields()
even = selecteven()
odd  = selectodd()
super=MSuper(even,pel=2)
vfe=manalyse(super,truemotion=true,isb=false,delta=1)
vbe=manalyse(super,truemotion=true,isb=true,delta=1)
neweven = mflowinter(even,super,vbe,vfe,time=50)
interleave(neweven,odd)
weave()

except that the separate, select, interleave, and weave statements would work on groups of 18 lines instead of one line at a time.

I think -- but am not sure -- that doing it this way would let the motion estimation work its magic in both the x and y directions without being confused by the moving, hard discontinuities every 18 pixels.

I'm not quite sure how to code this ...