Kinescope restoration back to 60i

[johnmeyer]

I have searched all these forums to see if anyone has attempted Kinescope restoration similar to what this company is doing:

http://www.kinescopes.com/LF_4.html

I have many Kinescope captures which I would like to look more like real video (which is what is done by the company linked to above). I think I know most of what I have to do, and I have done most of the following steps in other projects, but I need help in two ways.

First, am I missing a step that you think would make the result look more like video?

More important, has anyone come up with better ideas for 24p to 60i than what is described in this thread:

http://forum.doom9.org/showthread.php?t=124577&highlight=24p+60i

Here is my proposed restoration on which I would appreciate comments:

1. Do IVTC to recover the film frames from the 29.97 video. This is easy to do, and I have already tested and it works on Kinescope just like it does with any telecined film. This gets me the 24p film, just as if I had transferred the Kinescope film on a Rank Cintel.

2. Remove film dust and dirt. I spent hours and hours during work on another project perfecting a Despot script, and finally got Despot to work really well. There are some really great hints scattered around this forum that had to be combined together.

3. Do gamma adjustment to try to moderate some of the horrendous contrast that is typical of the Kinescope process. Again, I can do this in Vegas or in AVISynth. Not too hard.

4. Restore the sound. I do this for a living and there are lots of tricks to add "life" to muddy sound. Nero Wave Editor actually has a neat plugin for this.

5. OK, this is the tough one. I need to take the 24p, convert that to interlaced, and then synthesize the fields that were dropped during the Kinescope capture. MVTools is my choice for this (actually one of the MVFlowFps functions), but in my quick tests, I am not happy with the results.

So, if anyone has some hints or suggestions on #5 -- or on the overall process -- that would be much appreciated.

BTW, if you look at the results of the LiveFeed technology in the link I provided above, it is darned impressive stuff. I think I should be able to duplicate it almost exactly if I can get #5 working correctly.

Thanks!

[mikeytown2]

Looked at the comparison vids from kinescopes... nothing that special just a denoiser as far as i can tell.
http://img209.imageshack.us/img209/3338/48075121ff3.th.jpg (http://img209.imageshack.us/my.php?image=48075121ff3.jpg)

a=FFmpegSource("Philofarnsworth-WML15thAnniversaryFebruary1965Kinescope676.avi").Subtitle("Orginal")
b=FFmpegSource("Philofarnsworth-WML15thAnniversaryFebruary1965LiveFeedRestoration136.avi").Subtitle("Restoration").Trim(3,0)
StackHorizontal(a,b)
ShowFrameNumber(x=8,y=50)


FFMpegSource() (http://forum.doom9.org/showthread.php?t=127037)

The 2 Avi's are both 29.970 FPS and they used Vdub to create them.
http://mediainfo.sourceforge.net/

Explain what you mean by "Real Video". Also what is your source and target resolution? I've played around with High Motion video (me wakeboarding shot from a boat) trying to get 120p out of 30i and it doesn't work at all. It really depends on the video content, if there is not a lot of movement in the frame then your chances are much better. Post a sample and we can give you better advice. As of right now there is no magic button you can press to get nice looking 60i from 24p for every type of content out there. It doesn't mean we can't try with a sample though...

[2Bdecided]

I think the comparison videos on the website are wrong - they compare 24p with 30p, whereas the real output is 60i - so those video hide the real advantage.

My vague understanding of the kinescope process is that the fields aren't dropped - that's the real problem - they're all merged together in there. I could be wrong - I'm in the UK and the process here is quite different (50i>25p, simpler than 60i>24p).

_if_ the fields were simply missing, you could use mvtools to reconstruct the missing moments in time. The only problems would be the usual problems with mvtools, and probably the implied variable frame rate of the source.

However, given that nothing is missing, but it's all merged together, it's far more complicated.

In the UK, the Vidfire process works well for our archive stuff - we call them telerecordings. You can read about it on the Doctor Who Restoration website.

http://en.wikipedia.org/wiki/VidFIRE

Cheers,
David.

[scharfis_brain]

this might also be interesting:

colour restoration out af a black&white telerecroding (kinescope)

http://www.techmind.org/colrec/

[johnmeyer]

nothing that special just a denoiser as far as i can tell.No, they definitely do quite a bit of temporal magic, although you are correct about the denoiser (and film dust removal). See further below about why the improvements aren't quite as evident if you play these clips on your PC.

Explain what you mean by "Real Video". Also what is your source and target resolution? Good questions, especially given how many video standards we have to deal with. I am trying to create 720x480 SD 29.97 interlaced video, commonly referred to as NTSC video. The source of my footage are hockey games from the 1950s and 1960s, captured via a pass-through on my DV camcorder from the composite video feed from my satellite. It is captured at 720x480 29.97 interlaced (i.e., standard SD DV). See next comment for more about what I'm doing so far.

they compare 24p with 30p, whereas the real output is 60i True. You have to put the clips on a DVD and view them on a standard NTSC monitor (29.97 interlaced) to see the rather stunning difference.


In the UK, the Vidfire process works well for our archive stuffYes, I should have provided a reference or link to that as well. It actually precedes in time the technology I referenced, and is apparently more advanced.

If you research the kinescope process or if you capture and view individual fields of a kinescope (just do a separatefields() function and view the result), you will see that it is just standard film and you can recover the film using a standard IVTC process. However, it gets difficult after that. Without going into everything that I've found in my research, the short story is that Kinescope film cameras were pointed at a high quality television monitor and then filmed the result. The camera motors/shutters were electronically synced with the video VBI. In the best of these systems, two fields would be recorded on one frame of film and, through some sort of technique, the next field would either be stored (via persistent phosphors or some other means -- no digital storage back then) while the film pulled down, or it would be discarded. The discarding was needed in order to record 30 frames a second on a medium which only recorded 24 frames.

As I've looked at this problem, it may be way beyond what can be done with AVISynth because there are quite a few really tough problems.

Neglecting the fact that not all Kinescopes were done the same way, and assuming for the moment they were created as described above, I thought at first I could simply do the IVTC, separate the fields, run MVFlowFPS to create the fields that were dropped, weave the fields back together and have a super result. The problem, however, is that film jumps around, both in the gate of the camera, and then again when it is projected. Thus, the fields that were recorded on the film don't line up consistently from frame to frame. I can use Deshaker to completely eliminate this gate weave, but while that makes the film look stable, since I have no way of knowing what part of the gate weave/jitter happened in the camera and what part came from the projector, the fields still aren't going to appear in the same place.

It is this problem alone that I think dooms my project. The two companies that are doing this have access to the actual film, and therefore have control over the projection/capture process and therefore with the proper, controlled capture can know for certain that the jitter comes from the original camera and therefore have a chance at aligning fields from adjacent frames of film.

So, in the time I've thought about this from my original post, I am rapidly coming to the conclusion that this simply cannot be done without access to the original Kinescope film.

Thanks for all the comments. It helped me work through this relatively quickly and saved me wasting a lot of time.

[mikeytown2]

eh don't give up that easily, post a 30 sec clip. You never know...?

[johnmeyer]

eh don't give up that easily, post a 30 sec clip. You never know...?Thanks!

Here's a few seconds of the clip, as captured, encoded as a DV NTSC 720x480 AVI file.

If you run it through this simple AVISynth script:

AVISource("E:\Kinescope test.avi").assumebff()
separatefields()

This gives you each field from the capture. You will immediately see a standard 2:3 (two fields, then three fields) telecined film cadence. You will see some ghosting in some of the very fast moving fields. This is clearly due to a limitation in how the material was captured. Ignore that for the moment.

The general idea to get a normal NTSC 29.97 interlaced video "feel" from what was originally a video signal, is to replace that third repeated field with a synthesized field, and then re-weave the result. As I said in my original post, there are other things that need to be done as well, but this is the heart and soul of what would need to be done.

BTW, in researching this, I found some unbelievable technology that was being used to re-insert color with nothing but B&W kinescope film (of a color TV broadcast) as the starting point. No, it wasn't Ted Turner colorization, but instead, there was enough residual colorburst information at the margins (the technicians forgot to turn off the "color killer," a circuit found in most early color TV monitors so that B&W broadcasts wouldn't have color fringing). Anyway, somewhat like forensic pathologists, they were able to reconstruct the body from just these few traces. Remarkable stuff.

Here's the link (good for seven days):

https://www.yousendit.com/download/Q01HaklrdkdrUmswTVE9PQ

BTW, in looking at this particular Kinescope, I think it may have used the cheapest and easiest form of capture where they only captured half the fields. Therefore, some sort of resolution upresn'g may also provide some benefit.

[mikeytown2]

Here's my attempt... there appears to be some blended fields still so it's not perfect though...


AVISource("Kinescope test.avi")
#Get Film Frames
AssumeBFF()
Telecide(guide=1,blend=true,back=2)
Decimate(cycle=5,mode=3,quality=3)

#degrain for FPS conversion Analyse
source=last
backward_vec3 = source.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=4, sharp=1, idx = 2)
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=1, idx = 2)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=1, idx = 2)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=1, idx = 2)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=1, idx = 2)
forward_vec3 = source.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=4, sharp=1, idx = 2)
source=source.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=800,idx=2)

#Do magic to get 60P 60000/1001
backward_vec = source.MVAnalyse(blksize=16, overlap=4, isb = true, pel=4, search=3, idx=1, chroma=false)
forward_vec = source.MVAnalyse(blksize=16, overlap=4, isb = false, pel=4, search=3, idx=1, chroma=false)
#use undegrained clip for final output
last.MVFlowFps(backward_vec, forward_vec, num=60000, den=1001)

#convert 60P to 30i
AssumeFrameBased()
SeparateFields()
SelectEvery(4, 0, 3)
Weave()


Frames 15-25 seem to have blended issues. I would look at these filters for more options
http://avisynth.org/mediawiki/External_filters#Fieldblending_and_Frameblending_removal

[Alex_ander]

In my understanding of the Kinescope 60 -> 24 process, some fields are inevitably dropped and in irregular way (unlike with 'telerecording' 50 -> 25). It is possible to extract the recorded field sequence, but MVTools (MVFlowFPS) will not recreate the dropped fields/frames in their initial places because it assumes that input frames belong to equidistant moments (and this can't be true after simple 60 -> 24). It will even rebuid all the INPUT frames for new moments. Some script or special motion analysis is needed to help MVTools to only recreate the dropped fields in case of irregular dropping. I often needed something like this for restoration of bad NTSC->PALs but hesitated in addressing Fizick with the problem of narrow interest (now it doesn't look so narrow).

[2Bdecided]

Thus, the fields that were recorded on the film don't line up consistently from frame to frame.They're not supposed to. The original fields are intentionally blurred vertically. Without the blurring, they would never line up exactly by accident, but having them line up approximately for even part of the frame would have caused terrible problems on a normal display (reversed movement on part of a frame due to field swapping, for example!), so they are intentionally blurred to avoid this.

In the UK, on some telerecordings, this is done during recording (using something called "spot wobble"); on others (very early ones) it was done during playback. There are transfers of skip-field telerecording (one field only was stored on the film) where you can clearly see the original lines.

On your example, you can clearly see both fields superimposed without visible lines, as if blend deinterlaced. Recovering the original fields from this is a serious challenge - maybe this is something that the software you linked to achieves?


Even if the lines are discretely visible on the original film print, and even if no attempt is made to blur them when transferring the film back to video, you can't expect those 480 lines to be recoverable when almost randomly cropped, re-sampled and re-scaled to a new, non-aligned 480 lines (as they inevitably have been). If there are original video lines discretely visible on the film print, you'll need an HD transfer to recover them.

Some people are transferring SD telerecordings in HD to recover something else...
http://colour-recovery.wikispaces.com/

see especially
http://www.rtr.myzen.co.uk/pt450pal.bmp
from
http://colour-recovery.wikispaces.com/Full+gamut+colour+recovery+(yet+more)

Some early results have been amazing...
http://www.rtr.myzen.co.uk/totp_full_gamut_601.mov
...but it doesn't work with everything yet.

Cheers,
David.

[mikeytown2]

Attempt 2... Got an idea from here
http://forum.doom9.org/showthread.php?t=104294


AVISource("Kinescope test.avi")

AssumeBFF()

filldropsI()
function filldropsI (clip c)
{
even = c.SeparateFields().SelectEven()
vfE = even.MVAnalyse(blksize=16, overlap=4, isb = false, pel=4, search=3, idx=3, chroma=false)
vbE = even.MVAnalyse(blksize=16, overlap=4, isb = true, pel=4, search=3, idx=3, chroma=false)

odd = c.SeparateFields().SelectOdd()
vfO = odd.MVAnalyse(blksize=16, overlap=4, isb = false, pel=4, search=3, idx=4, chroma=false)
vbO = odd.MVAnalyse(blksize=16, overlap=4, isb = true, pel=4, search=3, idx=4, chroma=false)


global Efilldrops_d = even.mvflowinter(vbE,vfE,time=50,idx=3)#.ScriptClip("Subtitle(String(YDifferenceFromPrevious))")
global Efilldrops_c = even
E = even.scriptclip("""YDifferenceFromPrevious()<=4? Efilldrops_d : Efilldrops_c""")

global Ofilldrops_d = odd.mvflowinter(vbE,vfE,time=50,idx=4)#.ScriptClip("Subtitle(String(YDifferenceFromPrevious))")
global Ofilldrops_c = odd
O = odd.scriptclip("""YDifferenceFromPrevious()<=4? Ofilldrops_d : Ofilldrops_c""")

Interleave(E,O)
AssumeFieldBased()
Weave()
AssumeBFF()
}


Telecide(guide=1,blend=true,back=2)
Decimate(cycle=5,mode=3,quality=3)

#degrain for FPS conversion Analyse
source=last
backward_vec3 = source.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=4, sharp=1, idx = 2)
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=1, idx = 2)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=1, idx = 2)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=1, idx = 2)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=1, idx = 2)
forward_vec3 = source.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=4, sharp=1, idx = 2)
source=source.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=800,idx=2)

#Do magic to get 60P 60000/1001
backward_vec = source.MVAnalyse(blksize=16, overlap=4, isb = true, pel=4, search=3, idx=1, chroma=false)
forward_vec = source.MVAnalyse(blksize=16, overlap=4, isb = false, pel=4, search=3, idx=1, chroma=false)
#use undegrained clip for final output
last.MVFlowFps(backward_vec, forward_vec, num=60000, den=1001)

#convert 60P to 30i
AssumeFrameBased()
SeparateFields()
SelectEvery(4, 0, 3)
Weave()



I think it's fairly good! except for the blended fields...

Play around with Telecide and Decimate

[Alex_ander]

Attempt 2... Got an idea from here
http://forum.doom9.org/showthread.php?t=104294


Thanks for the link, very important function. But only works in case the (single) drops are filled with repeated frames/fields. Looks difficult to make right frames (fields) repeated, something like ChangeFPS() will probably create dupes between wrong frames.

[johnmeyer]

I was contacted today by Kevin Segura from LiveFeed Video Imaging, the company behind the technology referenced in the kinescopes.com link I referenced in my original post.

Kevin claims that my post, this thread, and my attempt to "reverse engineer" the process he uses at LiveFeed all constitute patent infringement.

I sent Kevin a long email in which I disagreed with every part of his assertion, especially since patents do not restrict our free speech rights to discuss technology. However, I have a soft spot in my heart for entrepreneurs, and I have seen the results of his work and, as I indicated in my first post, I think those results are fantastic. Therefore, rather than get into a long discussion about patents and whether he is properly asserting his rights, or not, I instead have decided not to make any further posts in this thread, not because any of us are doing anything wrong -- because we definitely are not -- but because this is a guy trying to make it on his own in a tough business, and I don't want to do anything to make it tougher for him.

So, I wish Kevin well and hope that, perhaps, in the brief discussion we've had here that perhaps we have provided a few ideas that he can use to make his products and services better.

[2Bdecided]

Some countries have an exemption for R&D, others do not.

IANAL but AFAIK you aren't on very safe ground carrying out R&D on patented matter in the USA.

Again, IANAL but AFAIK you're fairly safe here in the UK.

This is not legal advice!

I agree that people who are trying to earn money from inventing novel and useful video processing techniques deserve encouragement.

Cheers,
David.

[mikeytown2]

fair enough... but just out of curiosity I did a quick search and came up with nothing on google patent search (http://www.google.com/patents), assuming the patent is in Kevin's name. Xvid (http://www.xvid.org/) is a classic example of code that might infringe on patents, at least according to wikipedia (http://en.wikipedia.org/wiki/Xvid#Patent_issues); discussion about Mpeg4 part 2 code implementation is still going on though. If we would have looked at a patent first and then went about reverse engineering it, i would feel dirty about doing something like that. The code i made above is somewhat trivial... simple MoComp FPS adjustment, took less then 20 min to get it running. So with that, to everyone here... good luck! I have no need for the code I made, just did it because of an interesting challenge. As for the 2 vid's from kinescopes they where of no help, as i stated above all thats there is a denoised clip; nothing was accomplished until johnmeyer posted a sample vid with the request to get 30i out of it. So this entire misunderstanding could have been avoided if johnmeyer would have posted a sample and not referenced Kevin's website... I would have come up with exactly the same code! Code for my first post came from this documentation (http://avisynth.org.ru/mvtools/mvtools.html). The second post states where i got the idea (http://forum.doom9.org/showthread.php?t=104294) from.

With that, if Kevin wishes to have my posted code removed, so be it, i will do it; but what i came up with is trivial, and i had no idea it might be patented.

I'm also a supporter of people making money!

[Joel Cairo]

Well, I'll just say "thanks" to John & mikeytown2 for understanding my position. It was indeed the specific LiveFeed references and links to my site that brought about my reaction. As John & I discussed in a PM exchange, we both recognize that I.P. rights have to be asserted in order to preserve them. So, while I have no desire to stifle general scholarly discussion, I hope you'll all understand my position.

The patent application is in process (and believe me, it's a **long** [multi-year] process), so that may be why the search didn't turn up anything.

I'm grateful that people are so interested in the work that I do, and even more grateful that they want to see it succeed. So mikeytown2, it would be my **preference** (and my polite request) that your code be taken down-- if, for no other reason, because the process that John was looking for has already been created; and also because I hate the potential hassle of having to watch for the future legions of people who'd stumble across the code with the aid of Google and decide that they didn't care about intellectual property rights (both mine, and those of the owners of the material that they might attempt to exploit...)

So thanks again to everyone for your support of a fellow forum member, and also for your time and consideration in reading this response.

All the best,

-Kevin Segura (a/k/a "Joel Cairo")
LiveFeed Video Imaging

[neuron2]

Before any code is taken down, please state the claims of your patent so we can decide if the code is violating anything. Thank you.

I assume you are not claiming a patent on the idea of motion-compensated frame/field interpolation.

[Gavino]

While I support the protection of legitimate rights, I find it shocking that anyone could consider mikeytown2's code to be violating anything at all, as he has clearly stated how he came up with it using his own brain.

Out of solidarity, I will add my contribution: there's no need to use global variables, as

global Efilldrops_d = even.mvflowinter(vbE,vfE,time=50,idx=3)
global Efilldrops_c = even
E = even.scriptclip("""YDifferenceFromPrevious()<=4? Efilldrops_d : Efilldrops_c""")
can be replaced by

E = even.ConditionalFilter(even.mvflowinter(vbE,vfE,time=50,idx=3), even, \
"YDifferenceFromPrevious()", "<=", "4")

Don't worry, mikeytown2 - I won't be seeking any royalties for this idea. :)

[avih]

I don't think any code should be taken down. The general notion of video restoration is not new, nor are motion compensated processes, cleaning filters in trillion variations, etc. A guy comes up with a simple method, implemented in a framework intended exactly for such tasks, that produce results which are [trying to be] similar to ones which are produced by other products. There's nothing illegal about that. It's not even reverse engineered, just plain black-box examination. IMHO the discussion should continue if there's still interest in it.

[neuron2]

Mr Segura sent me a PM offering excuses about why he could not tell me the claims of his patent, which appears not to exist. He knows them well enough to try to shut down the thread, but not well enough to tell us what they are!

[setarip_old]

Mr Segura sent me a PM offering excuses about why he could not tell me the claims of his patent, which appears not to exist. He knows them well enough to try to shut down the thread, but not well enough to tell us what they are!I'd view this as a failed attempt, by Mr. Segura, at "bluff poker" ;>}

If anyone has any further information regarding enhancing/restoring kinescopes, I for one, would be extremely interested...

[mikeytown2]

Because there are no patented claims, if I remove the code it might set a bad precedent... thus, I can not budge on this. The post from 2005 (http://forum.doom9.org/showthread.php?t=104294) that I referenced is trivial prior art, and my guess is it's older then his potential claims. I understand where Kevin is coming from, but I do not want to set a precedent where we have people claiming to have something patented, and yet can not produce any proof.

[avih]

@mikeytown2, agreed.

[Leak]

I'd view this as a failed attempt, by Mr. Segura, at "bluff poker" ;>}
Or rather a successful attempt at invoking the Streisand effect (http://en.wikipedia.org/wiki/Streisand_effect)...

np: Spooky - Little Bullet (Part One) (Gargantuan)

[mikeytown2]

k so I've taken another look at this... I think the "heart" of the issues revolves around Telecide (http://neuron2.net/decomb/decombnew.html) once you got the MoComped FPS stuff figured out. Added FFT3DFilter (http://avisynth.org.ru/fft3dfilter/fft3dfilter.html) to the prefiltering stages.


AVISource("Kinescope test.avi")

AssumeBFF()

filldropsI()
function filldropsI (clip c)
{
#even fields processing
even = c.SeparateFields().SelectEven()
evenPF = even.FFT3DFilter(sigma=4,bt=5)

vfE = evenPF.MVAnalyse(blksize=16, overlap=4, isb = false, pel=4, search=3, idx=3, chroma=false)
vbE = evenPF.MVAnalyse(blksize=16, overlap=4, isb = true, pel=4, search=3, idx=3, chroma=false)

E = ConditionalFilter(even, even.mvflowinter(vbE,vfE,time=50,idx=3), even, "YDifferenceFromPrevious()", "lessthan", "4.0")


#odd fields processing
odd = c.SeparateFields().SelectOdd()
oddPF = even.FFT3DFilter(sigma=4,bt=5)

vfO = oddPF.MVAnalyse(blksize=16, overlap=4, isb = false, pel=4, search=3, idx=4, chroma=false)
vbO = oddPF.MVAnalyse(blksize=16, overlap=4, isb = true, pel=4, search=3, idx=4, chroma=false)

O = ConditionalFilter(odd, odd.mvflowinter(vbE,vfE,time=50,idx=4), odd, "YDifferenceFromPrevious()", "lessthan", "4.0")


#return interlaced
Interleave(E,O)
AssumeFieldBased()
Weave()
AssumeBFF()
}


Telecide(blend=true,back=0)
Decimate(quality=3)

#degrain for FPS conversion Analyse
source=last.FFT3DFilter(sigma=2,bt=5)

backward_vec3 = source.MVAnalyse(isb = true, delta = 3, pel = 4, overlap=4, sharp=2, idx = 2)
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 4, overlap=4, sharp=2, idx = 2)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 4, overlap=4, sharp=2, idx = 2)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 4, overlap=4, sharp=2, idx = 2)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 4, overlap=4, sharp=2, idx = 2)
forward_vec3 = source.MVAnalyse(isb = false, delta = 3, pel = 4, overlap=4, sharp=2, idx = 2)
source=source.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=800,idx=2)

#Do magic to get 60P 60000/1001
backward_vec = source.MVAnalyse(blksize=16, overlap=4, isb = true, pel=4, search=3, idx=1, chroma=false)
forward_vec = source.MVAnalyse(blksize=16, overlap=4, isb = false, pel=4, search=3, idx=1, chroma=false)
#use undegrained clip for final output
last.MVFlowFps(backward_vec, forward_vec, num=60000, den=1001)

#convert 60P to 30i
AssumeFrameBased()
SeparateFields()
SelectEvery(4, 0, 3)
Weave()
bob()



Using above code on frame 118, the interpolated motion is messed up. If i change
Telecide(blend=true,back=0) to
Telecide(blend=true,back=2) then frame 118 is ok but now frame 85 has backwards motion. Any ideas?

Also Gavino I had to use "lessthan" because "<=" did not work. Thanks for the help though! Possible bug with 2.58RC3?

[Gavino]

Also Gavino I had to use "lessthan" because "<=" did not work. Thanks for the help though! Possible bug with 2.58RC3?
Aargh! Yet another unnecessary limitation of the built-in run-time filters which I wasn't aware of. :(

Using GRunT, you can write

ConditionalFilter(c1, c2, c3, "YDifferenceFromPrevious()<=4")

Let me take this opportunity to say well done for standing your ground on this issue, mikeytown2.

[Floatingshed]

This is fascinating stuff.
I'm a bit of an Avisynth novice but learning fast. I'd love to do something like this with 625/25 - 625/50 material. Would one of you chaps who clearly has a greater understanding than me please post an amended version of the script for me to play with?
Many thanks in advance,
Andy.

[johnmeyer]

I got it to work, and it works very well. However, it is a multi-step process because the 24p to 60i conversion is just one step. Also, you need to have very good stuff to start with, preferably the original kinescope film. At the very least, you need something on which you can do an inverse telecine (IVTC) to recover the original 24 fps film.

[2Bdecided]

I'd love to do something like this with 625/25 - 625/50 material.That's easier than 24p back to 60i.

Following the above script, you could just try...
#degrain for FPS conversion Analyse
source=last.FFT3DFilter(sigma=2,bt=5)

backward_vec3 = source.MVAnalyse(isb = true, delta = 3, pel = 4, overlap=4, sharp=2, idx = 2)
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 4, overlap=4, sharp=2, idx = 2)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 4, overlap=4, sharp=2, idx = 2)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 4, overlap=4, sharp=2, idx = 2)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 4, overlap=4, sharp=2, idx = 2)
forward_vec3 = source.MVAnalyse(isb = false, delta = 3, pel = 4, overlap=4, sharp=2, idx = 2)
source=source.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=800,idx=2)

#Do magic to get 50P
backward_vec = source.MVAnalyse(blksize=16, overlap=4, isb = true, pel=4, search=3, idx=1, chroma=false)
forward_vec = source.MVAnalyse(blksize=16, overlap=4, isb = false, pel=4, search=3, idx=1, chroma=false)
#use undegrained clip for final output
last.MVFlowFps(backward_vec, forward_vec, num=50, den=1)

#Re-interlace if needed:
assumetff()
separatefields()
selectevery(4,0,3)
weave()


Leave out the initial degraining to save time if you want - replace everything above "#Do magic to get 50P" with just "source=last".

Cheers,
David.

[johnmeyer]

Yes, that looks like my 24p to 60i script, with the appropriate changes made to go from 25p to 50i. I had dct=4 in both of the mvanalyze lines, but that slows things down a lot and may not improve the quality enough to be worth the extra time. You'll have to test on your clips and see.

[2Bdecided]

It's slow enough already! ;) Or if not, there's always mvflowfps2.

The "Dad's Army in Colour" shown on BBC Two Saturday evening was vidFIRE'd. Very effective, though there were a couple of places where it didn't look right, and many where the motion looked realistically smooth but more blurred than video.

Cheers,
David.

[johnmeyer]

there were a couple of places where it didn't look right, and many where the motion looked realistically smooth but more blurred than video.They probably have access to the film and also can spend a lot more time on this than a non-commercial person like me. However, I'll bet that even for them that there are lots of situations where the motion comp breaks down and they have to substitute a "safer" way (interpolation) to create the extra fields. That of course will look blurry.

[Floatingshed]

2Bdecided thanks for the script.
I'm afraid it is not sinking into my brain quite as quickly as I would like. If you can spare the time I'd appreciate a detailed description of what each section does.
Sorry to be a pain, MVtools is making my brain hurt!

[johnmeyer]

The first block of code denoises (FFT3d) and then degrains the original footage.

The next two blocks create additional frames between the existing frames in order to take your footage from 25 progressive frames per second to 50 progressive frames per second. The only "tricky" part is the separatefields() line which takes that 50 frames per second and turns it into 100 fields per second, with the first (0) field being a top field, the second field (1) a bottom field, the third field (2) a top field, and the fourth field (3) a bottom field. The SelectEvery command then takes each group of four fields and only uses the first (0) top field and the fourth (3) bottom field. It then combines (weaves) these two fields back into a frame. Since these two commands started with 100 fields per second, and then threw away the second and third field, there are only 50 fields per second left. Then, the weave command takes these 50 fields, two at a time, and combines them back into frames, so you end up with 25 frames, but unlike the original frames, these are interlaced.

So, what did all this accomplish? You now have temporal movement between the top and bottom field, whereas the original 25 fps footage had absolutely no temporal movement between fields. And, that is the definition of interlaced vs. progressive and therefore you now have footage which has twice the temporal resolution and therefore has the "television" feel as opposed to the "film" feel.

[Floatingshed]

Very nicely explained, thanks. Can't wait to get home and play. Cheers.
Andy.

[Floatingshed]

What does the "E = ConditionalFilter(even, even.mvflowinter(vbE,vfE,time=50,idx=3), even, "YDifferenceFromPrevious()", "lessthan", "4.0")" stuff do in the original script?
Thanks.

[johnmeyer]

What does the "E = ConditionalFilter(even, even.mvflowinter(vbE,vfE,time=50,idx=3), even, "YDifferenceFromPrevious()", "lessthan", "4.0")" stuff do in the original script?When I started this thread, I thought that most kinescopes were made in a manner where the film camera would actually capture a full video frame from start to finish, and than another, and then skip a frame. However, that was stupid on my part. The person responding tried to come up with an approach that would only add extra frames/fields for the frames/fields missed during 30 -> 24 decimation. The conditional script was a very clever way to only add back the fields and frames when no movement is detected, so when there isn't much difference between frames, then add an interpolated frame. Those lines were adapted from another script posted here years ago where a person was getting dropped frames, and his frame capture software merely duplicated the previous frame whenever a frame drop was detected. That script is actually amazingly useful and, since a perfect duplicate results in a YDifference of 0.00, it is easy to detect. That script then replaced the missing frame with an interpolated frame using MVanayze's motion estimation.

A little more reading and thinking about the kinescope process reveals that the conversion is much, much simpler, and fortunately this makes it much easier to do this film to video conversion. Remember that older video cameras actually scanned the image so that each line -- and in fact each part of each scan line -- is taken at a later moment in time than the line above. This is different than most of today's cameras where the entire field is exposed and then dumped from the CCD (and now CMOS) sensor, so there is actually no temporal difference between adjacent lines.

So, if you ignore for the moment the brief vertical blanking interval, you can think of the scanning of the raster lines in a normal old-fashioned CRT TV picture as a continuous process that never starts and never stops. Thus, if you are taking a film picture of the TV screen, it actually doesn't matter when you start taking the picture, as long as you stop taking the picture (i.e., close the shutter) exactly 1/29.97 second later. You will always end up with a complete frame of video. It turns out that most kinescopes appear to have been done this way. They take a frame of video, then close the shutter and advance the film. They lose some portion of the video while the film is pulled down. The kinescope film camera shutter is specially modified so that it has exactly a 72 degree angle. There is some other stuff about wobble (to make the scan lines disappear) and persistence (so both fields appear with equal intensity).

Rather than repeat all this, I described it in another forum:

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=624219

[Floatingshed]

It's beginning to click! Thanks for taking the time to explain.

[Mug Funky]

oh, this has got me interested.

i think if we have the original film available to us, maybe a telecine could be aligned just right to extract the original fields. this assumes the original filming had sufficiently good lenses and sufficiently good camera operators... and that the camera and telecine have sufficiently stable film transport. if the fields are too blurry or there's too much aberration it wouldn't work, but if it does we can line up the machine. the other option is to scan in a very high res and use some avisynth magic to lock onto the fields.

damn, i wish i had some kine footage lying around here. it doesn't come up too often unfortunately.

@ Joel Cairo:

nothing personal here... you should see what's happening in the decrypting forum. but really, we need to know what we're violating, except for simply trying to do the "gist" of what your product already does. there's already been attempts on this forum and others to accomplish the same thing, usually using "Vidfire" and Doctor Who as references. in addition i develop "in house" techniques to accomplish various things at my workplace, but wouldn't try to stop the very active and useful development in the avisynth forums here (rather i feed off it and contribute where i can :)). relax - even in a worst case scenario for you (losing a lot of business through free tools doing the same thing), you could probably get a job at snell and willcox, cintel, filmlight, digital vision, or any of the other companies making digital film manipulation tools with the knowledge you have.

[johnmeyer]

i think if we have the original film available to us, maybe a telecine could be aligned just right to extract the original fields.Originally I thought that might be possible, but I am now pretty certain that this is totally impossible for two different reasons. Either reason would make it next to impossible, but the two together pretty much guarantee that you cannot retrieve original fields.

1. The kinescope process involved one of several processes designed to eliminate the scan lines. For instance, if you Google:

"kinescope spot wobble" (http://www.google.com/search?hl=en&rls=GGLG%2CGGLG%3A2005-23%2CGGLG%3Aen&q=kinescope+spot+wobble)

you'll find various descriptions about how the video was intentionally "vibrated" in order to obscure the scan lines. This means that the fields were never exactly in the same position from moment to moment. Other techniques were used as well.

2. The other problem is the nature of film itself. As you doubtless know when film is exposed in the camera, and then again when it is projected, each frame of film never comes to rest in the film gate exactly in the same way as the previous frame. As a result, if you look at a static title at the beginning of a feature film, you will notice that it bounces and "weaves" on the screen. This "gate weave" is obviously present in a kinescope and, much like the spot wobble, means that the video fields will never be at the same place from one frame of film to the next.

Now, #2 might be possible to cure if you had access to the original film. You could use Deshaker to remove the gate weave if you could see the edge of the film (outside the gate) and stabilize on that. When Deshaker was first released, I corresponded with the author, Gunnar Thalin, and he told me he actually added a few settings for a user who was doing exactly that. His work was posted many years ago in the 8mm film forum (not on Doom9, but elsewhere).

However, despite this negative news, I also have something else to share: I don't think it matters. I had many revelations like this in the course of doing this, but what this exercise is all about is synthesizing not only the missing partial frames, but also synthesizing the missing fields. It really doesn't matter where the original fields may lie, because the kinescope process was designed to obscure them and give us a frame of film that looks exactly like what a film camera would have taken if it had been mounted on top of the video camera at the time the original video was taken. Except for the video contrast, and other video artifacts, the kinescope actually does a pretty good job of doing exactly that. Therefore, all we can do -- and indeed all we really WANT to do -- is create the illusion that what was film is now in fact video. Therefore, this process should work equally well with 24p video, or any regular film source that has been IVTC'd in order to recover the original progressive frames.

The one thing you could do if you had the original film is to get a much better scan, because the contrast of most kinescopes that I have captured off the air or received from collectors is really, really bad compared to captures of film that I've done myself. Also, as mentioned above, with access to the film, you could remove the gate weave, and this would significantly add to the illusion that you are once again watching video. The slight residual motion on stationary shots is still a telltale giveaway that makes you subconsciously realize that you still are watching something that isn't quite video (although in the things I've done so far, it is actually pretty amazing at times).

The pros at VidFire clearly do a better job, but for your own work, using the techniques being discussed here, you can pretty close.

[Floatingshed]

Well, I had a good play around with this last night and I'm very impressed, the script worked very well on a section of telerecording from 1963.
The main problem now is the inherant film faults, which are suddenly much more noticeable.
Does anyone know what to use to remove film dirt & spots? I've tried the various filters but the results were not great. Software that allows manual "cloning" of a small area of picture from one frame to another would be ideal as most problems are on one frame but not the next.
Thanks, Andy.

[steptoe]

You could have a look at MCTemporalDenoise or MCSpuds

Both use motion compensation to try and remove just noise or grain but are incredibly slow as they use a lot of external filters and functions to achieve the results but if quality is what you want give them a try

They also both use Removegrain and FFT3DFilter which a lot of people recognise as being pretty good at what they achieve along with various despot and other noise/grain filters

http://forum.doom9.org/showthread.php?t=139766
http://forum.doom9.org/showthread.php?t=131279

[2Bdecided]

Software that allows manual "cloning" of a small area of picture from one frame to another would be ideal as most problems are on one frame but not the next.I asked about that before. It didn't seem to exist. The BBC have something called scratch box that does exactly what you say - you draw over the bad areas and it copies them from the previous/next frame. You'd think it would be trivial on a PC (compared to the kind of processing AVIsynth does), but I haven't found the software yet!

Cheers,
David.

[Floatingshed]

You'd think it would be trivial on a PC.

Precisely. Hopefully some clever chap will come up with something. I'd much rather manually clean things up than leave a filter doing it automatically for a week or two!

[Floatingshed]

JohnMeyer said: Restore the sound. I do this for a living and there are lots of tricks to add "life" to muddy sound.

I could do with some pointers here too! Sorry!
I use cooleditpro for most audio operations and I know my way around it very well (a career in radio helped with that!) but production not restoration is my forte.
These kinescopes/telerecordings have very poor optical (mostly 16mm) sound which has a very harsh middley sound with excessive muddy bass and loads of distortion. Lovely.
What do you do with the sound?

[johnmeyer]

Look for my username and "despot." I think I posted my script before. It will give you some good starting points. Here's a "before" clip:

Before Dust Removal (http://www.youtube.com/watch?v=b92SThVVgZ4)

and after:

After Dust Removal (http://www.youtube.com/watch?v=e8c0r_oD8WQ)

Ignore the dust on the first two seconds of the "after" clip (long story). As you'll see, this technique gets rid of about 80% of the dust (and without removing the tennis ball!).

As for sound, if you have Nero, you probably have the wave editor. The key tool to try is "Band Extrapolation."

[Floatingshed]

Hello again,

i'm still trying to understand this script...
What is going on here:

#use undegrained clip for final output
last.MVFlowFps(backward_vec, forward_vec, num=50, den=1)


Is the comment correct and if so why wouldn't you use the degrained clip?
Sorry to sound stupid but its all very new.
Thanks,
Andy.

[AnnaFan777]

I wonder how could you video geeks still use 60i instead of 30i ?

24p = 24 progressive frames per sec. (film)
30i = 30 interlaced frames per sec = 60 fields interlaced (ntsc)
60p = 30i Bobbed (mostly likely)

where did the 60i come from?

60i = 120 field interlaced.

I'm sure you don't mean that.

[Wilbert]

I wonder how could you video geeks still use 60i instead of 30i ?

24p = 24 progressive frames per sec. (film)
30i = 30 interlaced frames per sec = 60 fields interlaced (ntsc)
60p = 30i Bobbed (mostly likely)

where did the 60i come from?
Some people use 60i to denote 60 fields a second (like the original poster), while others use 30i for that.

[AnnaFan777]

Some people use 60i to denote 60 fields a second (like the original poster), while others use 30i for that.

60fd might be better.

Doesn't "i" indicate "interlaced"?

I remember a few years back, people still used "30i/29.976i" (from the textbook)

I think "60i" starts from those Sony/JVC specs
They think 60i is sexier, more impressive than 30i for end users.

now this is confusing, sony's 60i means interlaced ntsc video,
but 60i here apparently refers to progressive materials.

and both are wrong :)

[Wilbert]

Doesn't "i" indicate "interlaced"?
Yes, indeed.

now this is confusing, sony's 60i means interlaced ntsc video,
but 60i here apparently refers to progressive materials.

No, it means interlaced.

[Mug Funky]

you could say "60" refers to the timebase in Hz rather than the framerate.

then the p or i denotes whether this timebase is expressed in fields per second or progressive frames per second.

60i is the standard way of saying 30fps, interlaced. it's not just marketing bunk either, as the EBU and SMPTE standards also use this terminology.

@ johnmeyer: the last bit of kine i transferred must have been done on a newer machine. fields were visible when i zoomed in my TK, but i didn't have enough time alone with the film to try to line it up perfectly. also, there was natural blurring, probably in the lens used (it was gaussian-ish). weave isn't too bad on modern cameras, and not a problem at all with pin-registered scanners (unless the film is still soft from cleaning). but of course not much kine has been done with modern cameras :) the most recent bit of kine i can think of is the TV series "Frontline", where the documentary-style bulk of the program was shot on hi8 and kine'd to 16mm, then TK'd back to beta SP... sort of like a very expensive deinterlace.

[NerdWithNoLife]

you could say "60" refers to the timebase in Hz rather than the framerate.

then the p or i denotes whether this timebase is expressed in fields per second or progressive frames per second.
Instinctively, I want to disagree (I was trained to think that 30i is 30 interlaced frames per second), but I can see how after using double weave for example, it's kinda sorta 60i, though it should effectively be the same as 30i. But if you were to separate the fields of double weaved "60i" it would be 120 fields per second, with every 4 being identical. And fields aren't interlaced, right? So calling it 60i while referring to fields is a bit odd to me. You've destroyed my education - I don't know what to think anymore! :confused:

[johnmeyer]

the last bit of kine i transferred must have been done on a newer machine. fields were visible when i zoomed in my TKI'm not sure whether anything has been transferred via the Kinescope process since the early 1970s. There are definitely a LOT of movies being shot on video and then transferred to film, but those video to film transfers (including those done from earlier formats like Hi8) are NOT done using a Kinescope. Instead, they are transferred using a film recorder. This device is similar to those used years ago to make 35mm slides for presentations. The usual method is to first resample (from 29.97 to 24) and then deinterlace the video (if you didn't shoot 24p or 25p). Then, each frame is displayed on the film recorder screen, and a photograph is made onto 16mm or 35mm film. Thus, the deinterlacing and frame decimation are done in software. The film recorder display is not a raster display, so there will be no raster lines.

As for the gate weave, it is still pretty obvious even in modern Hollywood movies. If you look at a static title, you'll see it bounce around. If you ever watch the old movies on the TCM channel, they all exhibit gate weave, even though they have been transferred to video from film using a Rank scanner, which provides near-perfect registration. The problem is that the cameras don't have the luxury of advancing the film slowly, but instead have to run at 24 fps. There is just too much stretch, pull, wobble, bounce, etc. in that process, and it only takes a fraction of a millimeter to result in fairly significan movement up there on the big screen.

Raster lines should not be evident in kinescopes because back when this technology was used, a "wobble" was added to each scan line to make it vary up and down slightly. This had the effect of erasing the lines between fields. There were other techniques used, but this is the one most commonly mentioned.

[mikeytown2]

I wonder how could you video geeks still use 60i instead of 30i ?

24p = 24 progressive frames per sec. (film)
30i = 30 interlaced frames per sec = 60 fields interlaced (ntsc)
60p = 30i Bobbed (mostly likely)

where did the 60i come from?

60i = 120 field interlaced.

I'm sure you don't mean that.

Here's a post I made on this subject
http://forum.doom9.org/showthread.php?p=1213819#post1213819