The power of Avisynth: restoring old 8mm films.

[SnillorZ]

Originally Posted by pinterf

Could you please try it with 0.97 again, this time specifying ", align = true" additional parameter for the Crop line?

Sorry not certain which crop line you mean?

You mean like this:

cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot,align = true)  #temporarily remove any black borders on input video

If so the script still bombs the program(s) (e.g. AVSMeter)

[StainlessS]

Align = true,

its lovely that avs+ made things a bit faster/better,
but woulda been even nicer if mod whatever were not an additional issue.


Lots more work for Devs, but who the hell cares bout them !

[pinterf]

Originally Posted by SnillorZ

Sorry not certain which crop line you mean?

You mean like this:

cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot,align = true)  #temporarily remove any black borders on input video

If so the script still bombs the program(s) (e.g. AVSMeter)

Yep, that's it. I'm not sure if there are other Crop commands around.

[SnillorZ]

Anyway, last post for today.

Quick example of a rough cut taken from the script tests:

Using @johnmeyer (VideoFred) script 2017 (Avisynth+ GamMac, etc)

https://youtu.be/UD0tTJLIrK8

[pinterf]

Originally Posted by pinterf

Yep, that's it. I'm not sure if there are other Crop commands around.

So, there were two other Crops in the script.
Using AVS 2.6 and Crop without align=true I got the message from RgTools 0.97:
"RemoveGrain: Invalid memory alignment. Unaligned crop?"
Put the missing ", align=true" lines and the script was working for Avisynth 2.6 as well.

Regarding the slowish avs+ 32-bit run:
Even for a single thread Avisynth+ needs 1300M memory for a basic out-of-box side-by-side comparison script (if not limited). My sources are 1600x1200 scans.

In Avisynth+ when the size of internal frame caches have to be shrunk due to low memory, it has much bigger penalty on speed than it happens in classic Avisynth 2.6.

Quick AvsMeter tests with Avisynth+ 2772 x86, using the formerly attached "JM2017" script:

Single thread SetMemoryMax(1024): 0.26 fps
Single thread SetMemoryMax(2048): 0.46 fps (actually 1350M used)
Prefetch(2) SetMemoryMax(1024): 0.43 fps (actually used 1384M)
Prefetch(2) SetmemoryMax(2700): 0.50 fps (actually used 1770M)

In this case an x64 workflow and thus the virtually limitless memory can help a lot for Avs+. Such videos with full-HD resolution and a complex filter chain require huge amount of memory. Too bad there are still filters without x64 version, but it's just a question of time to have them.

(Did not run x64 tests because of the missing unsharpmask function)

[SnillorZ]

Originally Posted by pinterf

So, there were two other Crops in the script.

Thank you, found those now.

So now testing John's 2012 script using AVS2.6 MT and the newer plugins that are available, gives the following with 4 Threads and 2048M. On the Parade Example AVI (1920x1080 16fps) with Result S4

AVSMeter 2.9.1 (x86) - Copyright (c) 2012-2019, Groucho2004
AviSynth 2.60, build:Feb 20 2015 [03:16:45] (2.6.0.5)

Number of frames: 241
Length (hh:mm:ss.ms): 00:00:15.063
Frame width: 2560
Frame height: 720
Framerate: 16.000 (16/1)
Colorspace: YV12
Active MT Mode: 2

Frames processed: 241 (0 - 240)
FPS (min | max | average): 1.073 | 122698 | 3.818
Process memory usage (max): 2507 MiB
Thread count: 17
CPU usage (average): 77.3%

Time (elapsed): 00:01:03.122

Thank you for the detail regarding the differences in memory handling between Avisynth+ and earlier versions. This has helped me understand why the significant difference in performance between the latest version of the cine film restore script and earlier ones.

So, in a better position now with everyone's input, I am hoping you marvelous code mechanics can come up with the x64 ports of the few remaining external plugins required to give a full 64bit test a run.

Understand that you will all have other priorities (days jobs to do), so no rush, I'll just keep a watching brief here.

[pinterf]

And here is Deflicker 0.5 for x64. Not optimized yet for x64 but at least exists.
https://github.com/pinterf/Deflicker/releases

[StainlessS]

Ooooooo Lovely, thanx P.

[SnillorZ]

Originally Posted by StainlessS

Ooooooo Lovely, thanx P.

What he said +1

[videoFred]

Originally Posted by SnillorZ

Anyway, last post for today.

Quick example of a rough cut taken from the script tests:

Using @johnmeyer (VideoFred) script 2017 (Avisynth+ GamMac, etc)

https://youtu.be/UD0tTJLIrK8

Picture quality is very good! What transfer system have you used?

But aspect ratio is not good: it looks to narrow.
Also, if there is no flicker in the original scan, you can disable deflicker() in the script.

Fred.

[SnillorZ]

Originally Posted by videoFred

Picture quality is very good! What transfer system have you used?

But aspect ratio is not good: it looks to narrow.

Also, if there is no flicker in the original scan, you can disable deflicker() in the script.

Fred.

Hi Fred and thank you. Used a "transfer" company here in UK, they said the equipment they use is from the German company MWA-Nova, using MWA "Vario" Flashscan Digital Data Scanners.

I agree on the aspect ratio. This was from an initial test, based on recommendations from Johnmeyer Post #1095 for improving fps processing of the scripts and Avisynth, he was making the point that 8mm would see little benefit from anything above SD resolutions, so this example was done at 1024x576, but yes I think with the borders added back it makes the frame too "square". Have you found something that works best for standard 8 and is it the same for Super 8? (most of the footage I have is standard 8). Scans have been supplied full HD 1920x1080.

Its funny, I have some footage from early 60's (like this example) that the original film quality is still pretty good, yet some much later stuff (80's) that has aged nowhere near as good, down to handling and equipment I guess. So some footage will require a lot more attention than others.

Sadly I've come across a couple of bits of footage that have been double exposed and I think will have to be consigned to the "too difficult" pile as they will be way beyond my skill set.

Good to hear from you, it was seeing examples of your work that provided the inspiration for doing this.

[johnmeyer]

Your fps, at around 3.5, is starting to look reasonable if your input is really:

Frame width: 2560
Frame height: 720

That 2560 width is what you reported above. Is that really what is being fed to the script?

You want to do two things if you are going to somewhat reduce the resolution prior to feeding the result to your script. The first is to crop off any black bars on the side. Even if you are going to keep everything at HD resolution, it is pointless to process all those black/blank pixels. Which brings me to a key point:

You never want to feed black borders into any of these scripts (see my last comment below).

If you still want to process in HD, crop first to remove all borders (including any on top and bottom); then run the script; and then at the end, pad out the result by adding pixels on the side until you get to a standard 1920x1080 resolution. Getting rid of borders should make a huge difference in performance.

So, if you want to process in a lower resolution, resize down to the lower resolution after doing the crop recommended above. Don't include any borders in the resize operation.

If you do re-size, you'll want to pay attention to the aspect ratio of the film compared to the aspect ratio of standard PAL or NTSC SD video. I actually added some parameters for this, which I don't think Fred ever added to his script. I did this primarily for handling 8mm film which is almost perfectly square, unlike NTSC SD video which at 656x480 (square pixel) or 720x480 (non-square pixel) is 4:3. So when you deliver 8mm scans using the SD DVD format, you will always end up with black bars on the side. It's just the way the math works. However, these inevitable borders must be temporarily stripped out before feeding the film transfer to the script, and then added back. I did this with the "in_bord_left" etc. border variables. It lets you easily remove borders and then, as the very last step, adds back black borders so you end up with the same video size you started with, but without ever processing the black pixels.

This is needed not only to reduce processing time, but also to avoid having funky borders from the motion stabilization. If you leave the black borders, the black from the borders will wander into the frame of the final video.

P.S. Your scans look good, although it looks like you may be losing some highlights (that is the fault of the scan) and it also looks like you might need to do more work in post on gaining the shadows, as exhibited by the walk in the square starting at the 0:13 second mark. I do scene-by-scene gamma adjustments in Vegas, using a custom histogram, but others have used a combination of HDRAGC and GamMac in AVISynth to do this automatically. I posted my GamMac results, but I don't have it working well enough to rely on, so I run the script twice: once with, and once without GamMac and then cut between them just before I deliver the final result.

I need to get back to trying HDRAGC. It has been upgraded a lot since I first tried it a decade ago. It produce some really good results, but was prone to go AWOL on some scenes and really mess things up. When it was working, this is what the results looked like:

HDRAGC good results

[StainlessS]

Also, vast black borders will screw with any auto color correction stuff.

[SnillorZ]

Originally Posted by johnmeyer

That 2560 width is what you reported above. Is that really what is being fed to the script?

John that was just a test run based off a @pinterf advised change to the Crop function. Script will have been pointing to a S4 result as the source i.e. 2 x 1280 side by side.

Your comments on borders sort of brings me back to my question up thread which think you've perhaps missed?

Originally Posted by SnillorZ

@johnmeyer
Please can I revisit your advise above, whilst still testing performance tweaks?

Can I clarify, after doing a R4 processing with your script, are you saying then run the result (VirtualDub>Save As>Uncompressed avi) through a script process using R1/2/3 (as preferred)?

Using same script i.e. letting Stabilise/Denoise/Sharpening process again?

or use a modified version to comment out some of these (noting your comment GamMac introduces some flicker)

to confirm source scans are 1920x1080 with 208px border left & right on the standard 8 scans and 172px Super8 (I've adjusted these values for Mod8 etc).

To confirm with testing the scripts, have the border crop functions:

in_bord_left=208  in_bord_top=0  in_bord_right=208  in_bord_bot=0    #Borders around input that must be removed

cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot)    #temporarily remove any black borders on input video

... as I discovered without you end up with side to side "frame weave" or funky borders as you describe.

However are you saying here

If you still want to process in HD, crop first to remove all borders (including any on top and bottom); then run the script; and then at the end, pad out the result by adding pixels on the side until you get to a standard 1920x1080 resolution. Getting rid of borders should make a huge difference in performance.

that the borders should be removed first outside of your script and not using the crop function as shown above? Sorry I'm a little confused.

Yes I anticipate that when I get into the details of the post edit I'll have scene by scene correction to do. I've never used Vegas and likely will use PPro as I have some experience with it, although some time ago but at least GUI is familiar. So anticipating having to cut some scenes for further AVS processing or something similar in PPro to adjust.

Interested about your comment that some have managed this automatically though. As I know I have a lot of scenes to deal with like the example you picked out - Bless dear old Dad, he did used to like to get his moneys worth by shooting with the same speed film in camera indoors & out, guess film was a good chunk of a working mans wage back then.

[StainlessS]

John probably just means that there is no included pre-cropping in given scripts, so add your own after source filter and before rest of script, you
can just insert a Return Last before the rest of script whilst getting coords correct.

EDIT: Or Return Source, or whatever the cropped clip is called.

[pinterf]

Originally Posted by pinterf

And here is Deflicker 0.5 for x64. Not optimized yet for x64 but at least exists.
https://github.com/pinterf/Deflicker/releases

v0.6 version is ready, SSE2 and AVX2 support in both x86 and x64 version.

[SnillorZ]

Sorry that's why I'm confused, as I'm reading them as John's scripts do include pre-processing crop: as all his scripts have these relevant parts (have only changed the relevant bord pixel parameters):

#VIDEO FILE
#Change the following line to point to your video file
film="D:\VideoSource\**SOURCEFILE**.avi"

...........>

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

...........>

source= Avisource(film).killaudio().assumefps(play_speed).trim(trim_begin,0).converttoYV12()
trimming= framecount(source)-trim_end
source1= trim(source,0,trimming)

cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot,align = true)

or am I misunderstanding and just outed myself as a noob? is it pitchforks and flaming torches time now StainlessS?

[StainlessS]

Originally Posted by SnillorZ

is it pitchforks and flaming torches time now StainlessS?

No not yet, busy at present, maybe tomorrow.

I muchly doubt that john expects you to do an entire pass just for cropping, do as you deem fit.

[johnmeyer]

The inborder = 208 should do the trick. 208 is mod 4 which, I have found, makes the script "happier."

[StainlessS]

John, Fred,

Anybody ever use AutoLevels(autoGamma=true), if so any problems crashes at all ?

Kaboom!

K=BlankClip.Trim(0,-100)
W=K.Invert
K++W++K++W++K++W++K++W
#AutoLevels(autolevel=true,debug=true)
AutoLevels(autogamma=true,debug=true)
return last

Autolevels::adjust() called with gamma=0.0, and so 1/gamma produces Divide by Zero..

I probably will not get time to look further today, but maybe get back to it tomorrow.
Got it compiling x64 OK, thought that I had borked it, but bug in original dll too.

EDIT: Seems to only be RGB24 and RGB32.