Capturing and restoring old 8mm films

[videoFred]

Hello everybody,

Original thread:
http://forum.doom9.org/showthread.php?t=144271

The original thread is getting a bit heavy, so I tought to start up a new thread. In this thread we can perhaps discuss the used Avisynth restoring methods some more in detail.

I have recently upgraded my 8mm film transfer system. A new and better IMI machine vision camera and a custom made RGB Led backlightsource and capture software, both developed and build by Frank Vine.
www.cine2digits.co.uk

For the restoring I have used my film restoring script but I had to modify it for this specific source. For example I have used some hue color corrections. You can see the effect in the blue sky, the skintones and in the vegetation.

Example clip:
https://vimeo.com/49963017

Your feedback is welcome,
many greetings from Belgium,

Fred.

[johnmeyer]

Fred,

I think it is wonderful that you are continuing to improve your transfer system and also improve the post-production techniques, including your script. Many people abandon these projects after their initial effort.

Since you are starting a new thread, and since you want to discuss possible areas for improvement in the script, let me make a few comments about the before/after video you posted. As you know, I have used your script, with a few variations of my own, for several years now. I mention this because what I am about to write below could be seen as negative, but I think you will understand that my intention is to be constructive, and to point out those areas that I still think need improvement.

1. Water. One of the problems in both the MDegrain and also RemoveDirt sections of the script is that they deconstruct waves, flowing water, and other similar "watery" structures. If you go to the 0:20 mark in your video and look at the middle upper part of the little waterfall (concentrate on the bright upper part of the middle section), not only is there a green shift, but there is a loss of a lot of subtle structure in the water, most notable in the whitest parts of the water. I have seen this so often that I no longer use your original script on any scenes that contain open or running water.

2. Blue Sky. I have pretty much given up using the color correction in your original script (the "coloryuv(autowhite=true)" setting), although once in awhile it does help correct color casts that I cannot correct any other way. If you look at the blue skies in the various scenes in the clip, you will see a definite turquoise (blue-green) shift. The original blue colors appear much closer to correct. There is also a shift towards green in some of the white highlights in all the scenes in the clip. I use the Spyder colorimeter to color calibrate my display, so I think I am viewing the colors correctly, although as most people know, color is extremely difficult to get right.

3. Gamma correction. It appears that you may have improved the gamma correction algorithms. The street scene taken from overhead (at about 0:14) has wonderful improvement in the shadows. I will be interested to know what you have done to get that improvement. As anyone who has transferred film knows, this is one of the toughest things to get to look good, especially if you use a stock video camera for capturing.

4. Clouds. This is actually probably the same issue as what I described with the water, but if you look at the clouds at the 0:24 mark, you will see that a lot of subtle structure and detail in the dark part of the clouds has disappeared. One of the issues here is grain removal. I have done a lot of noise reduction over the past ten years, and one thing I have noticed is that noise (and grain) impart a certain artificial sense of detail, even where none existed. Part of this is psychological, but part of it may be due to the fact that all these "dancing artifacts" do tend to form real details via their movement, and eliminating that movement reduces the details. Once again, the problem is most evident in "objects" that have very little fine structure or detail. On the other hand, objects with lots of detail -- like buildings, flowers, people's faces -- look spectacularly better after treatment with the script. The flowers at 0:28 look unbelievably good. Nice job!

5. Streets. This is similar to the water and clouds, but it happens so often in my film transfers that I have noted the problem many times. You'll see it in the scene starting around 1:09. At first, all most people will see is the remarkable improvement on the external structure around the building in the background. Good stuff! But then, if you start to look at the road in front of the car, you'll notice that almost all the detail and "depth" has been eliminated. It almost looks like what happens if you take a little water and smear it over a watercolor painting, blending all the details together.

The scene that follows, with the tops of the railway cars, shows both the positives and negatives: at times the details are improved, and at other times, especially on the tops of other cars, the details seem to be obscured. This scene actually may hold some clues as to how we might build a better script because the detail on the tops of most of the cars seems to have been improved, whereas the details on one or two seem to have been diminished.

6. Motion stabilization edge loss. The depan motion stabilization works exceedingly well. I own Mercalli and have written extensively about Deshaker, so I have had a lot of experience using these tools. You have done a great job discovering the right settings for Depan. However, one area of improvement would be to find a way to use Deshaker or some other tool that preserves the edges so that we don't lose so much of the frame due to the zooming needed to hide the moving black edges introduced by the motion stabilization. I have justified this because the motion stabilization, IMHO, is one of the two biggest improvements the script provides (the other being dirt removal), and because my capture systems (like yours) capture the entire frame of film (the gate has been removed) so all that is being discarded is the part of the film that probably would have never been seen during normal projection. Still, it is sad to see all this information discarded ...

So, in summary, the areas of improvement I would like to work on would include (more or less in order of importance):

1. Better color correction.
2. More natural (or less aggressive) grain removal that doesn't harm detail in water, roads, and clouds.
3. Better gamma correction (which you seem to have already achieved -- I just want to know how you did it!)
4. Deshaking that preserves borders.

I don't have any ideas for #1. I think #2 may mostly be a matter of finding better settings for the existing plugins. #3 you have already achieved, but I hope you can explain how you did it. And, #4 will probably mean incorporating Deshaker, something that may be more bother than it is worth, given the two-pass nature of the approach that program takes.

[RCBasher]

Hi John,

The better gamma is down to the larger pixels in the IMI camera (6.45um) and my RGB lighting system which optimises the full well depth of the sensor.

Hope this helps to explain.

Frank

EDIT Should also add that in-camera gamma is done before dropping to 8-bit output.

[johnmeyer]

The better gamma is down to the larger pixels in the IMI camera (6.45um) and my RGB lighting system which optimises the full well depth of the sensor.I'm sure that the camera is doing a great job, and having direct control over the sensor makes a huge difference.

However, my comments were based on looking on the differences between the left (before the script changes) and right (after the script changes) images in the video Fred linked to. The left is the capture from your camera, and it looks pretty good, but the right image has much better gamma, with far brighter midtones and a little more brightness in the deep shadows. It is this change, which was done in the script and not in the camera, that I was referring to. I'd love to know what plugin and settings Fred used to achieve these differences.

Now, if you are saying that the image on the right side was taken with a different camera than those on the left side, then I did not understand what Fred was trying to show, and I should probably delete my entire previous post.

[videoFred]

Hi John,

Thank you for examining my work in detail!

- Water - clouds- streets: I agree about the loss of detail caused by the heavy grain reduction. Actualy I have already made a few scripts without MVDegrain. But this specific footage needed a lot of additional sharpening. And with this amount of sharpening, the grain especialy in the blue sky became annoying.

- Gamma: like Frank says: this camera/lightsource setup is capable to get nearly everyting out of the film. Even when captured relative dark, the information is still there and it's easy to make it more visible with levels(0,1.2,255,0,255) for example. But I have used a little trick here: levels(0,1.6,255,0,255) followed by autolevels(output_low=6, output_high=250) This gives almost a HDR effect on some scenes.

- Color correction: this is a tricky one because personal taste can play here and all computer systems are different. So I do not know if you see the same colors as I do.

I have used this for the color correction:
.tweak(sat=1.1, hue=0, starthue=10, endhue=169)\
.tweak(sat=1.0, hue=0, starthue=20, endhue=104)\

.tweak(sat=1.1, hue=0, starthue=170, endhue=280)\
.tweak(sat=1.1, hue=0, starthue=170, endhue=229)\

.tweak(sat=1.3, hue=-4, starthue=280, endhue=360)\
.tweak(sat=1.1, hue=-3, starthue=288, endhue=308)

With other sat and hue values we can make a complete different picture. So it's realy a matter of personal taste.

- Deshaking and cropping the borders: Personal I do not mind so much about that. Of cource I try to keep this as low as possible.

Fred.

[videoFred]

Now, if you are saying that the image on the right side was taken with a different camera than those on the left side, then I did not understand what Fred was trying to show, and I should probably delete my entire previous post.

Please leave your interesting post. :)

The right side was not taken with a different camera, I can assure you. The trick is to have max. information in the original even when it appears to look dark on the first sight.

Fred.

[johnmeyer]

Fred,

Thanks for sharing the settings for gamma correction and color correction. I have a big transfer project which I will start within the next week, as soon as the film arrives. I'll use your ideas to tweak my version of your script and report back on any improvements I am able to make.

[videoFred]

Yes, please report back John, we are all learning from each other. Someone has posted different versions of RemoveDirtMC() in the other thread. Have you tried them?

Fred.

[johnmeyer]

Someone has posted different versions of RemoveDirtMC() in the other thread. Have you tried them?No, I missed that thread. I'll see if I can find it.

[RCBasher]

However, my comments were based on looking on the differences between the left (before the script changes) and right (after the script changes) images in the video Fred linked to.
Even when captured relative dark, the information is still there and it's easy to make it more visible with levels(0,1.2,255,0,255) for example.

It is also worth to keep in mind that the left hand image is not the actual original, it has been downsized and compressed for showing on Vimeo.

[johnmeyer]

Well, I searched but could not find the thread talking about improvements to the RemoveDirt function. Hopefully my film restoration skills are better than my forum searching abilities :)

John

[videoFred]

It is also worth to keep in mind that the left hand image is not the actual original, it has been downsized and compressed for showing on Vimeo.

I had to downsize and compress it for Vimeo of cource, but there's another reason for the downsizing too: VDub did not accept the stackhorizontal() comparison clip in full 2776 x 1036 size.

Fred.

[videoFred]

Here it is John:

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

Fred.

[johnmeyer]

Thanks! I'll see what I can do with that information in my upcoming projects.

[johnmeyer]

Two years ago, I posted an alternative to VideoFred's wonderful film restoration script:

Alternative Script (http://forum.doom9.org/showthread.php?p=1406847#post1406847)

My main goal was to improve performance by using MVTools2 instead of MVTools, and also by using multi-threading. I made many other changes as well, all of which are documented in that original script, which you can read by clicking the link above.

Since that time, Fred has provided many updates and improvements to his script, but I haven't shared any of my changes. However, now that Fred has started this new thread, I thought it might be useful to share my latest script. All of my work is based on what he has done, but I continue to focus on performance, as well as to improve dirt removal which, along with motion stabilization, is one of the most important restoration steps in improving old amateur film.

Most of the changes are documented in the comments at the beginning of the script (see my next post), but let me provide a few additional details.

Performance

I took Fred's latest script, and set both input and output speed to 16 fps; set dirt removal to 23; and set block size to 4 (you need this small block size to avoid having small "structure" disappear). I used the Result=4 mode, which does not provide any autolevel or autocolor correction (more on this below).

I set my new and old scripts to the same settings, and then fed the same clip to Fred's script, to my original script, and to my new script. I then ran the "video analysis pass" in VirtualDub and recorded the average fps shown in the progress dialog. Here are the results on my 3.2 GHz Intel i7-965 computer (I used six threads in my multi-threaded scripts):


Fred's latest script: 3.3 fps
My original script: 8.5 fps
My latest script: 15.2 fps


Dirt Removal

In addition to being twice as fast as what I previously posted, my newer script does a much better job of removing dirt because it uses the more sophisticated two-step motion estimation process which has been posted many times in this forum by some of the doom9 "gurus." I spent quite a bit of time (many hours) comparing various pre-filters, and also working on all the other settings. I also used the following test clip to make sure that fine details were not being removed:

Fine Detail Test Clip (http://dl.dropbox.com/u/1561578/Fine%20Structure%20Test.avi)

It is a real challenge to remove dirt and reduce grain, without also removing the wires that suspend the riders on this old spinning amusement park ride. It is a very useful test clip.

Auto Correction

Fred has made many changes to improve autolevels, autocolor, and motion stabilization. I tried his auto correction improvements, but did not get good results with my film transfers. One reason for this is that Fred uses an amazing custom camera that gives him much different gamma and color than what I get using my Sony FX-1 HDV camcorder as the capture device. Also, I have found that every attempt at doing these corrections automatically almost never works across the huge variations that I get in really old amateur film, all of which suffers from poor development, bad storage (which results in non-uniform fading of each of the three color layers), fogging (from inserting or removing the film cartridge in direct daylight), and many other similar mishaps. I have found, unfortunately, no substitute for manual correction inside my video editing program (Sony Vegas).

So, in my script, I still incorporate the old levels and color correction, but I seldom actually use them.

Also, I did not get much improvement with Fred's newer motion stabilization parameters. I have actually reduced the amount of Depan that I use because if I really need to do serious stabilization, I do that in Vegas using either Deshaker or Mercalli. Therefore, my use of Depan is only to remove film gate weave and minor camera movement. I find limiting Depan to small corrections lets me keep more of the original frame, and when I really need stabilization, both Deshaker and (to a lesser extent) Mercalli provide edge restoration so that no border cropping is done.

Performance "Secrets"

How did I achieve better performance, while still improving quality? Here are the changes (see notes in the script for version numbers of various plugins):

1. Use newer version of MVTools2 that was compiled for the SVP project.

2. Use better MT version of AVISynth (2.60, Aug 28, 2012, Ben Rudiak-Gould)

3. Change motion compensation to two-step process, with first step using large block size. This improves quality, while also providing a slight improvement in performance.

4. Use SSE versions of RemoveDirt and RemoveGrain (I don't know why I didn't do this before ...)

5. Moved the autolevels calls inside of a non-multithreading section, and made sure they were near the end of the script (thanks to Didée for this insight).

Read the script changelog below for the full list.

Frame Interpolation

I have provided a different approach to creating interpolated frames, for those who want to change 16, 18, or 24 fps progressive film to 25p, 30p, 50i, 60i, or 60p video. I do this via SubJunk's excellent InterFrame2.avsi script which in turn uses SVP's SVSmoothFps function. This provides both performance and quality advantages compared to using the old MVTools and BlendFPS technology. I personally don't use this function very often, so I only include it as a commented-out section of code, rather than taking the time to provide a more elegant method of enabling/disabling this feature. However, it does work, and works well.

Bad Frame Removal

I also included the "filldrops" function which was first created by MugFunky many years ago. I use this in conjunction with my editing program. In my editing program, when I have a bad frame (from a projector burn, bad splice, sprocket jump, etc.) I use a macro to replace that frame with a duplicate of the previous frame. I then enable this function (remove the comment). The function passes through all normal frames, but when it detects a duplicate, it replaces that with a motion-estimated frame. Here is an example of what can be done:

Restoration of Jumpy Film (http://www.youtube.com/watch?v=uzMFodrGHDs&list=PL230DED9513ECA2CB&index=2&feature=plpp_video)

It is a labor intensive process, but the results are pure magic.

Issues

Many of the plugins used pre-date the SetMTMode() approach to multi-threading in AVISynth. It is actually remarkable that they work at all and, unfortunately, while they do work, stability can be an issue. I have found that if I need to jump ahead in VirtualDub or seek backwards, that I often get crashes. The "solution" is to temporarily comment out the SetMTMode() calls.

I have tried to figure out if a "Distributor()" call might help, but I cannot for the life of me figure out where or how that is supposed to be used, and was not able to fix stability problems by adding that call. I also have tried various SetMemoryMax values, and sometimes that will change the point at which instability occurs, but it really doesn't solve anything permanently.

So, multi-threading in AVISynth is what it is, and this script does work for me, but YMMV, and you should be prepared to change the "threads" variable and also the MemoryMax setting.

Summary

So, as you can tell, I made many of these changes because of a difference in equipment, difference in workflow, and different set of criteria than what Fred had in his work. I think I have achieved better performance and better dirt removal, but other than that, I make no claims that my work is "better" than what Fred has done. We are each dealing with different source material, and each of us has a different aesthetic we are trying to achieve: for instance, I want to retain more of the look of film, so I do less grain reduction and sharpening, and don't usually do motion-estimated frame interpolation.

I offer this to Fred and to everyone else in the hope that perhaps we can collectively move forward and continue to improve transfer and restoration of old movie film stock.

Many thanks not only to Fred, but to all the other people in this forum who have provided the tools and techniques that make all of this possible.

The script follows in the next post.

[johnmeyer]

# film restoration script, based on work by videoFred.
# denoising, resizing, stabilising, sharpening, auto-levels and auto-white balance.
#
# Changes made by John Meyer on October 10, 2012
#
# 1. Modified RemoveDirtMC function to do estimation in two steps. This improves performance and quality.
# 2. Modified MDegrain to do estimation in two steps. This provides roughly the same quality with blocksize=8
# as what I was getting with blocksize=4, but with virtually no performance penalty
# 3. Updated to use special build of MVTools2 that works with SVP.
# 4. Moved Autolevels inside special multi-threading section in order to improve performance with autolevels.
# 5. Removed all trim commands because I do all editing outside the script (in Vegas).
# 6. Included InterFrame. The InterFrame script is better than MFlowXXX.
# 7. Reduced default horizontal depan setting to 5. If "real" stabilization is need for really shaky film, then I do
# stabilization prior to using the script, using either Deshaker or Mercalli. Depan is great for small camera shakes and most importantly
# for removing "gate weave" inherent in film. However, I don't think it works too well as a general-purpose stabilizer.
# 8. Still to do: Improve multi-threading stability (change memorymax and reduce threads variable if script crashes). If you can't goto
# a specific frame without crashes, then comment out all SetMTMode() commands. A "distributor()" statement might improve stability
# when scrubbing, but I doubt it. The problem is that too many of these plugins were not built with MT in mind. The script seems
# to perform very well, however, if you just load and then only go forward (or render). The problems general happen only when "jumping"
# ahead in large intervals.
#
# Changes made by Meyer (June 8, 2010):
# 1. Replaced the MVDegrainMulti function, which was part of the original MVTools
# with the equivalent function using the newer and faster MVTools2.
# 2. Added RemoveDirt function prior to Degrain in order to eliminate large dust spots. This
# substantially improves the dirt removal capabilities of this script. The user will need to
# download this plugin at:
# http://www.removedirt.de.tf/
# 3. Eliminated a great deal of sharpening. The original script did sharpening in at least four places.
# With grainy film stock, this sometimes created objectionable grain. Also, the limitedSharpenFaster
# function, while excellent for video, is uncessarily slow, and isn't really needed for this low
# resolution source. Too much sharpening can make the film look too much like video.
# 4. Added multithreading. I was able to roughly triple the script performance. It may be possible to
# substantially increase this, perhaps as much as 12x instead of 3x. However, the autolevels function
# would have to be replaced (see notes above, for changes made in 2012).
# 5. Fixed several things I found. The result3 option didn't have the manual color correction code, so I
# added that back in. All the numbered "stab" variables (stab1, stab2, etc.) aren't needed except
# for providing a test function for stabilization. I eliminated all of this to streamline the script.
# 6. Deflicker seemed redundant, given all the averaging that takes place with MDegrain, and also the averaging
# that is done when the autolevels outputs are selected. I include that as a "commented out" option.
# 7. I reduced the number of frames used for averaging autolevels from the default (which is 5) to 2.
# I probably should add a variable in the header so the user can change this. Something else to do
# in the future ...
# 8. I added yet another set of crop parameters. I did this because both my capture and my output are
# done using NTSC DV AVI which is 720x480. However, 8mm film is almost exactly square, so the captured
# 720x480 video has black bars on the side. These need to be cropped off prior to doing motion
# stabilization, but then added back prior to the final output, which must still be 720x480 with the
# black bars on the side.
# 9. I reduced the default depan settings to 20, which is what was recommended in the original script. I
# also reduced the post-depan cropping. I did this so I could keep as much of the original frame
# as possible.
# 10. I removed the second denoising and sharpening function. It just seemed to be too much, and made the
# result too artificial
# 11. I removed the MVFLowFPS interpolation. I did this during one of dozens and dozens of attempts
# to improve the speed of the script. I should probably add this back, but if I do so, I also
# need to make it work correctly for interlaced output. If the goal is to show this on an NTSC or PAL
# television set, then it is not correct to convert from the film fps to 25 fps progressive (PAL) or
# 29.97 fps progressive (NTSC). Instead, this should be done as follows (example given is NTSC):
#
# MFlowFPS(source,super,backward_vec, forward_vec, num=60000, den=1001,ml=200)
# SeparateFields()
# SelectEvery(4, 0, 3)
# Weave()
#
# This yields interlaced 29.97, which has twice the temporal resolution as 29.97 progressive, and will
# therefore look correct on a TV set. I have done a lot of this as part of my Kinescope to video
# conversion scripts. For those scripts, the goal is to make the filmed version of a TV show look
# like it was actually videotaped. However, for something that originated on film, this "does violence"
# to the original feel of the media. It is true that it can make horizontal pans less "juddery," but
# it won't feel like film anymore. Also, this technique does break down, espcially with fast motion
# in the foreground.
# 12. Removed the unecessary "coloryuv(off_U=blue,off_V=red)" statement from the denoising section.
# 13. Added killaudio() statement to prevent lockups when using SetMTMode().
#
#====================================================================================

[johnmeyer]

#VIDEO FILE
#----------------------------------------------------------------------------------------------------------------------------
#Change the following line to point to your video file
film="e:\fs.avi"


#GENERAL PARAMETERS
#----------------------------------------------------------------------------------------------------------------------------
result="result4" #specify the wanted output here; valid results are "result1" through "result4" and "resultS1" through "resultS4" for before/after
play_speed=16 #play speed (8mm=16; Super8=18; 16mm sound=24)


#COLOR AND LEVELS PARAMATERS
#----------------------------------------------------------------------------------------------------------------------------
saturation=1.0 #for all outputs
gamma=1.0 #for all outputs
blue= -0 red=-0 #manual color adjustment, when returning result3 & result4. Values can be positive or negative
black_level=0 white_level=255 output_black=0 output_white=255 #manual levels, when returning result2 & result4


#SIZE, CROP AND BORDERS PARAMETERS
#----------------------------------------------------------------------------------------------------------------------------
CLeft=16 CTop=16 CRight=16 CBottom=16 #crop values after Depan and before final resizing
W=720 H=480 #final size after cropping
bord_left=0 bord_top=0 bord_right=0 bord_bot=0 #720p= borders 150
in_bord_left=0 in_bord_top=0 in_bord_right=0 in_bord_bot=0 #Borders around input that must be removed


#STABILISING PARAMETERS
#----------------------------------------------------------------------------------------------------------------------------
maxstabH=05 #maximum values for the stabiliser (in pixels) 20 is a good start value
maxstabV=20
est_left=40 est_top=40 est_right=40 est_bottom=40 #crop and contast values for special Estimate clip
est_cont=1.6

#DENOISING PARAMETERS
#----------------------------------------------------------------------------------------------------------------------------
#Fastest parameters
#denoising_strength=600 #denoising level of first denoiser: MVDegrain()
#denoising_strength=300 #denoising level of first denoiser: MVDegrain()
#block_size= 16 #block size of MVDegrain
#block_size_v= 16
#block_over= 8 #block overlapping of MVDegrainMulti()

#Best compromise between speed and quality
denoising_strength= 600 #denoising level of first denoiser: MDegrain()
block_size= 8 #block size of MVDegrain
block_size_v= 8
block_over= 4 #block overlapping of MVDegrainMulti()

dirt_strength=23 #sets amount of dirt removal (big spots)


#FOUR STEP SHARPENING PARAMETERS
#--------------------------------------------------------------------------------------------------------------------------------
PRE_sharp_ness= 120 PRE_radi_us= 3 #presharpening (UnsharpMask) just after first denoising
Sharp_Strength= 0.1


#AUTO LEVELS PARAMETER
#--------------------------------------------------------------------------------------------------------------------------------
X=4 #X is a special parameter for reducing the autolevels effect on the whites
X2=4 #X2 is a special parameter for reducing the autolevels effect on the blacks


#NUMBER OF THREADS
#--------------------------------------------------------------------------------------------------------------------------------
threads=5


# END VARIABLES, BEGIN SCRIPT
#=================================================================================================================================

# Using AVISynth version 2.60, build August 28, 2012 (Ben-Rudiak-Gould, etc.)
# Using VirtualDub 1.8.6

#Change the following (lower or higher) if you have stability problems with multi-threading
SetMemoryMax(800)

#Load plugins explicitly
LoadPlugin ("mvtools2.dll") #Version 2.5.11.9 2/24/2012
LoadPlugin("autolevels.dll") #Version 0.6.0.0 1/09/2011
LoadPlugin("Deflicker.dll") #Version 0.4.0.0 8/16/2004
Loadplugin("Depan.dll") #Version 1.10.0.0 4/09/2007
LoadPlugin("DepanEstimate.dll") #Version 1.9.2.0 3/25/2007
Loadplugin("mt_masktools.dll") #Version 2.0.23.0 3/14/2008
loadplugin("RemoveDirtSSE2.dll") #Version 0.9 5/05/2005
Loadplugin("RemoveGrainSSE2.dll") #Version 0.9 5/01/2005
Loadplugin("warpsharp.dll") # 4/05/2010

#Use the following for alternative frame interpolation
#loadplugin("svpflow1.dll") #Version 1.2.1.0 5/29/2012
#loadplugin("svpflow2.dll") #Version 1.3.1.0 6/02/2012
#Import("InterFrame2.avsi") #Version 2.1.0 6/27/2012

#Open and crop the video
#Remove all setmtmode statements (there are four in this script) if not using multi-threaded (MT) AVISynth
setmtmode(5,threads)
source1= Avisource(film).killaudio().assumefps(play_speed).converttoYV12() #killaudio() improves stability (in my experience -- others disagree)
cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot) #temporarily remove any black borders on input video
setmtmode(2)

#cropped_source=filldrops(cropped_source) #Use this when removing bad frames that have been removed by duplicating previous frame
#(see notes in function at end of script)

#STABILIZING
#....................................................................................................................................................................
stab_reference= cropped_source.crop(est_left,est_top,-est_right,-est_bottom).tweak(cont=est_cont).MT_binarize(threshold=80).greyscale().invert()
mdata=DePanEstimate(stab_reference,trust=1.0,dxmax=maxstabH,dymax=maxstabV)
stab=DePanStabilize(cropped_source,data=mdata,cutoff=0.5,dxmax=maxstabH,dymax=maxstabV,method=1,mirror=15)

#Alternative line that includes deflicker. I find that this usually is not needed.
#stab=DePanStabilize(cropped_source,data=mdata,cutoff=0.5,dxmax=maxstabH,dymax=maxstabV,method=1,mirror=15).deflicker()


#DENOISING
#...................................................................................................................................................................

#Remove dirt
input_to_removedirt=stab.crop(CLeft,CTop,-CRight,-CBottom)
stabcrop=RemoveDirtMC(input_to_removedirt,dirt_strength,false)

#Reduce grain
prefiltered = RemoveGrain(stabcrop,2)
superfilt = MSuper(prefiltered, hpad=32, vpad=32,pel=2)
super= MSuper(stabcrop, hpad=32, vpad=32,pel=2)

halfblksize= (block_size>4) ? block_size/2 : 4
halfoverlap= (block_over>2) ? block_over/2 : 2

bvec1 = MAnalyse(superfilt, isb = true, delta = 1, blksize=block_size, overlap=block_over,dct=0)
bvec1 = MRecalculate(super, bvec1, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

fvec1 = MAnalyse(superfilt, isb = false, delta = 1, blksize=block_size, overlap=block_over,dct=0)
fvec1 = MRecalculate(super, fvec1, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

bvec2 = MAnalyse(superfilt, isb = true, delta = 2, blksize=block_size, overlap=block_over,dct=0)
bvec2 = MRecalculate(super, bvec2, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

fvec2 = MAnalyse(superfilt, isb = false, delta = 2, blksize=block_size, overlap=block_over,dct=0)
fvec2 = MRecalculate(super, fvec2, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

denoised=stabcrop.MDegrain2(super, bvec1,fvec1,bvec2,fvec2,thSAD=denoising_strength).levels(0,gamma,255,0,255).tweak(sat=saturation).unsharpmask(PRE_sharp_ness,PRE_radi_us,0)


#SHARPENING
#...................................................................................................................................................................
sharp1=denoised.sharpen(Sharp_Strength)
PreBorderFrame = sharp1.Lanczos4Resize(W - bord_left - in_bord_left - bord_right - in_bord_right, H - bord_top - in_bord_top - bord_bot - in_bord_bot)


#FRAME INTERPOLATION (optional)
#...................................................................................................................................................................

#Interpolate frames
#Use this for progressive output -- example shows 29.97 progressive
#PreBorderFrame=InterFrame(NewNum=30000,NewDen=1001,PreBorderFrame,GPU=true,Cores=threads)

#Use this for interlaced output -- example shows 29.97 interlaced
#PreBorderFrame=InterFrame(NewNum=60000,NewDen=1001,PreBorderFrame,GPU=true,Cores=threads).SeparateFields().SelectEvery(4, 0, 3).Weave()


#RESULT1: AUTOLEVELS,AUTOWHITE
#......................................................................................................................................................................
SetMTMode(5) #Turn off SetMTMode for Autolevels
result1= PreBorderFrame.coloryuv(autowhite=true).addborders(X,0,0,0,$FFFFFF).addborders(0,0,X2,0,$000000).autolevels(filterRadius=2).crop(X,0,-X2,-0).addborders(bord_left+in_bord_left, bord_top+in_bord_top, bord_right+in_bord_right, bord_bot+in_bord_bot)

#RESULT3: AUTOLEVELS, MANUAL COLOR CORRECTIONS
#.....................................................................................................................................................................
result3= PreBorderFrame.coloryuv(off_U=blue,off_V=red).addborders(X,0,0,0,$FFFFFF).addborders(0,0,X2,0,$000000).autolevels(filterRadius=2).crop(X,0,-X2,-0).addborders(bord_left+in_bord_left, bord_top+in_bord_top, bord_right+in_bord_right, bord_bot+in_bord_bot)
SetMTMode(2) #Re-enable SetMTMode after Autolevels

#RESULT2: MANUAL LEVELS, AUTOWHITE
#......................................................................................................................................................................
result2= PreBorderFrame.levels(black_level,gamma,white_level,0,255).coloryuv(autowhite=true).addborders(bord_left+in_bord_left, bord_top+in_bord_top, bord_right+in_bord_right, bord_bot+in_bord_bot)

#RESULT4: MANUAL LEVELS, MANUAL COLOR CORRECTIONS
#.....................................................................................................................................................................
result4= PreBorderFrame.coloryuv(off_U=blue,off_V=red).levels(black_level,gamma,white_level,0,255).addborders(bord_left+in_bord_left, bord_top+in_bord_top, bord_right+in_bord_right, bord_bot+in_bord_bot)


#PARAMETERS FOR THE COMPARISONS
#.....................................................................................................................................................................
W2= W+bord_left+bord_right
H2= H+bord_top+bord_bot
source4=Lanczos4Resize(source1,W2,H2)


#COMPARISONS: ORIGINAL VS RESULTS
#......................................................................................................................................................................
resultS1= stackhorizontal(subtitle(source4,"original",size=28,align=2),subtitle(result1,"autolevels, autowhite",size=28,align=2))
resultS2= stackhorizontal(subtitle(source4,"original",size=28,align=2),subtitle(result2,"autowhite, manual levels correction",size=28,align=2))
resultS3= stackhorizontal(subtitle(source4,"original",size=28,align=2),subtitle(result3,"autolevels, manual color correction",size=28,align=2))
resultS4= stackhorizontal(subtitle(source4,"original",size=28,align=2),subtitle(result4,"manual colors and levels correction",size=28,align=2))

#Finish and go home
Eval(result)


# END SCRIPT, BEGIN FUNCTIONS
#=================================================================================================================================


#REMOVE DIRT FUNCTION
#......................................................................................................................................................................
function RemoveDirt(clip input, int "limit", bool _grey)
{
clensed=input.Clense(grey=_grey, cache=4)
alt=input.RemoveGrain(2)
return RestoreMotionBlocks(clensed,input,alternative=alt,pthreshold=6,cthreshold=8, gmthreshold=40,dist=3,dmode=2,debug=false,noise=limit,noisy=4, grey=_grey)

# Alternative settings
# return RestoreMotionBlocks(clensed,input,alternative=alt,pthreshold=4,cthreshold=6, gmthreshold=40,dist=1,dmode=2,debug=false,noise=limit,noisy=12,grey=_grey,show=true)
# return RestoreMotionBlocks(clensed,input,alternative=alt,pthreshold=6,cthreshold=8, gmthreshold=40,dist=3,tolerance= 12,dmode=2,debug=false,noise=limit,noisy=12,grey=_grey,show=false)
}

#This function provides motion compensation for the remove dirt function, thus improving quality.
function RemoveDirtMC(clip,int "limit", bool "_grey")
{
_grey=default(_grey, false)
limit = default(limit,6)

prefiltered = RemoveGrain(clip,2)
superfilt = MSuper(prefiltered, hpad=32, vpad=32,pel=2)
super=MSuper(clip, hpad=32, vpad=32,pel=2)

bvec = MAnalyse(superfilt,isb=true, blksize=16, overlap=2,delta=1, truemotion=true)
fvec = MAnalyse(superfilt,isb=false, blksize=16, overlap=2,delta=1, truemotion=true)

bvec_re = Mrecalculate(super,bvec,blksize=8, overlap=0,thSAD=100)
fvec_re = Mrecalculate(super,fvec,blksize=8, overlap=0,thSAD=100)

backw = MFlow(clip,super,bvec_re)
forw = MFlow(clip,super,fvec_re)

clp=interleave(forw,clip,backw)
clp=clp.RemoveDirt(limit,_grey)
clp=clp.SelectEvery(3,1)
return clp
}

# The following function will remove near duplicates ("0.1") or exact duplicates (change to "0.0").
# It replaces these duplicates with a motion estimated frame. It works really well (IMHO).
#
# Use: In your video editor, replace any single bad frame (burned frame, jump, missing frame from splice, etc.) with a duplicate of the
# previous frame. Then, include a call to this function (see script above, where it is commented out).
#
# Here's an example of how this function can be use:
#
# http://www.youtube.com/watch?v=uzMFodrGHDs
#

function filldrops (clip c)
{
super=MSuper(c,pel=2)
vfe=manalyse(super,truemotion=true,isb=false,delta=1)
vbe=manalyse(super,truemotion=true,isb=true,delta=1)
filldrops = mflowinter(c,super,vbe,vfe,time=50)
fixed = ConditionalFilter(c, filldrops, c, "YDifferenceFromPrevious()", "lessthan", "0.1")
return fixed
}

[fpp]

The sum total of know-how and experience contained in this handful of posts is incredible, and so are the results. Thanks to all for sharing them !

I must definitely make the trip to Belgium someday, to see Fred's new wonder machine :-)

[videoFred]

Hi John,

Thank you for all the work and for sharing.

But you have used an old version of my script! Both stabilizing and sharpening are different in my latest script. I'm also using the modified Autolevels() by Frustum, and this one is much better than the old one.

Anyhow, you have some very interesting ideas about speeding up everything. At this moment, I'm working on a faster script myself, without heavy degraining, but still with RemovedirtMC().

It seems that the botteneck for speed is RemoverdirtMC(). Can you give me some tips to speed up RemoverdirtMC()? Are the SSE2 versions from the dll's realy that much faster?

many greetings,
Fred.

[Gargamel]

Thank you, videoFred and johnmeyer: no doubt that our transfers will again improve a lot. Everybody reads each of your posts with greed !

Bonjour fpp ! Tres heureux de te lire aussi. Tu devrais organiser un petit "week-end du transfert" a Gand, preside par Fred ! Il y aurait foule. ;-)))

[smok3]

Example clip:
https://vimeo.com/49963017


amazing!

[johnmeyer]

But you have used an old version of my script! Both stabilizing and sharpening are different in my latest script. I'm also using the modified Autolevels() by Frustum, and this one is much better than the old one.

One problem in making such a long post (so long that it took three posts), is that many points get lost. I did try the new autolevels, and also tried the different approach to using that DLL that you have in your latest script (using the Low/High parameters), but I ended up with all sorts of levels "pulsing" where the levels would shift violently from frame to frame. I'm pretty sure it is some sort of scene detection issue and probably could have been easily solved. However, as I said in my last post, both the auto levels and auto color correction (not just in your script, but in all scripts I have tried) just can't cope with the huge variation in problems that I find in old amateur film. So, I have to do those manually, and therefore didn't want to spend a lot of time trying to tweak these settings.

I also didn't use your code because your newer approach involves two more color space conversions (converttoRGB24() followed immediately by a converttoYV12() ), and those always have a pretty significant performance penalty.

As for the Depan improvements, I did try them, but didn't see much difference (I did temporarily bolt your new code into my script). Also, I realized, as I was testing, that unless there is a performance improvement or a borders improvement, I'm not too interested because for "big" motion stabilization, I always use either Deshaker or Mercalli inside of Vegas prior to frameserving into your script (or my version of your script).

However, if you think I should re-visit your autolevels, autocolor, and Depan improvements, I'll be happy to go back and make the changes. It is only a few minutes of work to put them back.

It seems that the botteneck for speed is RemoverdirtMC(). Can you give me some tips to speed up RemoverdirtMC()? Are the SSE2 versions from the dll's realy that much faster?

The SSE2 versions only account for a very small portion of the improvement, but there is zero downside to using them, and they are optimized to use faster instructions available in my processor.

Here are, I think, the major reasons why my script is faster, and therefore these are the things you should try when making revisions to your work:

1. Get rid of the original MVTools. MVTools2 is, I think, better in every way, but the most important improvement is that it was rebuilt to be compatible with AVISynth multi-threading. Multi-threading is essential for speed improvement. Once you get rid of the original MVTools, you should be able to use the SetMTMode() statements, and once you do that, you can get integer multiple speed improvements (2x-4x).

2. Use the two-step motion estimation which involves using MRecalculate. This takes very little additional coding. The basic idea is to do an initial motion estimation using a somewhat denoised clip. fft3dfilter is often used, but I found that RemoveGrain is faster and more importantly, results in more dirt removal and fewer false positives. This initial motion estimation is done using really large block sizes, and therefore is quite fast. Then, a second motion estimation is done using the original unfiltered clip, but using the estimation vectors generated from the denoised clip. This second motion estimation is done using a smaller block size. You end up with better motion estimation and, even though two estimations are done, the overall speed is actually faster than if you did one estimation using really small block size.

3. Do the same two-step estimation for the MDegrain section of the script.

4. Try different versions of AVISynth. This is really important when doing multi-threading, both because of stability and also performance.

I do have plans for possible further improvement. As you know, there is another branch of the MVTools development that resulted in a real-time motion estimation tool called SVP. This is designed primarily for creating smooth motion on 24p material by creating interpolated frames. This is actually built into many modern TV sets (the "soap opera effect"). The SVP tool can use GPU acceleration and can be amazingly fast. Unfortunately, it was not created to produce vectors for MDegrain or other plugins like RemoveDirt. However, the authors did respond to requests for a "hack" to let the SVP vectors get passed to these other plugins. I did try this some months ago, and it did work. I just didn't have time to put it into the script and debug it. This potentially could provide another big increase in speed.

SVP is included as part of the InterFrame script for doing motion-estimated frame rate conversion.

[matfra]

Hey Fred.
Is it possible to have you script run in MT mode.
How can I do it. It is crashing for me

[johnmeyer]

Is it possible to have you script run in MT mode. How can I do it. It is crashing for meMy version of Fred's script (posted earlier in this thread) as well as my earlier version (posted in Fred's earlier thread) were designed specifically to run under MT using SetMTMode. They run at least 4x faster and, if you are willing to use larger block sizes for MDegrain, you can approach 10x faster.

[johnmeyer]

In my version of the script, which I posted on the first page of this thread, one of the "improvements" I added was to use the Interframe script for motion interpolation. I mentioned that I don't often use this capability, but that this script had been written specifically for this purpose and therefore, I assumed (oh no!), it would be better.

Well, yesterday I actually used it, and wasn't entirely satisfied. So, I tried a few alternatives and, with this one test case, I got much better results using my own (much simpler) implementation of the function, still using SVP, but using settings that I was not able to achieve just by changing the settings passed to Interframe.

FWIW, here is my motion interpolation code:

function SmoothFPS2(clip source, threads) {
super_params="{pel:2,gpu:1}"
analyse_params="""{
block:{w:16,h:16},
main:{search:{coarse:{distance:-10}}},
refine:[{thsad:200}]
}"""
smoothfps_params="{rate:{num:30,den:16,abs:false},scene:{mode:0,limits:{scene:8500}},algo:21,cubic:1}"
threads = 5

super = SVSuper(source,super_params)
vectors = SVAnalyse(super, analyse_params)
SVSmoothFps(source,super, vectors, smoothfps_params, url="www.svp-team.com", mt=threads)

# Alternative for interlaced output
# SVSmoothFps(source,super, vectors, smoothfps_params, url="www.svp-team.com", mt=threads).SeparateFields().SelectEvery(4, 0, 3).Weave().assumefps(29.97)
}


I was not able to figure out how to pass "num" and "den" parameters to this function because they are inside an array and AVISynth kept throwing an error. I didn't have the time to figure this out, and for my needs it was sufficient to just "hard-wire" the function for the desired final rate.

[matfra]

Hey John,
I already tried you version. Yes its working fast with MTmode. I ran 2 test on same clip, 1 was your and the other was Fred's script. I did get the same quality image on both clip, and your script was running at 22fps. Fred script ran at 9fps. The difference with Fred script, that you can tweak lot more and apply a versy strong denoising, and FlowFPS.
I have a question for you John, or maybe Fred can answer me too. I really dont like the Sharpening fonction used in the script. I find the sharpening too strong or not enough. Often it is sharpening noise and I get (Noise Halo) around people or object in the video.
Is there a way you could implement more tweak for the Sharpening, or maybe replace USM by LSFMod ?

[matfra]

I made some test last night. I managed to replace the denoising parameters with SMDegrain 2.1d.
I get 16fps with very high denoising at tr8 ! Tr2 lot lot more faster than John script. I made some custom parameter.

#SMDegrain SETTINGS
thSAD= 400 #denoising level of second denoiser
tr=8 #number of frames for averaging (forwards and backwards) 3 is a good start value
PreFilter=2 #block size of MVDegrainMulti()
Mode=-1
blksize= 16
lsb=False
ContraSharp=True
Interlaced=False

#DEGRAINING/SHARPENING
#vectors= cleaned.MVAnalyseMulti(refframes=denoising_frames, pel=2, blksize=block_size, blksizev= block_size_v, overlap=block_over, idx=1)
#denoised= cleaned.MVDegrainMulti(vectors, thSAD=denoising_strenght, SadMode=1, idx=2).unsharpmask(USM_sharp_ness3,USM_radi_us3,0)
denoised=noise_baseclip.SMDegrain(thSAD=thSAD,tr=tr,PreFilter=PreFilter,Mode=Mode,blksize=blksize,lsb=lsb,ContraSharp=ContraSharp,Interlaced=Interlaced).unsharpmask(USM_sharp_ness1,USM_radi_us1,0)

[videoFred]

I have a question for you John, or maybe Fred can answer me too. I really dont like the Sharpening fonction used in the script. I find the sharpening too strong or not enough. Often it is sharpening noise and I get (Noise Halo) around people or object in the video.

Are you using the latest version of my script? If you see halo's around people then you have set it way to strong.


Is there a way you could implement more tweak for the Sharpening, or maybe replace USM by LSFMod ?

Been there before... LSFMod was in my early scripts.

Fred.

[wesbc]

Hi,

I have some 8mm film that have been damaged by flood from the recent hurricane sandy. These are old film of my wife's childhood that I've been meaning to transfer to modern media but have kept postponing. With the recent storm my basement was flooded with 6' of water and the film along with the projector was submerged in sea water for several hours. I was only able to get to the film 4 days later. So far I've rinsed each wheel in warm water to clean them. I know nothing about 8mm film so I hope I have not damaged it any further.

If anyone can give me advice on how I can get these restored or can recommend a professional service that is reliable I would greatly appreciate it. Thanks.

Wilson

[johnmeyer]

Good move on getting them into fresh water. That is the correct first step. The next step is to get them into a wetting agent so that they dry without waterspotting. "Photo-Flo" is the stuff I used in the darkroom, and I have a bottle of it in my hand right now. It was made by Kodak. You put a few drops in the water (which should be at room temperature), and slosh the film around to remove any residual chemicals (after the film has been in the fixer, in the case of developing). Since the film was developed long ago, you don't have to worry about chemicals, but you probably have a lot of "crud" from the sea water. In the early days of my darkroom work, in the late 1950s, before Photo-Flo, the way to keep the film from water-spotting was to use a soft chamois or sponge squeegee. The one I used look like a pair of kitchen tongs, with the tongs covered with the soft, non-scratch absorbent material.

So I'd recommend, if you're going to do it yourself, that you combine the two steps: you soak in water containing Photo-Flo, and then wipe the water off with a sponge or similar tool in order to remove any remaining dirt.

If you are looking for professional help, I'd call various East Coast transfer services and ask if they have any special cleaning facilities. Some of the really good places have ultrasonic cleaning machines that will certainly be able to remove the gunk from the water. That is going to be the big challenge, and the sooner you do it, the better. Much of my father's 35mm negatives were immersed in sewer water in a house flood back in the 1940s. When I tried to clean them in the late 1990s, I couldn't get any of the gunk to budge.

Whatever you end up doing, you should still proceed with the fresh water rinse with the wetting agent in order to get rid of the salt.

[edit]You might also want to consider posting in this forum:

8mm Forum (http://8mmforum.film-tech.com/)

[digitap]

Hi, all, this is my first post. I've been reading these threads and saw many of the Vimeo clips. My goal is to help my father process the 5000+ feet of regular 8mm film he had transferred. To get started, I have a few questions. Before I get to those, let me give you some relevant details:

We had the film transferred at filmtransfer.com (now pixcel) using their frame-by-frame HD process. We received a 1080 transfer saved as avi's. Upon playing it, I found they had done a basic time-correction by duplicating each frame. Also, they encoded the file using the Cineform lossless codec.

I've gotten the codec issue squared away, as the one provided on the hard drive they sent back only had the playback codec, not the one able to be used to encode video. I found the necessary software and did a test run using AVS and VirtualDubMod and was able to save the video using the Cineform codec and at the same time delete every other frame. On opening the new file, though I'm getting a message about YV12 color and it doesn't let Fred's script do any processing. I'm not sure how to correct this.

Secondly, is there any way to use Fred's script or JohnMeyer's directly on the source files? I'd like to not have to re-encode all the video to take out the duplicate frames if I can just add a few lines to the restoration scripts to have that process done automatically.

Lastly, what parameters need changed since this is a 1080 transfer vs. standard resolution? I obviously need to adjust the cropping values, but what about the stabilization, spot/grain, and sharpening? Any thoughts or suggestions?

Thanks all!

[johnmeyer]

1. Cineform is now owned by GoPro. You can download from their site a codec that will both play and encode Cineform files.

Cineform Codec (http://gopro.com/3d-cineform-studio-software-download/)

2. Use VirtualDub to cut 2-3 seconds of one of your transfers (choose something with lots of motion). Make sure to use the "Direct Stream Copy" option (video menu). Upload this so we can take a look at the pulldown that was added. The most important thing facing you, before you do anything else, is to remove that pulldown properly, without leaving duplicates, or without decimating good frames. You cannot use any of the film restoration scripts until and unless all pulldown (duplicate) frames or fields are removed. Note, in that last sentence, that I said "frames or fields." Proper pulldown is done at the field level, not frames, and if you decimate entire frames you can end up with a huge mess. Google "3-2 film pulldown" and read up on how the telecine process is done. This will describe the process for 24 fps sound film, but the concept is the same for other, slower, silent film speeds.

Basic pulldown removal is done with the IVTC plugin using TFM followed by Tdecimate. With simple sound telecine, you can use these two functions without any parameters, but with film that runs at other than 24 fps, you must supply your own parameters.

Here are some basic starting points for 16 fps and 18 fps film, but this code may not work for your situation because I have no idea how the pulldown was added:

tfm(display=false)
tdecimate(display=false,mode=0,cycleR=2,cycle=5) #18 fps # 3:3:4 field count
#tdecimate(display=false,mode=0,cycleR=2,cycle=3)#16 fps

3. Use ConvertToYV12 (or ConvertToYUY2, if appropriate) to do the color conversion. There is a performance penalty to these color conversions, so only do them when necessary.

[digitap]

Thank you, I have already downloaded the software from GoPro, maybe I wasn't clear on that point.

I'll see about pulling out a short clip for you. I emailed the company and asked about their time correction and confirmed that they just duplicate each frame. I don't believe they blended fields such that I'd need to do IVTC. When I load a clip into VDub, I can advance frame by frame. In the original clips, you simply see each frame of film twice, then it moves to the next frame, i.e. 1,1,2,2,3,3,4,4... There doesn't appear to be any sort of blending of two different frames of film into a single frame of video.

I guess the company was "being nice" so that the AVIs were immediately playable without having them look like they are in fast forward, but as a consequence they're twice as big (file size) as they needed to be. With this doubling, the speed is off just slightly from the original 16fps (all of these were standard 8mm silent films), but not too noticably.

I guess my second question above is question is whether I could add a parameter at the beginning of the script to only process every other frame? If not, I'll need to convert each clip by removing duplicate frames and saving as separate files. With around 500GB of video, I was simply looking to save the time and space (another 250GB) doing that.

[Guest]

I guess my second question above is question is whether I could add a parameter at the beginning of the script to only process every other frame? Try SelectEven().

[johnmeyer]

I have seen the simple pulldown you describe (duplicating each frame). This is correct for 15 fps film, but for the common 16 fps (8mm and early silent 16mm) and 18 fps (later 16mm and all Super 8), your film will run too slow.

For your simple pulldown, the SelectEven() already recommended is all you need.

When you are ready to create the final video, if it is going to play on anything other than a TV set, you can simply set the playback speed using the guidelines I gave above. Just plug the appropriate fps value into AssumeFPS(), e.g., AssumeFPS(18) for Super 8.

[Boffee]

This one is for John Meyer. I have put your script from post #25 in to the Frame Interpolation section of your new cine script on post #17 replacing the use of Interframe. However I end up with 16 or 18 fps, which is what I started with. I guess, looking at the function SmoothFPS2, it seems to me I am missing a return line. Am I correct? If so, could you say what this should be. Being a newbie to Avisynth I could not figure this out. Thanks

[johnmeyer]

However I end up with 16 or 18 fps, which is what I started with. I guess, looking at the function SmoothFPS2, it seems to me I am missing a return line. Am I correct? I apologize for posting a rather incomplete function. I should have spent more time and allowed you to pass the frame rate into this function. However, in my haste to show what I did, I posted a "hard-wired" function that is designed for a specific source rate (16 fps), going to a specific output rate (30 fps). Therefore, you may need to alter the code to match your source and output rates. You will need to change these numbers

num:30,den:16

A "return" statement is not needed. If omitted "last" is used.

Everything else in the function is hard-wired as well. You would be better served by taking code from the documentation and using that, but feed to that code the settings I used in my function.

[Boffee]

I must be missing something. I had already changed num to 25 and den to 18 for PAL, but same result no change in speed. Tonight I have put this into a script on its own.

avisource="E:\Cine Capture\1977\Band on the march.avi"

LoadPlugin("Plugins/svpflow1.dll")
LoadPlugin("Plugins/svpflow2.dll")

function SmoothFPS2(clip source, threads) {
super_params="{pel:2,gpu:1}"
analyse_params="""{
block:{w:16,h:16},
main:{search:{coarse:{distance:-10}}},
refine:[{thsad:200}]
}"""
smoothfps_params="{rate:{num:25,den:18,abs:false},scene:{mode:0,limits:{scene:8500}},algo:21,cubic:1}"
threads = 5

super = SVSuper(source,super_params)
vectors = SVAnalyse(super, analyse_params)
SVSmoothFps(source, super, vectors, smoothfps_params, url="www.svp-team.com", mt=threads)
}

Result from Avisynth is error "not a clip"
Virtualdub says "scripts return value is not a video clip".


I have also tried the script included with the SVP documentation which works absolutely fine on the same source clip, get 25fps output, just don't seem to be able to get it to work as part of your cine script.
Probably the answer is simple, just can't figure it out, sorry.

[creaothceann]

# LoadPlugin("Plugins/svpflow1.dll") # Are you storing the script in the Avisynth directory? Don't do that; it's better to create a dedicated project directory.
# LoadPlugin("Plugins/svpflow2.dll") # And the plugins and scripts in the "Plugins" directory are automatically loaded.


AVISource("E:\Cine Capture\1977\Band on the march.avi")




function SmoothFPS2(clip c, threads) {
super_params = "{pel:2, gpu:1}"
analyse_params = """{
block : {w:16, h:16},
main : {search:{coarse:{distance:-10}}},
refine : [{thsad:200}]
}"""
smoothfps_params = "{rate:{num:25, den:18, abs:false}, scene:{mode:0, limits:{scene:8500}}, algo:21, cubic:1}"
threads = 5
super = c.SVSuper (super_params)
vectors = c.SVAnalyse(super, analyse_params)
c.SVSmoothFps(super, vectors, smoothfps_params, url="www.svp-team.com", mt=threads)
}

[johnmeyer]

avisource="E:\Cine Capture\1977\Band on the march.avi"

LoadPlugin("Plugins/svpflow1.dll")
LoadPlugin("Plugins/svpflow2.dll") Your script has two problems.

Problem #1: Your script has to call the function, but it doesn't.
Problem #2: When you use a variable to hold your video, you must refer to that variable in subsequent calls, and must explicitly return the variable you use for the final video result using the "return" statement.

Therefore, your script should be:

LoadPlugin("Plugins/svpflow1.dll")
LoadPlugin("Plugins/svpflow2.dll")
threads=1
avisource="E:\Cine Capture\1977\Band on the march.avi"
newvideo = SmoothFPS2(avisource,threads)
return newvideo

The function itself should follow this code, as you already did in the script you posted above.

[Boffee]

Thanks. At last I have got this to work as a stand alone script.

LoadPlugin("Plugins\svpflow1.dll")
LoadPlugin("Plugins\svpflow2.dll")

threads=1
myclip=avisource("your video.avi").ConvertToYV12()
smooth_video = SmoothFPS2(myclip, threads)
return smooth_video

#followed by function SmoothFPS2 etc as shown in post 25

[creaothceann]

In short...

AVISource("video.avi").ConvertToYV12.SmoothFPS2(1)

[tonydokter]

hello everyone I was wondering if anyone of you have made a wetgate for there capture device and if so could thy explain how they did it. Mybe show some examplesor alink to a page

[Gerald1937]

Having learned much from the thread on restoring 8mm film using Avisynth and contributed to it a few times too, my endeavour has been to get the highest quality stop motion digtal capture I could from the source film to use as the feed into Fred's script. This new thread on capturing seems an appropriate place to post information on the system I developed for making my captures. I hope it helps to stimulate ideas on methods of film transport for stop motion capture. Alas at 76 new ideas do not come to me so frequently anymore.

My design, shown at www.mets-telecinesystem.co.uk ,seeks to:-

Be economic by the re-use of equipment I already owned where practical.

Eliminate both horizontal and vertical jitter during capture and to develop the techniques to measure and analyse the performance obtained.

Investigate the factors that affect the speed of stop motion capture and how these can be measured. This includes the significance of shutter type used, global or rolling, on video camera delay and how I measured it.

The capture method I used to get good captures from worn/damaged film.

The use of digital blending to capture the detail in both highlights and shadows on the film during capture.

The web page includes a "How it is made" section and a PDF file for those wanting better quality resolution and drawings that should print to size.http://www.mets-telecinesystem.co.uk

Regards
Gerald1937

[Boffee]

I have a problem with the John Meyer script in post #17 which seems to be related to mvtools2.dll. Everytime I run the script with avisynth & Virtualdub, the latter crashes on exit with " out-of-bounds memory access (access violation) occurred in module 'ntdll'". If I use an old mvtool2.dll version from Fred's script plugin folder, version 2.4.2, then all is OK. Any ideas?

[johnmeyer]

I have a problem with the John Meyer script in post #17 which seems to be related to mvtools2.dll. Everytime I run the script with avisynth & Virtualdub, the latter crashes on exit with " out-of-bounds memory access (access violation) occurred in module 'ntdll'". If I use an old mvtool2.dll version from Fred's script plugin folder, version 2.4.2, then all is OK. Any ideas?Comment out all "SetMTMode()" statements and see if it works. This will substantially reduce performance, but it will help zero in on the problems.

You can also try changing the SetMemoryMax() values.

Finally, check the versions of the various plugins you are using and make sure they match the versions shown in the script.

[Boffee]

Ok commented out setMTmode statements and changed set memory, but no difference. Plugins are OK except for warpsharp. I can only find a version for 2008. Apparently a warpsharp problem is already known, see http://forum.doom9.org/archive/index.php/t-68947.html. Loaded LoadPluginEx.dll, but did not fix the problem. If I use Fred's download package then all is OK, probably why he uses these specific ones. Guess I will have to use these.

[bhershey]

I'm so impressed with the results from Fred's script and also with John's modifications I'm going to use one of them in our post production workflow at my media transfer company.

I'll use VDub in distributed batch mode and get all the film transferred each day processed overnight and ready for builds by the next morning.

Fred's script works great out of the box, but I want to try John's code to take advantage of the speed improvements.

I'm getting an error on exit that will prevent any batch operations... "An out-of-bounds memory access (access violation) occurred in module 'ntdll'". I've tried everything already suggested and all versions match what is listed in the code. error log file is below.

The error goes away when using the older version of mvtools2.

I also get the same error at startup if I alter the "Auto Levels Parameters" X and X2 to any other numbers.

I'll be glad to work with the author to troubleshoot.

Thank you Fred and John!!!

Brian

VirtualDub crash report -- build 30009 (release)
--------------------------------------

Disassembly:
76ef64a0: 49 dec ecx
76ef64a1: 7ffd jg 76ef64a0
76ef64a3: ff8b55108d48 dec dword ptr [ebx+488d1055]
76ef64a9: ffe8 jmp eax
76ef64ab: b90100008b mov ecx, 8b000001
76ef64b0: f0 lock
76ef64b1: 85f6 test esi, esi
76ef64b3: 0f84cf070000 jz 76ef6c88
76ef64b9: f6450c08 test [ebp+0ch], 08h
76ef64bd: 0f852a030000 jnz 76ef67ed
76ef64c3: 803d8003fe7f00 cmp byte ptr [7ffe0380], 00h
76ef64ca: 0f8516970000 jnz 76effbe6
76ef64d0: 85f6 test esi, esi
76ef64d2: 0f8481660000 jz 76efcb59
76ef64d8: 8b5df8 mov ebx, [ebp-08h]
76ef64db: 85db test ebx, ebx
76ef64dd: 0f853a970000 jnz 76effc1d
76ef64e3: 5f pop edi
76ef64e4: 8bc6 mov eax, esi
76ef64e6: 5e pop esi
76ef64e7: 5b pop ebx
76ef64e8: c9 leave
76ef64e9: c20c00 ret 000c
76ef64ec: 90 nop
76ef64ed: 90 nop
76ef64ee: 90 nop
76ef64ef: 90 nop
76ef64f0: 90 nop
76ef64f1: 90 nop
76ef64f2: 90 nop
76ef64f3: 90 nop
76ef64f4: 90 nop
76ef64f5: 90 nop
76ef64f6: 90 nop
76ef64f7: 90 nop
76ef64f8: 90 nop
76ef64f9: 90 nop
76ef64fa: 90 nop
76ef64fb: 90 nop
76ef64fc: 90 nop
76ef64fd: 90 nop
76ef64fe: 90 nop
76ef64ff: 90 nop
76ef6500: 8bff mov edi, edi
76ef6502: 55 push ebp
76ef6503: 8bec mov ebp, esp
76ef6505: 53 push ebx
76ef6506: 8b5d10 mov ebx, [ebp+10h]
76ef6509: 57 push edi
76ef650a: 33ff xor edi, edi
76ef650c: 3bdf cmp ebx, edi
76ef650e: 0f84ef220000 jz 76ef8803
76ef6514: 56 push esi
76ef6515: 8b7508 mov esi, [ebp+08h]
76ef6518: f7464400000001 test [esi+44h], 01000000
76ef651f: 0f859f0e0000 jnz 76ef73c4
76ef6525: f6464801 test [esi+48h], 01h
76ef6529: 0f85db220000 jnz 76ef880a
76ef652f: f6c307 test bl, 07h
76ef6532: 0f8551970000 jnz 76effc89
76ef6538: 8d43f8 lea eax, [ebx-08h]
76ef653b: 80780705 cmp byte ptr [eax+07h], 05h <-- FAULT
76ef653f: 0f842d970000 jz 76effc72
76ef6545: f640073f test [eax+07h], 3fh
76ef6549: 0f8431970000 jz 76effc80
76ef654f: 3bc7 cmp eax, edi
76ef6551: 894510 mov [ebp+10h], eax
76ef6554: 0f8499970000 jz 76effcf3
76ef655a: 807bff05 cmp byte ptr [ebx-01h], 05h
76ef655e: 0f8438970000 jz 76effc9c
76ef6564: 8b4510 mov eax, [ebp+10h]
76ef6567: f6400780 test [eax+07h], 80h
76ef656b: 0f84530e0000 jz 76ef73c4
76ef6571: 8bd3 mov edx, ebx
76ef6573: 8bce mov ecx, esi
76ef6575: e823000000 call 76ef659d
76ef657a: 84c0 test al, al
76ef657c: 0f84420e0000 jz 76ef73c4
76ef6582: 803d8003fe7f00 cmp byte ptr [7ffe0380], 00h
76ef6589: 0f858d970000 jnz 76effd1c
76ef658f: b001 mov al, 01h
76ef6591: 5e pop esi
76ef6592: 5f pop edi
76ef6593: 5b pop ebx
76ef6594: 5d pop ebp
76ef6595: c20c00 ret 000c
76ef6598: 90 nop
76ef6599: 90 nop
76ef659a: 90 nop
76ef659b: 90 nop
76ef659c: 90 nop
76ef659d: 8bff mov edi, edi
76ef659f: 55 push ebp

Built on Aegis on Sun Sep 21 12:07:07 2008 using compiler version 1400

Windows 6.0 (Windows Vista x86 build 6002) [Service Pack 2]

EAX = 0715b428
EBX = 0715b430
ECX = 02fdb2e6
EDX = 03170000
EBP = 0012fb24
ESI = 03170000
EDI = 00000000
ESP = 0012fb18
EIP = 76ef653b
EFLAGS = 00210246
FPUCW = ffff027f
FPUTW = ffffffff

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'ntdll'...

...reading address 0715B42F.

Pointer dumps:

ECX 02fdb2e2: 00000159 680c6ac3 02fe91c0 000111e8 08758b00 7a203d83 750302ff 0c353b2e
EDX 03170000: d5f5d467 01000c58 ffeeffee 00000000 05c70010 031700a8 03170000 03170000
ESI 03170000: d5f5d467 01000c58 ffeeffee 00000000 05c70010 031700a8 03170000 03170000
ESP 0012fb18: 0715b430 0679daa0 7559b0ad 0012fb38 75599c46 03170000 00000000 0715b430
0012fb38: 0012fb74 02fdb2e1 03170000 00000000 0715b430 0679daa0 0675eb80 7559b0ad
0012fb58: 7559b0ad 0012fb4c 0012f73c 0012fb94 02fdb458 02fe91b0 ffffffff 0012fbe0
0012fb78: 02f91889 0715b430 06777220 07110020 02b47d90 0675eb80 0675eb80 0012fbd0
EBP 0012fb20: 7559b0ad 0012fb38 75599c46 03170000 00000000 0715b430 0012fb74 02fdb2e1
0012fb40: 03170000 00000000 0715b430 0679daa0 0675eb80 7559b0ad 7559b0ad 0012fb4c
0012fb60: 0012f73c 0012fb94 02fdb458 02fe91b0 ffffffff 0012fbe0 02f91889 0715b430
0012fb80: 06777220 07110020 02b47d90 0675eb80 0675eb80 0012fbd0 02fe7e40 00000002

Thread call stack:
76ef653b: ntdll!RtlFreeHeap [76e90000+66500+3b]
75599c46: kernel32!HeapFree [75550000+49c32+14]
02fdb2e1: mvtools2!_AvisynthPluginInit2@4 [02f60000+6c70+74671]
02f91889: mvtools2!_AvisynthPluginInit2@4 [02f60000+6c70+2ac19]
02f91729: mvtools2!_AvisynthPluginInit2@4 [02f60000+6c70+2aab9]
5dafea4f: AviSynth!avs_delete_script_environment [5da90000+69000+5a4f]
5dbb30dc: AviSynth!DllCanUnloadNow [5da90000+6f190+b3f4c]
5dafd23a: AviSynth!avs_delete_script_environment [5da90000+69000+423a]
5dafea4f: AviSynth!avs_delete_script_environment [5da90000+69000+5a4f]
5dbb30dc: AviSynth!DllCanUnloadNow [5da90000+6f190+b3f4c]
5db27f57: AviSynth!DllCanUnloadNow [5da90000+6f190+28dc7]
5dafcdd2: AviSynth!avs_delete_script_environment [5da90000+69000+3dd2]
5dafd254: AviSynth!avs_delete_script_environment [5da90000+69000+4254]
01791054: RemoveGrainSSE2!00001054
01791195: RemoveGrainSSE2!00001195
01797092: RemoveGrainSSE2!00007092
01797067: RemoveGrainSSE2!00007067
5dafcdd2: AviSynth!avs_delete_script_environment [5da90000+69000+3dd2]
5dafd254: AviSynth!avs_delete_script_environment [5da90000+69000+4254]
003e4670: RemoveDirtSSE2!_AvisynthPluginInit2@4 [003e0000+4550+120]
003e45a8: RemoveDirtSSE2!_AvisynthPluginInit2@4 [003e0000+4550+58]
5dafcdd2: AviSynth!avs_delete_script_environment [5da90000+69000+3dd2]
5dafd254: AviSynth!avs_delete_script_environment [5da90000+69000+4254]
5db31a55: AviSynth!DllCanUnloadNow [5da90000+6f190+328c5]
5dafcdd2: AviSynth!avs_delete_script_environment [5da90000+69000+3dd2]
5dafd254: AviSynth!avs_delete_script_environment [5da90000+69000+4254]
5daf271b: AviSynth!0006271b
5daf3efb: AviSynth!00063efb
5daf3e59: AviSynth!00063e59
5daff6cb: AviSynth!DllCanUnloadNow [5da90000+6f190+53b]
5daff45b: AviSynth!DllCanUnloadNow [5da90000+6f190+2cb]
73d261ba: AVIFIL32!AVIFileRelease [73d20000+61ac+e]
004b5e72: AVIReadHandlerTunnelW32::Release()
004bcf1a: InputFileAVI::~InputFileAVI()
004bd338: InputFileAVI::(special)()
004be1fc: VDInputFileFLM::Release()
004923c7: VDProject::CloseAVI()
00478223: Deinit()
00481893: WinMain@16()
00584d98: __tmainCRTStartup()
7559d309: kernel32!BaseThreadInitThunk [75550000+4d2f7+12]
76ed1603: ntdll!RtlInitializeExceptionChain [76e90000+415a0+63]
76ed15d6: ntdll!RtlInitializeExceptionChain [76e90000+415a0+36]
0066fe60: VirtualDub!0026fe60
0066fe60: VirtualDub!0026fe60

-- End of report

[johnmeyer]

These are the plugins I use in my version of the script:

LoadPlugin ("mvtools2.dll") #Version 2.5.11.9 2/24/2012
LoadPlugin("autolevels.dll") #Version 0.6.0.0 1/09/2011
LoadPlugin("Deflicker.dll") #Version 0.4.0.0 8/16/2004
Loadplugin("Depan.dll") #Version 1.10.0.0 4/09/2007
LoadPlugin("DepanEstimate.dll") #Version 1.9.2.0 3/25/2007
LoadPlugin("fft3dfilter.dll") #Version 2.1.1.0 2/20/2007
Loadplugin("mt_masktools.dll") #Version 2.0.23.0 3/14/2008
loadplugin("RemoveDirtSSE2.dll") #Version 0.9 5/05/2005
Loadplugin("RemoveGrainSSE2.dll") #Version 0.9 5/01/2005
#Loadplugin("removegrain.dll") #Version 0.9 5/01/2005
Loadplugin("warpsharp.dll") # 4/05/2010

I just checked the date/time on the version of MVTools2 I'm using and it is 2/24/2012 1:15 p.m.

The version of AVISynth may also matter. I am using AVISynth 2.60, build: Mar 9 2013[13:28:27] Ben Rudiak-Gould et al.

I am running this on Windows XP 32-bit SP3. I have Windows 7 64-bit, but never do any AVISynth work on that boot partition.

One question: have you changed the "threads" setting? I have an 8-core computer and if you have fewer cores, bad things may happen. I'd suggest setting threads to 2 for debugging purposes and see if that helps. Also, comment out both SetMTMode statements later in the script, down below the "#Change SetMTMode for Autolevels" comment. You should, of course, leave the two SetMTMode statements, located on either side of the "source1= ..." statement, and these two SetMTMode statements should not be altered.

Make sure you are using my script exactly as posted and that you haven't added any additional SetMTMode or MT statements.

Finally, I did a little research on this forum and found several similar error messages being reported by people using the LimitedSharpenFaster plugin when using SetMTMode. In my script, I still included the vestiges of that plugin, but these old references are all commented out. If you have enabled these lines by removing the comment symbol, I think this will cause that error message. Therefore, make sure that all refernces to LimitedSharpenFaster are commented out or removed. I should have done that before posting, but the script I posted did have them commented out and therefore should not have a problem unless you removed the comment symbol.

[edit]In looking further at other reports of this error message, the version of AVISynth appears to sometimes be the culprit. Try installing the exact version I listed above and see if that helps.

[bhershey]

I just checked the date/time on the version of MVTools2 I'm using and it is 2/24/2012 1:15 p.m.
The version of AVISynth may also matter. I am using AVISynth 2.60, build: Mar 9 2013[13:28:27] Ben Rudiak-Gould et al.
I am running this on Windows XP 32-bit SP3. I have Windows 7 64-bit, but never do any AVISynth work on that boot partition.


I have all the exact same versions.


One question: have you changed the "threads" setting? I have an 8-core computer and if you have fewer cores, bad things may happen. I'd suggest setting threads to 2 for debugging purposes and see if that helps. Also, comment out both SetMTMode statements later in the script, down below the "#Change SetMTMode for Autolevels" comment. You should, of course, leave the two SetMTMode statements, located on either side of the "source1= ..." statement, and these two SetMTMode statements should not be altered.


No help with any of these suggestions.


Make sure you are using my script exactly as posted and that you haven't added any additional SetMTMode or MT statements. Make sure that all refernces to LimitedSharpenFaster are commented out or removed.


script exactly as posted... no change.


[edit]In looking further at other reports of this error message, the version of AVISynth appears to sometimes be the culprit. Try installing the exact version I listed above and see if that helps.

I have Windows Vista Home Premium, AMD dual core 2.0ghz, 4gb memory.
I'm using avisynth.dll 2.60, build: Saturday, ‎March ‎09, ‎2013, ‏‎4:28:48 AM Ben Rudiak-Gould

Next I should probably get you a small sample of my input files. I've tried two so far and they are both DV AVI files... attached is the mediainfo .txt file from the current video file I'm using for testing, if it helps.

Also, any idea why changing X or X2 crashes?

Brian