The power of Avisynth: restoring old 8mm films.

[drewcox]

Freds script works just amazingly. I have no words!!!! Now I have a last problem :) . how to make a final clip??? when I drop the script in virtual dub it shows 2 videos(before and after). what I have to do to have my final amazing clip???????

I am fairly new to Avisynth and VirtualDub(Mod) myself, but what I do is simply File/Save As and choose an appropriate encoding for the output, depending on what you want to do with it next.

Tell me, since you seen to be going through the same process as me over the last few days, I have a few questions:

- have you had many stability problems with the tools (not the script). I am constantly getting VirtualDubMod crashing and locking up.
- Are you using the Multi-Threaded version of AviSynth?
- What sort of sharpening settings are you using? I find I have to keep mine very low (like 10,10,10), probably because my source is so blurry to begin with.

I would love to see a sample of your output.

[johnmeyer]

when I drop the script in virtual dub it shows 2 videos(before and after). what I have to do to have my final amazing clip???????See my earlier posts in this thread. The short version: remove the "S" from the string assigned to the "results" variable (e.g., use 1 instead of S1).

[torwart]

I have a happy end!!!!!!!! :) Everything works!!!! This forum is a miracle I think and you gyes are geniuses!!!! Thanks for your answers!!!!

Answering to Drewcox
I think , that if script and plugins are right the result will be right too. I can't see any stability problems except my wrong acts. Maybe it is not true. I don't have enough experience to talk about this.
I don't use multithreaded avisynth.
For sharpening I use sharpen(), but I know that there are much better filters for this.for example limitedsharpen. Don't ask me about settings, becouse it is a dark forest for me. :)

P.S. Special :thanks: to Mr. Fred.

[videoFred]

Anyway, I am working with settings like:


play_speed=15 #trim frames and play speed (PAL: 16.6666 or 18.75)
numerator= 30 #numerator for the interpolator (final frame rate)
denumerator= 1 #denumerator example: 60000/1001= 59.94fps

Is this the right approach? Can you forsee any issues?

If you want 29,97 fps, then the parameters must be:

play_speed=15 #trim frames and play speed (PAL: 16.6666 or 18.75)
numerator= 3000 #numerator for the interpolator (final frame rate)
denumerator= 1001 #denumerator


I am getting some interpolation artifacts in some high-motion shots, I might end up having to render both interpolated and frame-blended versions and picking and choosing between them during editing. But it's worth it for the smooth playback compared to 18fps...

Yes, you will always have to make a choice here... You can also let iMovie do the frame rate conversion and see what you get.

With these paramerers my script will not change the final frame rate, only the play speed:

play_speed=15 #trim frames and play speed (PAL: 16.6666 or 18.75)
numerator= 15 #numerator for the interpolator (final frame rate)
denumerator= 1 #denumerator example: 60000/1001= 59.94fps

Fred.

[stoffal]

Fred, thank you very much for this wonderful script. I have tested it on some clips and it is amazing how we can polish up with it. I love that I can influence all parameters in detail. It is crazy that still no plugin developer has published a video editing plugin for 8mm restoring (for FinalCut or Premiere or iMovie) that offers these features directly in your video editing software (I know there used to be FilmFix once but they canceled the plugin years ago).

A question into the community:
Maybe some of you use (just like me) a Mac. Unfortunatly, Avisynth is not working on Mac. Do you switch to a 'real PC' for running the script? Or do you use a virtual windows on your Mac to run the script?

And one more:
What codec do you prefer to output the video? Especially, when you want to edit it afterwards in Premiere/FinalCut/etc. For Mac users: As VirtualDub cannot output Quicktime codecs, what codec do you prefer?

Thank you!
Christopher

[Pieter8mm]

Dear Stoffal,
I use a MacPro early2099 with 16GB memory, running VMWare fusion windows 7 for running Fred's script. It is a rock solid system with no errors. It doesn't make a different how many
cores you use for VMW the script don't go faster then 4fps
I use FCP7. After running the script I transcode it with Apple compressor to mov. I made a droplet (see download).

[mathmax]

hi

when I load the script I get this error:

there is no function named unsharpmask

However I have this line in my script:
Line 100: Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\awarpsharp.dll")

and the dll is indeed in the plugins folder...

what is the problem?

[Didée]

UnsharpMask is not part of aWarpSharp, but rather of the "WarpSharp package (http://avisynth.org/warpenterprises/#warpsharp)"

[mathmax]

Thank you Didée :)

http://forum.doom9.org/showthread.php?p=987619#post987619

[Amateur]

Wow your results are stunning. Is this script only good for 8mm film or can it create similar results with NTSC DVDs? I just got a Michael Jackson DVD of his music videos and would love to get them to look as good as you got your film to look. I can't even seem to get this script to work though. How do I call it in MeGUI? I tried copying the interpolation avs file to my avisynth folder and changing it to avsi then using the file name as a default like i do with other filters

film_restoring_frame_interpolation()

but that didn't work. so then i tried to just copy everything from within the avs file and adding that to megui but that doesn't seem to work either. i get an error window that pops up and says "load plugin: " then has a bunch of random symbols, none of which are letters.

here is a sample (http://www.mediafire.com/?xqj7o9uqszcdsyk) of one of the vids i'm trying to encode
here is a different sample (http://www.mediafire.com/?0auyam7thto68y6) from another of the videos on the DVD. this one might be better

[videoFred]

Is this script only good for 8mm film or can it create similar results with NTSC DVDs?

I'm sorry, the script is not made for DVD files.

Fred.

[Amateur]

DARN! I was afraid of that. I wish I could get my live shows to look that good. Incredible.

[fpp]

Hi everyone,

I just subscribed to Doom9 (well, 5 days ago :-) after entirely reading this thread, specifically to thank videoFred and all the other contributors for the wealth of knowledge contained herein.

Like several others here, I am saddled with my dear Dad's Super-8 legacy. All his equipment was stolen during a break-in ages ago, so he has only the reels left, which he can't look at.
Recently he decided (without consulting me first :-) to have them transferred to DVD by a local "professional" (we live 500 km apart).
As often, the guy turned out to be a fraud, charging professional prices for kitchen-table work, and the result is a disaster.

Thirty seconds of a typical scene can be found here (http://dl.dropbox.com/u/10354034/Super8/sample.mpg) (streets of Durban, RSA, 1969 - 14 MB).
I have over two hours of this crap.

Understandably my dad is quite dispirited about the whole business. I fully understand that the rational approach would be to bite the bullet, clean up the old reels and have them transferred again, in DV format, by a more competent operator. This may happen at some point, but in the meantime I would still like to try and salvage some of what's there : make it at least watchable (which it isn't), remount it in narrative order with subtitles, author a proper DVD with menu, etc. If I can do it in two month's time it would make a nice present for his next birthday.

Knowing next to nothing about (analog) video, I've spent quite a few nights reading up about VirtualDub, AviSynth, AVSpmod, etc., and blindly tinkering with those. I think I've learnt more in the hour I spent reading this topic :-)
I can't imagine the time it would take me to get to the level of videoFred's work, and some others here, so I'm really thankful for their sharing it.

Of course I didn't believe for a second the scripts would work as-is on my specific material, and they didn't, so I'd be even more grateful if anyone could spare a moment to peek at it and advise on what I should add/change...

First, I don't have an AVI source, only the VOBs or titles converted to MPEG, so AviSource() won't do. DirectShowSource() works, but it is said to "lose frames". I have found and used DGDecode (DGIndex and MPEG2Source), should I look for something better ?

Second, I suppose this source must be interlaced. Unfortunately I can't make much sense of all I've read on this topic... how should I go about making it progressive first ? Should I even do it, as it will be re-encoded to DVD eventually ? For the time being I'm using Decomb and FieldDeinterlace().

Next, the most obnoxious problem with the DVD transfer is the terrible and permanent stroboscopic effect (flash, flicker ?). My understanding is that it comes from a bad job compensating for the difference between the projector's 18 fps and the recorder's 25, but I can't seem to find the duplicated and blended frames that should result from that, so I think the usual "cures" would not work. Is that right ?

My "cut-n-paste" experiments so far have led me to this very simple script :


LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\hotspot.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\ReduceFlicker.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\decomb.dll")

MPEG2Source("..\source1\VTS_01_1.d2v")
slideframe = ImageSource("slideframe.bmp")
HotSpot(mask="hotspot.bmp", mult=220, add=0)
ReduceFlicker(strength=3, aggressive=true)
FieldDeinterlace()
Overlay(slideframe, mask=slideframe.Invert())
ColorYUV(autogain=true, autowhite=true)


Result is here (http://dl.dropbox.com/u/10354034/Super8/sample.avi) (8 MB).

As you can see, ReduceFlicker does help a lot, but this is still treating the symptom rather than the cause. Is there anything else I could try ?

I have been unable to get any visible difference from more "advanced" plugins, like autolevels, Deflicker, RemoveDirt, despot etc.

Lastly, if/when I get the scripts right I will need to save the bits back to MPEG for DVD authoring. I've seen talk about different codecs to do this (ffmpeg, Hc etc.). Is this important ? Is there a clear choice ?

Thanks (a lot) in advance for any light you people could shed on my (very newbie-ish) questions...
fp

[johnmeyer]

I looked at your clip and see the following problems:

1. The transfer was done by pointing a video camera at the film projector (or screen) and as a result, you have some fields (fields as seen when you serve the video into a "separatefields()" script, not frames) that are blends of two adjacent film frames. I would recommend using TFM followed by Tdecimate to find these blended fields and remove them. With a little trial and error, I think you can turn this transfer into a frame-accurate (like a Workprinter) transfer.

2. The flicker is probably the most objectionable thing to your father. I have found that setting DCT=1 in MVTools does a remarkable job on film flicker, sometimes better than Deflicker. I have often used both. I think you can probably get good results if you use both. I briefly mentioned this elsewhere in this thread:

MVTools to Remove Flicker (http://forum.doom9.org/showthread.php?p=1471963#post1471963)

3. Overexposure. You are hosed with this one. Nothing can be done.

4. Poor resolution. Again, not much can be done here, but if you successfully are able to do #1 above, then you may be able to regain some "apparent" sharpness using VideoFred's script.

5. Color bands. This is easy since this particular footage is B&W. Simply apply a B&W filter. However for color footage, this is going to be tough to remove.

If you lived on the same continent as me, I'd volunteer to do a few reels so you could see the difference between what you got and a good frame-accurate transfer. Since you don't live nearby, I would suggest that you try to find a transfer house that either does Rank Cintel transfers or advertises "frame accurate" transfers. Here in the USA, there is a person named Roger Evans who sells a variety of transfer systems:

MovieStuff (http://www.moviestuff.tv/)

If you can find anyone who uses his frame accurate transfer systems, you should get much better results. Whatever you do, only have them transfer one or two reels, so you can see the results, before you spend a lot more money re-doing the whole thing.

[fpp]

John, thank you SO much for taking the time to look it over and write down such precise advice. Especially in so short a time (about an hour if the time zones are correct :-)... just one more confirmation that this forum, and the people it attracts, are a gem.

Identifying the real/main problems, and choosing the right tools for them, must be the #1 pitfall for the uninitiated in video, film transfer, AVISynth and its cornucopia of mildly documented plugins... Now I have a couple of very focused leads (TFM/Tdecimate and MVTools/Deflicker) which I'm going to follow up immediately. Hopefully I'll get better results than with my poking around in the dark, and save some time to boot !

Your only comment I don't understand is #5 : the footage is definitely not B&W ?... it has bad colour, yes, but colour nonetheless :-)
I just checked the .mpg sample I put online, it shows up fine here in mpHC, VLC etc. Also, the improvement by ColorYUV is plainly seen in the resulting AVI sample.

Otherwise, I fully concur that this is only a short-term stopgap (also an interesting learning process for me :-), and the real solution would be to start over. I had already read up on Roger's work, and yours also (the software side of which I understand is kind of a trade secret at this time :-). I don't know if such facilities are readily available on this side of the Pond, but I will scour what French (and maybe Belgian) forums I can find for hints on reputable operators.

Meanwhile, I'm off chasing the first two wild geese, will report back if they don't eat me :)

Again, thanks much !
fp

[Didée]

What most probably won't work out is the idea to use TFM+TDecimate to get rid of the blendings. (If that would work, then blend removers like Restore24 & SRestore never would've been developped.) The decimator simply watches for frames with the least difference to its predecessor and removes those. In some instances it will remove blended frames, in other instances it will remove good frames and let the blending stand. Decimators simply don't use metrics that could detect blendings.

The other way round, it's quite possible that SRestore could do a reasonable job to remove the blendings.

[fpp]

Didée, your comment is a relief... Right now I am stepping through a clip with tfm(d2v="...", display=true), and it seems to (mostly) get the clean/combed frames right.
However, when I feed that to TDecimate(), as you say, it drops good frames and keeps bad ones... Of course, I haven't really played with the parameters yet : there are so many, and I understand so little :-)

Thanks for the tip on SRestore... another wild goose chase :-)
fp

[Undead Sega]

Check out this setup for transfering 8mm with a Canon 5Dmk2:
http://vimeo.com/20950590 (http://vimeo.com/20950590)

Has anyone actually chekced this out??? :D

[johnmeyer]

Didée is correct about what TFM & TDecimate were originally intended to do. However, he is wrong that they can't be made to work for your situation. I know this because I spent several years developing a film transfer system based on capturing from a projector from which the shutter had been removed and then using TFM and TDecimate to remove the frames that are the least similar. The pharmaceutical drug companies call this sort of thing "off label" and it means using the drug (or in this case the software tool) for something different from what the drug was originally intended to treat. I actually talked to a patent lawyer about patenting the overall technique, but decided that it was too expensive. After I decided not to patent, I posted several times in these forums, providing an outline of my technique.

I have transferred hundreds of hours of film and made a LOT of money using this technique and it works extremely well, even on sound film.

So, in my technique, TFM and TDecimate can and DO work for removing both pulldown frame (the frame that happens when the film is being moved in a projector from which the shutter has been removed) and also from removing the third duplicate field (something that happens every 8-10 frames in a 24 fps shutterless projector when capturing with an unsynchronized 29.97 fps camera). To make this work, you use slightly different settings for TFM than you would normally. Send me a PM and I'll give you the settings.

[fpp]

John, I've read enough about your modus operandi, by following links in this huge thread, to conclude that you know perfectly well that which you speak about.

I was just saying that *I* could not, in the first few tries, get TDecimate to correct what TFM detected as "combed". Besides, I'm not having better success with SRecover, so that says it all :-)

And thanks for the kind offer, trying the PM right away...

[Didée]

John -- Since TDecimate is designed to remove the most-similar frame, I wonder how do you use it for
and then using TFM and TDecimate to remove the frames that are the least similar.
I mean, you can't just tell TDecimate "please don't remove the most similar frames like you usually do, but instead remove the most different frames." On its own, TDecimate just won't do that.

What else? Using 2-pass operation, then figuring the most-different frames from the stats file, and making an override file based on this? It's surely possible to do something this way. No doubt. But then, this doesn't quite comply with your "easy-go" recommendation
I would recommend using TFM followed by Tdecimate to find these blended fields and remove them. With a little trial and error, I think you can turn this transfer into a frame-accurate (like a Workprinter) transfer.
because with the "standard usage" of TFM().TDecimate(), this just can not be done.

[Didée]

Okay - while "LOTS of money" is made behind the scenes via PM:p;), I'll continue publicly ...

Besides, I'm not having better success with SRecover, so that says it all :-)
Oh, that probably means you didn't use SRestore like it should in this case here. Above all, to use SRestore you don't start with TFM a/o TDecimate, but with a simple bob filter.

The following script:
mpeg2source("sample_(fpp).d2v")
o=last

o.bob(-.2,.6)
SRestore(frate=20.0)
requestlinear()
rest=last

calm = rest.temporalsoften(1,255,255,32,2).merge(rest,0.25)#.repair(rest,1).removegrain(11)
calm = calm.temporalsoften(1,255,255,16,2).merge(calm,0.25)

LOP = calm.bicubicresize(180,144).bicubicresize(720,576,1,0)
HIP = rest.bicubicresize(180,144).bicubicresize(720,576,1,0)
HIP = mt_makediff(rest,HIP)
mix = LOP.mt_adddiff(HIP,U=2,V=2)

sup1=rest.msuper(levels=1)
sup2=mix.removegrain(11).msuper()

bv2=sup2.manalyse(isb=true, delta=2,blksize=16,overlap=8,DCT=5)
bv1=sup2.manalyse(isb=true, delta=1,blksize=16,overlap=8,DCT=5)
fv1=sup2.manalyse(isb=false,delta=1,blksize=16,overlap=8,DCT=5)
fv2=sup2.manalyse(isb=false,delta=2,blksize=16,overlap=8,DCT=5)

rest.mdegrain2(sup1,bv1,fv1,bv2,fv2,thSAD=640)

produced the following result: <KLICK> (http://www.mediafire.com/?7hm4cn80y2k82ra) (MediaFire, ~10MB)


Script made up in five minutes (between mowing the lawn and watering the hedgerow). Surely not perfect, but seems like a good start.

BTW, I didn't use DCT=1 because I didn't have the time for that (DCT=1 is very slow with blocksize=8, and pretty much unusably-slow with other blocksizes). Hence, I did a manual flicker-removal for MVTools' search clip. Runs much faster.

[johnmeyer]

I defer completely to Dideé. His script produces much better flicker reduction than what I've been doing. I was aware of the huge speed penalty in using DCT=1, but used it anyway, along with Deflicker, because I was unaware of his vastly superior method of reducing flicker.

As for his post about not being able to use TFM and TDecimate, here's the result of my script which does exactly that:

Recovered Film Clip (http://dl.dropbox.com/u/1561578/Recover%20Frames%20From%20Simple%20Projector%20Capture.avi)

The essential part of the script is this:

#Use "cthresh" to control amount of combing removed. Lower values removes more combing.
tfm(source,display=false,mode=2,pp=0,cthresh=35,micmatching=3,scthresh=2,mmsco=false)
#Use rate to determine how many fieds to decimate. Increase if you see duplicates; decrease if you have skips (jumps)
tdecimate(mode=7,display=false, rate=18)
requestlinear()



I took the additional liberty of cropping, gamma correcting, and color adjusting the clip. I did this in Vegas because color grading is obviously much easier to do in a capable editing program.

So, as I stated before, TFM/TDecimate were not made to do this, but they can be made to do the job. I could not have achieved the result if it didn't work.

"According to the greatest minds of science, it cannot fly. ... But what does the bumblebee do? It ignores the great minds, the skeptics, the computers... and it just goes ahead and flies. "

[johnmeyer]

I don't like to post twice in a row, but because editing a previous post to add more information can sometimes cause problems, I'm doing it anyway. So, with that apology, here is another result, this one using Didée's script, but then running that result through my variation (posted much earlier in this thread) of VideoFred's film restoration script that is the original subject of this thread, with both the Autolevels and Autocolor correction enabled:

Film Restoration Script (http://dl.dropbox.com/u/1561578/Dide%C3%A9%20Results%20Put%20Through%20VideoFred%27s%20script.avi)

I am not suggesting that doing further processing through VideoFred's script necessarily produces a better result, although it does add dirt removal and obviously changes levels and color [edit] and does motion stabilization [/end edit]

To me this particular result seems oversharpened, although I often have this issue with this script and usually substantially reduce the sharpening. The key things it will do for your film is to reduce the dirt, stabilize, and automatically adjust -- to some degree -- for the large exposure variations typical of amateur home movies.

As you will find, when trying to improve film transfers -- even those that were transferred with a better process -- there is no such thing as a "set it and forget it" script that will give good results on every foot of film you have.

Along these same lines, I did a frame-by-frame comparison between the output of Didée's script and my script and found that on some frames his produced a better output, and on some, mine produced a better result. Neither seemed to have a clear advantage over the other. My point in saying this is that removing the blended frames is not an exact thing, and therefore you may still need to adjust slightly the settings used (in either script) in order to get the best results. Clearly you should use Didée's script as the starting point for your further tweaking because its flicker reduction is much better, and it is 20% faster than my script.

[fpp]

Hey guys, hold your fire, I'm drowning ! :-)

Seriously now, a huge thanks (yet again) to both of you for the time you took, here and backstage, to explain and illustrate what I was missing.

All of your results are impressive compared to the original and my own tinkering, and much better than I even thought possible...

Didée, am I correct in supposing that in your script, everything after the SRestore() is (mostly) devoted to deflickering ? The effect is truly amazing, and I'm glad that my questions led to this exchange with John !
(unfortunately, if I wanted to understand how it works before mowing my own lawn and watering the plants, the garden would turn to jungle :-)

John, I tried to follow your advice and plug Didée's output into VideoFred's Restoration script, like you did. However it seems all that processing is a bit too much for my PC (either that, or something is wrong with my setup) : AVS doesn't crash or error out, but slows down to a crawl and looks basically frozen most of the time. I think I'll just try to re-use the levels/colour correction and leave out the costly bits.

You are very right that the quest for ever better results can turn into indefinite tweaking and tuning. It's probably a lot of fun, too, once you know what you're doing, but I'm a beginner working on a deadline... So now that you guys have set me on the right track, I need to get the AVS stuff to the "good enough" level, and then leave good enough alone. Because after that there will be a lot of encoding to do, and then a lot of authoring, which I know better but still takes a lot of time !

I'll work in whatever improvements I can till tomorrow night, then I'll move on. Thanks for getting me started !

[johnmeyer]

Didée will have to answer about how his de-flicker approach works.

As for how I "plugged into" VideoFred's script, what I did was to take your "sample.mpg" file, and then fed that into Didée's script. This produced the identical results that he got, but I saved it using a lossless codec (HuffYUV) as an intermediate file. I then opened this in VideoFred's script, modified some of the parameters, and then saved the result in the DivX format and uploaded. I didn't pay attention to PAR, so when you play the result, it may be horizontally stretched.

VideoFred's script relies on lots of different plugins. If you are having problems, I would suggest going to the first post in this thread, downloading the "Film_Restoring.zip" file, and then reading the "Installing_help.txt" file. Perhaps you have already done this, but if not, I think this will help you get it running. One problem with many of these somewhat complex scripts found here in this forum is that you need to have specific versions of plugins in order for everything to work.

You will have to decide if it is worth it to get his script to work. As you pointed out, Didée's script fixes the two main problems of frame/field blending and flicker. The main reason I uploaded the VideoFred script's modification the Didée script output is to help you decide whether you like what the VideoFred script does on this particular clip.

Here's my opinion after using VideoFred's script on lots of film (some of which earned "lots" of money :) -- apologies for sounding like a jacka$$ in the previous post, and thank you to Didée for keeping me honest):

I find that the dirt removal and stabilization make home movies MUCH more enjoyable to watch. The color and levels adjustments sometimes help, but sometimes make the film look worse: it really depends on the source material. The many levels of sharpening and resolution enhancement sometimes work miracles (take a look at some of the sample VideoFred has posted at Vimeo for some unbelievable results) and other times tend to make the film look "phony." As for the frame interpolation, rather than frame and field repeating (when changing from 16, 18, or 24 fps progressive to either 25 or 29.97 interlaced), I personally don't usually do this because the results don't look as much like film. Having said that, if your footage has a lot of horizontal camera movement, this interpolation works very well on camera pans and will reduce or eliminate the judder that results from the slow temporal cadence of these old film speeds.

[fpp]

John, thanks for the details on your process. As I have quite a lot of material, and am still in the first step (LOL), I want something "batchable" -- in fact I have already written a Python script that writes DOS batch files to process entire directories from one template .AVS : create a .d2v and .avs for each .mpg segment, then use those to encode to .m2v. So I'd rather avoid cutting up the work in chunks, although I understand the PC suffers less that way.

Actually VideoFred's script does work : it is installed as per the instructions, with its own packaged plugins. It's just overwhelming my machine, and I won't even consider the time it would need to encode all my stuff: law of diminishing returns...

So, as you say, I've made my choices so I can move on : Didée's deblender/deflicker, plus your RemoveDirtMC, plus color/levels adjustments, are now declared "good enough", especially compared to the original :-)

Encoding time is plenty long as it is, no need to make it worse... Would SetMTMode help here ? Need to try that.

Oh, and about your last sentence : yes, at the end of the script I'm left with the 18 fps from SRestore. HCenc won't encode that because it's not DVD-compliant ; I just added "AssumeFPS(25)" to test the encoding, but obviously the result runs faster that the source. I'm currently scouring the Avisynth Wiki for the right way to do "frame and field repeating", but sometimes an answer comes faster here than I can find it myself :-)

[johnmeyer]

Would SetMTMode help here ? If you have a multi-core computer, SetMTMode can make things run much faster, so yes, it should help. However, some plugins don't play "nice" with the MT mode. For a simple test to see if it will work, download and copy the MT version of the Avisynth DLL, and then add SetMTMode (5,0) before your AVISource (or equivalent) command, and then add SetMTMode(2) immediately after that AVISource statement. There are other modes you can use.

I always encode about 10-15 seconds of video both with SetMTMode and then without it, and then A/B them on the timeline in my video editor. On one or two occasions I wrote scripts where the results from the various threads got out of sync and I ended up with different video with the MT version. The other problem you can have is instability (crashes), but you'll see that problem pretty quickly, if it is there :). Sometimes you can still get the script to work if you add a SetMemoryMax statement, although it always "feels" to me like you are just delaying the inevitable by doing this (i.e., if something is eating memory, sooner or later you're going to have a problem).

I'm left with the 18 fps from SRestore. HCenc won't encode that because it's not DVD-compliant ; I just added "AssumeFPS(25)" to test the encoding, but obviously the result runs faster that the source. I'm currently scouring the Avisynth Wiki for the right way to do "frame and field repeating", ...

You want to repeat fields and not frames because repeating frames makes the video too "jerky." I got started doing this years ago, and back then the advice was to use a SelectEvery statement. Here's one that I've used for years to go from 18 fps to 30 fps:

separatefields()
selectEvery(6, 0,1, 0,3, 2,3, 2,5, 4,5)
weave()
AssumeFPS(29.97, true)

If you go this route, and want to make your own SelectEvery statement, always check that the fields always alternate between even and odd, and that when you go "backwards" to an earlier field, you only go back one number.

When I have posted the above code in the past, someone always responds by pointing out that you can do the same thing, and do it much more generically, using the following (this is someone else's code):

ChangeFPS(59.94)
AssumeBFF() # or TFF, as required
SeparateFields()
SelectEvery(4, 0, 3)
weave()

For your PAL situation, I think you would simply substitute 50 in the first line (in place of 59.94) and 25 in the AssumeFPS line. Make sure you use the appropriate BFF or TFF statement. Also, make sure that the frame rate of your input video is correctly identified prior to the ChangeFPS statement, because it will do its work based on what it believes to be the current frame rate.

Since I got used to doing it the first way, and since that gives me exact control over the cadence I create, I continue to do it that way. Thus, other than doing a few test several years ago, I haven't used the above code much, but I'm pretty sure it works.

Hope that helps!

[Didée]

at the end of the script I'm left with the 18 fps from SRestore.
I'm not perfectly sure if 18fps is the framerate that should be gotten from this source.

When I did the quick jump at it, I first tried SRestore(frate=18.0), too. Looked at the preview, and had the impression that there were "jumps" in the motion, i.e. missing frames. Then I tried frate=20.0, and the preview seemed smooth.

Maybe the original playback was slightly accelerated? When I look at (my) 20fps sample, it also seems that things are moving slightly too fast - - the pedestrians all appear to be in a hurry, don't they?

Closer examination is recommended. Never rely on what "should be" ... always check what actually is.

[Gavino]

When I have posted the above code in the past, someone always responds by pointing out that you can do the same thing, and do it much more generically,
Probably me, as I was about to do it again... :)

using the following (this is someone else's code):
ChangeFPS(59.94)
AssumeBFF() # or TFF, as required
SeparateFields()
SelectEvery(4, 0, 3)
weave()
AssumeFPS(29.97, true).separatefields()
I don't think that's 'my' code though, or at least the last line isn't.
You don't want the final separatefields, and the AssumeFPS is redundant.
Just use twice the required final rate in the ChangeFPS call (eg 50 for PAL).

[fpp]

If you have a multi-core computer, SetMTMode can make things run much faster, so yes, it should help. However, some plugins don't play "nice" with the MT mode. For a simple test to see if it will work, download and copy the MT version of the Avisynth DLL, and then add SetMTMode (5,0) before your AVISource (or equivalent) command, and then add SetMTMode(2) immediately after that AVISource statement. There are other modes you can use.

After posting I realized I had MTMode enabled when I tried VideoFred's script. It was still slow as molasses, but after I added the required DLLs, it stopped erroring out and seemed to work.
He uses the more aggressive SetMTMode(1), and I have far fewer plugins loaded, so I tried that and it seems to work too. On my script, in interactive mode inside AVSPmod, the speedup is indeed quite perceptible !


You want to repeat fields and not frames because repeating frames makes the video too "jerky." I got started doing this years ago, and back then the advice was to use a SelectEvery statement. Here's one that I've used for years to go from 18 fps to 30 fps:
(...)
Hope that helps!

You bet it does (as always) ! My debt is starting to look like the Niagara Falls :-)

Just to be sure : is this something you do at the very end of the script, when all processing is done ?

[johnmeyer]

Didée makes a very interesting point about 18 fps possibly not being the correct framerate, and I think he is definitely correct.

In fact, there are two different "framerates" you need to think about here.

The first is the framerate (the one Didée refers to) that is actually used for the transfer. The projector could have been running at any speed from 15 fps up to 24 fps (or even a little higher). You have no way of knowing. Many projectors used for "quick and dirty" film to video transfer (like your father had done) have a variable speed control, and the operator adjusts this while watching a monitor connected to the camera, and changes the speed until the flicker is minimized. The slower the projector goes, the more duplicates SRestore will need to remove, and it will do this based on the frame rate you set.

So, you'll need to adjust the SRestore (and maybe other parameters as well) until you get the best result in eliminating the blends and duplicates in the captured video. I would temporarily put a "separatefields()" statement at the end of your SRestore script and then walk through several dozen fields to make sure you get exactly two fields per frame, and that none (or almost none) are blended. You also need to make sure that you don't end up with "jumps" which will happen if you decimate too much and end up remove entire frames. I haven't used SRestore, but with the method I described (using TFM and TDecimate) setting the incorrect framerate definitely could cause frames to be dropped.

Once you get that framerate adjusted correctly, you then have a second, and totally different framerate to figure out, namely what fps was used during the initial filming? This is the one you want to use when adding the pulldown using the ChangeFPS or Selectevery approach I posted above. For amateur video, the cameras were not very precise, and often varied quite a bit. This was especially true of cameras that used a manual windup spring to drive the camera (and the really early ones were hand-cranked ...). As a guideline, most early standard 8mm film was 16 fps; almost all Super 8 was 18 fps; and some later (post-1960) standard 8mm was 18 fps. So, if your dad's film truly was Super 8 and not 8mm, I'd start by making the assumption that it is 18 fps.

In a few cases I've been lucky enough to have a clock with a sweep hand (and one time I had an early digital scoreboard clock in the frame) and was able to determine exactly what fps to use. However, in most cases you'll just have to use the above information as a guideline and then adjust "to taste" based on whether the resulting movement appears natural.

...

I was in the middle of editing this prior to posting and noted that Gavino had posted. He caught a mistake: the separatefields() in the final line of the code in my previous post. As I indicated, I always check my work by temporarily adding that separatefields() line and then look at the resulting fields to make sure I don't have any temporal errors (fields that cause retrograde motion) or spatial errors (each successive field should bob up and down).

In order to avoid confusion for anyone who later reads these posts, I'll remove that separatefields() from my post above.

[fpp]

I'm not perfectly sure if 18fps is the framerate that should be gotten from this source.
When I did the quick jump at it, I first tried SRestore(frate=18.0), too. Looked at the preview, and had the impression that there were "jumps" in the motion, i.e. missing frames. Then I tried frate=20.0, and the preview seemed smooth.
Maybe the original playback was slightly accelerated? When I look at (my) 20fps sample, it also seems that things are moving slightly too fast - - the pedestrians all appear to be in a hurry, don't they?
Closer examination is recommended. Never rely on what "should be" ... always check what actually is.

You mean the fraud that committed the crime also had the projector running faster than 18fps, on top of everything else ? I'll find him and shoot him :-)

Is there anything else to "closer examination" than trial and error to determine a rate where movements "feels natural" ?

Every time I try to figure out the relationships between all these fps (the 18 - we hope - of the camera, the XX of the projector, and the 25 of the recorder), my brain melts faster than the cores at Fukushima... :-(

[johnmeyer]

You mean the fraud that committed the crime also had the projector running faster than 18fps, on top of everything else ? I'll find him and shoot him :-)We're all posting at the same time, so you may not have read what I wrote above. However, just to make sure I got the point across, when pointing a video camera at a projector screen and filming the process, you actually have to adjust the projector speed to something other than the speed at which the original movie was filmed. In fact, almost every transfer system uses a projector speed that is different than the original frame rate. The best transfer systems, like the Rank Cintel or Roger Evan's Workprinters scan or project at a much lower frame rate. The system I developed actually projects at 24 fps, even for 16 fps film.

So, no need to commit mayhem: the transfer house did exactly what was required by that particular method of transfer.

[fpp]

Probably me, as I was about to do it again... :)
I don't think that's 'my' code though, or at least the last line isn't.
You don't want the final separatefields, and the AssumeFPS is redundant.
Just use twice the required final rate in the ChangeFPS call (eg 50 for PAL).

Thanks. As an old-school programmer, I'm always in favour of cutting out two unneeded instructions :-)

[fpp]

Didée makes a very interesting point about 18 fps possibly not being the correct framerate, and I think he is definitely correct.
In fact, there are two different "framerates" you need to think about here.
The first is the framerate (the one Didée refers to) that is actually used for the transfer. The projector could have been running at any speed from 15 fps up to 24 fps (or even a little higher). You have no way of knowing. Many projectors used for "quick and dirty" film to video transfer (like your father had done) have a variable speed control, and the operator adjusts this while watching a monitor connected to the camera, and changes the speed until the flicker is minimized. The slower the projector goes, the more duplicates SRestore will need to remove, and it will do this based on the frame rate you set.
So, you'll need to adjust the SRestore (and maybe other parameters as well) until you get the best result in eliminating the blends and duplicates in the captured video. I would temporarily put a "separatefields()" statement at the end of your SRestore script and then walk through several dozen fields to make sure you get exactly two fields per frame, and that none (or almost none) are blended. You also need to make sure that you don't end up with "jumps" which will happen if you decimate too much and end up remove entire frames. I haven't used SRestore, but with the method I described (using TFM and TDecimate) setting the incorrect framerate definitely could cause frames to be dropped.


OK, that makes it so much clearer.... and thanks for the tip on how to proceed !

So much for that "last, easy question"... *SIGH* :-)


Once you get that framerate adjusted correctly, you then have a second, and totally different framerate to figure out, namely what fps was used during the initial filming? This is the one you want to use when adding the pulldown using the ChangeFPS or Selectevery approach I posted above. For amateur video, the cameras were not very precise, and often varied quite a bit. This was especially true of cameras that used a manual windup spring to drive the camera (and the really early ones were hand-cranked ...). As a guideline, most early standard 8mm film was 16 fps; almost all Super 8 was 18 fps; and some later (post-1960) standard 8mm was 18 fps. So, if your dad's film truly was Super 8 and not 8mm, I'd start by making the assumption that it is 18 fps.


Definitely Super 8, and dad's cam was from 1969, with a battery-operated motor, so 18 is probably a "safe enough" bet...

[fpp]

We're all posting at the same time, so you may not have read what I wrote above.

Definitely some crosstalk going on :-)

However, just to make sure I got the point across, when pointing a video camera at a projector screen and filming the process, you actually have to adjust the projector speed to something other than the speed at which the original movie was filmed. In fact, almost every transfer system uses a projector speed that is different than the original frame rate. The best transfer systems, like the Rank Cintel or Roger Evan's Workprinters scan or project at a much lower frame rate. The system I developed actually projects at 24 fps, even for 16 fps film.

Quite. On a French forum over here, some advertise continuous, shutterless filming at 16.66fps, with post processing that sounds a lot like yours (find the two good frames for each image, recombine them in the right order and dump the rest).

In this particular case, whatever reason the operator set the speed for, it certainly wasn't to reduce flicker :-)

So, no need to commit mayhem: the transfer house did exactly what was required by that particular method of transfer.

That's noble of you, but his others sins were sufficient anyway :-)

[fpp]

Okay, so John's "fps detection" method works, once you get the hang of it... and Dirée certainly has a very, very sharp eye !

The best value I was able to determine (based on appearance of first duplicate, and absence of jumps) is... 19.75. I sort of ran out of patience after that :-)

Running the AVS script in VirtualDub, and the original MPEG side-to-side show no meaningful drift, so I guess it's accurate enough. Problem solved, thanks guys !

However, the "Gavino way" of going back to 25fps adds a whole lot of *very* combed frames (last two out of every five actually). Is that to be expected ?...

[Gavino]

However, the "Gavino way" of going back to 25fps adds a whole lot of *very* combed frames (last two out of every five actually). Is that to be expected ?...
Combed frames are certainly to be expected, since the result is interlaced (and should be encoded as such). That's the point of repeating fields rather than frames.

John's approach with SelectEvery would do the same - this is basically 'hard telecine'. An alternative approach is 'soft telecine' - encode progressive at 18fps (or 19.75 or whatever) and use DGPulldown, as often recommended by manono (eg in this thread).

[johnmeyer]

To add to what Gavino said, go back to my various recent posts, and I always recommend using the "separatefields()" statement, temporarily at the end of your script, so you can make sure that the repeated fields are where you want them.

One thing I didn't mention, but I assume that you understand, is that when fields are repeated in order to make something which only has 18 actual frames per second play at the correct speed on a device which insists on playing everything at 25 frames per second (your PAL TV set), you have to either synthesize new frames (which is an option in VideoFred's script, or which you can do yourself with MVTools2) or you have to repeat frames. However, since repeating entire film frames often results in noticeable hesitations and jumps, the better way which has been used since day one of NTSC television -- and which works when going from 16 or 18 fps for PAL TV -- is to repeat fields instead of frames. This makes the repeat last 1/2 as long, and that makes a big difference in how smooth the result looks. However, this means that you will indeed end up with some frames which contain fields from two adjacent frames. That is perfectly OK, and looks absolutely fine when played on a TV capable of displaying interlaced material (e.g., any PAL TV set). As long as each field in a frame is either from the same moment in time, or the next moment in time, the viewer will not see anything they haven't seen many, many times before.

[videoFred]

@Johnmeyer, Didée, Gavino
--------------------------

Thank you all for contributing to this thread. :)

This is all very interesting information for those who are interested in transfering film.

@fpp:
------
You are in Paris, I am in Gent, Belgium. I can transfer one reel for you, to show you the difference :D
One reel only.. My free time is very limited.

Fred.

[videoFred]

Has anyone actually chekced this out??? :D

Originally Posted by tin3tin
Check out this setup for transfering 8mm with a Canon 5Dmk2:
http://vimeo.com/20950590

Yes, I have. It's very well done. :)

Fred.

[fpp]

@fpp:
------
You are in Paris, I am in Gent, Belgium. I can transfer one reel for you, to show you the difference :D
One reel only.. My free time is very limited.
Fred.

Fred, that's really generous of you (just like John if he hadn't been so far away) ! I imagine someone of your talent must get a lot of requests from "friends" :-)

I will talk with my father and ask him to bring a reel on his next trip over (should be soon). As you say, it would at least prove how badly the job was done, and what could be gained by starting over with a real professional...

I'll keep you posted by MP, thanks much !

BTW, I'm a "Fred", too :-)

[fpp]

@ John & Gavino :

Thanks for the clarifications & the thread on DGPulldown -- I might want to play a bit with that, or the parameters to SelectEvery.

I think I mostly understand what you're telling me, but I still find the result a bit strange. I'm at lunch break right now, but tonight I'll post a couple of screen caps to show you what I mean and see what you think...

[videoFred]

As you say, it would at least prove how badly the job was done, and what could be gained by starting over with a real professional...

I'm not a professional :)

This film project is my free time project. I do something completely different for a living.

Fred.

[fpp]

I'm not a professional :)
This film project is my free time project. I do something completely different for a living.
Fred.

Yes, that was already clear to me... What I really meant is that this is a field in which some "amateurs" are quite plainly as good or better than most "professionals", so one needs to choose carefully :-)

[johnmeyer]

... What I really meant is that this is a field in which some "amateurs" are quite plainly as good or better than most "professionals", so one needs to choose carefully :-)Boy is that ever true. I've talked to some of the people who run these local film to video transfer businesses and ask them things like, "do you clean the film?" or "how do you monitor and change exposure during the transfer," and I get no answer, bad answers, or just blank stares.

[fpp]

@ John & Gavino :
Thanks for the clarifications & the thread on DGPulldown -- I might want to play a bit with that, or the parameters to SelectEvery.
I think I mostly understand what you're telling me, but I still find the result a bit strange. I'm at lunch break right now, but tonight I'll post a couple of screen caps to show you what I mean and see what you think...

Okay, so here is how it looks with SelectEvery(4,0,2).
Most of the time I get three consecutive "clean" frames like this one :
http://dl.dropbox.com/u/10354034/Super8/28.jpg

and then two others like this one :
http://dl.dropbox.com/u/10354034/Super8/30.jpg

Is this the norm ? I feel the resulting clip is not as nice as the fast-running, uncorrected version.

I'm encoding it at 19.75 again right now, and will run DGPulldown on it for comparison. Thankfully that one has a command-line interface too, so if it looks better things will stay scriptable :-)

[johnmeyer]

I'll try once more.

The blending you were seeing in the original transfer was caused by two film frames being projected during the time that one frame of video was captured. These had to be removed. By contrast, what you are seeing now is the standard interlacing "teeth" that are caused by the two fields coming from different moments in time but, when the video is stopped, and you examine both fields at the same time in the freeze frame, you see these herringbone patterns.

So, as I've stated twice now, everything is normal. If you want to post two seconds of this video, I'll look at it and make sure.

Have you actually tried making a test DVD (using a DVD re-writeable) and looking at the result on a TV? That is something you also should always do, and it should give you confidence that your new result looks good.

[fpp]

I'll try once more.
The blending you were seeing in the original transfer was caused by two film frames being projected during the time that one frame of video was captured. These had to be removed. By contrast, what you are seeing now is the standard interlacing "teeth" that are caused by the two fields coming from different moments in time but, when the video is stopped, and you examine both fields at the same time in the freeze frame, you see these herringbone patters. So, as I've stated twice now, everything is normal. If you want to post two seconds of this video, I'll look at it and make sure.
Thanks, but I don't want your patience to wear any thinner... if you say it's OK, then it's OK :-)

Have you actually tried making a test DVD (using a DVD re-writeable) and looking at the result on a TV? That is something you also should always do, and it should give you confidence that your new result looks good.
Not yet, but you're right, I intend to. I need to encode some more material from different scenes and burn it to disc, so I can see it like other people will (I never watch TVs, myself :-).