Degraining script assist?

[Bruce/Fl]

Hello all,

I am an extreme avisynth noob, and hoping that I can get an assist here. Here is my situation.

I am in the process of having some old family 8mm films transferred. I am having it done by cinepost, so the results should be very good, although pricey. And they are very good, especially when I compare them to an earlier VHS transfer from about 25 years ago. In fact they are so good that I find myself actually wishing I could smooth out a bit of the now very easy to see and inherent grain from the source. I saw an example of Freds work online, and was really impressed. Since then I saw some of John Meyers work as well and was really impressed once again. That is what led me here.

As far as video editing programs go, I have been using Vegas 13 Pro. I use it to edit my present day Canon Vixia HD tape files. (ripped with HDVSplit)

I have gone to avisynth.org, and went through some of their tutorials, and so far so good. I am sloooowly learning to write code. (I am not always understanding exactly why I am writing what I write, but it is working). I have messaged John Meyer some and he sent me just the degraining segment of his code, but all of the other peripheral code that is needed to get it to run, well, at this stage of my learning I have no idea how to put it all together.

Additionally, I am working with .mov files, so I believe this is what I need to use, per John Meyer.

LoadVFAPIPlugin("C:\Program Files\AviSynth 2.5\plugins\QTReader.vfp", "QTReader")
QTReader("C:\xxxxxxxx\xxxxxx\xxxxx.mov")

As I mentioned, I have had no luck getting a degraining script to run. Anything beyond the very basic avisynth commands has foiled me. I *was* able to run Freds complete script, by downloading it and all of it's peripherals. It ran for me, and I got the split screen results. It looked horrible, because it was much more tweaking than I needed, but hey, it works. I *can* do this, if I have a complete script.

Anyways, as I was saying, I am getting many rolls of film transferred. Cinepost did the first 100' off of one of my 7" reels as a test run to give me a sample, to see if I wanted to go forward. As I mentioned, it'll be pricey, but I want to do it. I'm hoping to tweak the results some with a degraining script to make them even more impressive, and then hopefully my sister will see the value in it and I'll get some help from her on paying for it, (we'll split the cost). It will be over $1K initially, and then I'll have a few more reels on top of that, a little later. I'm having Cinepost hold my first 7" reel, and they are waiting for my go ahead to finish it off. Then, after being able to show the results to my sister and knowing she's financially in with me on this project, I'll send the rest of the first batch of reels.

All of which is the reason for my post. Could anyone here show me a complete script that will do some degraining for me? Something that all I will need to do is insert the path to my original file to and then run? I have avisynth downloaded, virtualdub, and a few other assorted programs and some dll's. I have a frame server loaded into vegas and have seen it work as advertised. Let me know what I'll need if I don't have it already and I'll get it and install it.

I hope to eventually get familiar with this script writing to be able to understand this better, but if I waited until I could do this all without a helping hand it would take forever. I'm hoping to be able to, once I tweak my sample file and impress my sister, give the go ahead to proceed in the very near future. I hope to make it so stunning of a difference it is a no brainer for her.

All that said, the look of the film after reducing the graininess some may not end up being what I am hoping for, and in that case, I'll just leave it as is. But having seen what is possible with avisynth, I am very hopeful that it will look even better.

Can anyone assist with a complete script? Ideally something that allows me to experiment with the amount of degraining being done, by changing a number here and there in the script.

Thank you

[videoFred]

Hi Bruce,



Can anyone assist with a complete script? Ideally something that allows me to experiment with the amount of degraining being done, by changing a number here and there in the script.

Thank you

This is what my script and John's script already does ;)

But I assume you want something more simple, to start with Avisynth and to learn everything. Is it possible to upload an example clip? Then we can see what you need.

Fred.

[Bruce/Fl]

hi Fred,

PM sent, inquiring about exactly what you'd like.

[Reel.Deel]

@Bruce/Fl

Post a sample for everyone.


Additionally, I am working with .mov files, so I believe this is what I need to use, per John Meyer.

LoadVFAPIPlugin("C:\Program Files\AviSynth 2.5\plugins\QTReader.vfp", "QTReader")
QTReader("C:\xxxxxxxx\xxxxxx\xxxxx.mov")


QTReader is really old, I would recommend LSMASHSource (http://avisynth.nl/index.php/LSMASHSource).

LSMASHVideoSource("xxxxx.mov")

[johnmeyer]

I received six separate PMs from the OP over at Videohelp.com, where he is also pursuing this same topic. I responded, at great length, to each PM. Eventually I realized that he is having problems with the basics, like how to read an MOV file into AVISynth. I eventually had to give up because I wasn't able to help him. Before I gave up, I did send him the basic degraining code that is in my version of Fred's script, and which is taken, more or less intact, from the MVTools2 documentation.

Here's what I sent:

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(super, isb = false, delta = 1, blksize=block_size, overlap=block_over,dct=0)
fvec1 = MRecalculate(super, fvec1, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

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

fvec2 = MAnalyse(super, 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)

However, since this used variables from earlier in the script, he didn't know how to change the variables. If someone wants to help this person, you need to give him a script, absolutely complete, that will read an MOV file, and which will degrain film grain. That was more than I was able or willing to do, but that is what is needed.

Perhaps I should have simply copy/pasted that MVTools2 sample code. Heck, here it is:

AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
super = MSuper(pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

There, that will degrain "test.avi". All you have to do is replace that first line with one that will read your MOV file, and you should get some degraining results. Increase or decrease the thSAD number (currently 400) to change the amount of degraining.

[feisty2]

thSAD=denoising_strength
thSAD ain't no "denoising_strength"... like, really not, way not
I know cuz I just read the code of mvtools and wrote my own ultra high precision (32bits float) branch
thSAD is like, more of the tolerance of imperfect motion estimation, larger thSAD = messed up motion vectors with lots of errors would still be, like, okay, acceptable and join the process
the real strength of MDegrain is "tr", larger tr = higher strength

[Bruce/Fl]

I received six separate PMs from the OP over at Videohelp.com, where he is also pursuing this same topic. I responded, at great length, to each PM. Eventually I realized that he is having problems with the basics, like how to read an MOV file into AVISynth. I eventually had to give up because I wasn't able to help him. Before I gave up, I did send him the basic degraining code that is in my version of Fred's script, and which is taken, more or less intact, from the MVTools2 documentation.

Here's what I sent:

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(super, isb = false, delta = 1, blksize=block_size, overlap=block_over,dct=0)
fvec1 = MRecalculate(super, fvec1, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

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

fvec2 = MAnalyse(super, 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)

However, since this used variables from earlier in the script, he didn't know how to change the variables. If someone wants to help this person, you need to give him a script, absolutely complete, that will read an MOV file, and which will degrain film grain. That was more than I was able or willing to do, but that is what is needed.

Perhaps I should have simply copy/pasted that MVTools2 sample code. Heck, here it is:

AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
super = MSuper(pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

There, that will degrain "test.avi". All you have to do is replace that first line with one that will read your MOV file, and you should get some degraining results. Increase or decrease the thSAD number (currently 400) to change the amount of degraining.

Hello John, Everyone,

A little background. just so everyone knows the story.

The night I initially contacted you, after first seeing Freds and then your work, I checked out various online resources looking for more info on this wonderful avisynth scripting. I was sent to doom9 first, where I started my researching. But I was not a member here yet, so I looked other places as well. I am a member over at Videohelp, and when I popped in there I saw your name over there as well, and that is why I reached out to you there. It wasn't that I was "pursuing this same topic" over there on their boards, but rather my recognizing your name over there, so I PM'd you using that forum. I don't want it to appear that I was over there sucking them dry of knowledge, and when done tossing them aside and coming here, in fact I never brought up the subject over there at all, I simply PM'd you using their messaging.

And your responses to my questions were very detailed, and I will once again thank you for the time and effort you put into trying to educate me. I am trying to learn about this scripting, but it is totally foreign to me, which you saw from my questions I am sure. I am still going through tutorials and working with more complicated scripting, but it is a very slow process. But regardless, after a few back and forth messages I gathered a sense that what I was trying to accomplish in contacting you, was most likely irritating you to some degree, so I stopped, and it looks like my instincts were correct, as you said above, what I was hoping for "... was more than I was able or willing to do". But once again, thank you very much for your efforts, and maybe someday soon I will be able to "talk shop" with you and others here when I actually have more of a clue as to what I am talking about. Because in my messages with you, and also here on my initial post, I tried to be very clear that I am very, very new to this and my knowledge is very, very limited in this area. I'm hoping I was clear on that as well here, I'm not trying to anything sneaky, I just need help.

But at the forefront of all of this is that I am hoping someone will help me jump ahead quickly in this scripting, on solely the degraining aspect, for the purpose of hopefully improving what Cinepost sent me so I can show my Sister what is possible, and that she will feel better about making a monetary contribution. All of the rest of the capabilites avisynth gives you, stabilization, adjusting levels, sharpening, etc., I am fine with learning as I go. It is only the degraining aspect of it that has, at least for me, a time constraint.

But John is right, what I really need is a complete script that is sort of plug in play, something I'll just need to put in the location of my sample clip into, and/maybe add some more plug-ins into, etc. to get it to do its thing. I hope my initial post here made that clear.

[Bruce/Fl]

@Bruce/Fl

Post a sample for everyone.



I'll work on doing just that tonight.

How much (length) of a sample would be best? Taking file size into consideration. The sample scan they sent me was approximately 10 minutes. I would assume you would only need 10, 15 seconds worth?

Thank you

Bruce

[StainlessS]

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



John, would below be more like what you require ?


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


If no difference from original sizes, would MRecalculate be necessary ?

EDIT: Oops, maybe below better


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

[feisty2]

All same stuff
John's version
Blksize > 4 (blksize=8, 16, 32), then halve it, if not (blksize =4), keep it 4
Your version
1: buggy, say blksize =8, and you know what will happen
2: = John's version blksize/2>=4 ---> blksize>=8---->blksize>4, If not, then obviously blksize=4, and ":blksize"=":4"

[StainlessS]

Cant remember off hand if block sizes have to be a power of 2.

What about MRecalculate thing feisty ?

EDIT: yes 1. was buggy.

[feisty2]

Recalculate is meant for, not just different, actually smaller block size, the vector clip contains 3 things of each vector, vx, vy and thsad, recalculate reads the thsad from one vector, and if it's too high, then the block is kind of "high energy" (complicated) or whatever and the motion estimation is bad and recalculate will divide the large block into 4 smaller blocks and try to match again, so you'll always have the most precise match

[StainlessS]

Yeh but, if sizes aint smaller, then is there any point at all in calling MRecalculate, is it a NOP, or just a time waster ?

(Or does it actually still do something useful)

[feisty2]

If the recalculate blksize >= analyze blksize ------> waste of time

[StainlessS]

Thank you F, then my initial post was perhaps not also a total waste of time.

[johnmeyer]

We're off on a tangent here. The block size and MRecalculate were an attempt to get a slight improvement in speed and quality, and that's exactly what I got: a slight improvement. The code I posted was just lifted directly from the MVTools2 documentation.

And, speaking of documentation, I'm still trying to figure out this statement:

thSAD ain't no "denoising_strength"... like, really not, way not
I know cuz I just read the code of mvtools and wrote my own ultra high precision (32bits float) branch
thSAD is like, more of the tolerance of imperfect motion estimation, larger thSAD = messed up motion vectors with lots of errors would still be, like, okay, acceptable and join the process
the real strength of MDegrain is "tr", larger tr = higher strength First of all, "tr" was not a part of MVTools2 until version 2.6.x, and I'm still using 2.5.x.

Second, in reading the 2.6.x documentation, "tr" is not used in their sample degraining code, so the authors did not think it important. Here is that code, copied directly from the documentation:

To denoise interlaced source with function MDegrain2i2:

function MDegrain2i2(clip source, int "overlap", int "dct")
{
overlap=default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct=default(dct,0) # use dct=1 for clip with light flicker
fields=source.SeparateFields() # separate by fields
super = fields.MSuper()
backward_vec2 = super.MAnalyse(isb = true, delta = 2, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse(isb = false, delta = 2, overlap=overlap, dct=dct)
backward_vec4 = super.MAnalyse(isb = true, delta = 4, overlap=overlap, dct=dct)
forward_vec4 = super.MAnalyse(isb = false, delta = 4, overlap=overlap, dct=dct)
fields.MDegrain2(super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400)
Weave()
}

AVISource("video.avi")
mdegrain2i2(4,0)


Finally, "tr" really is not a very practical denoising variable, since it can only take on a few discrete values (0 through 5 is the extent of the practical range). Most desnoising scripts, like this one:

http://forum.doom9.org/showpost.php?p=1714954&postcount=2

use the tr variable as more of a switch than a denoising setting. So, yes, it can be included as a way to change the nature of the denoising, but I certainly wouldn't call it a "strength" variable.

thSAD isn't exactly a strength variable either, but it does continuously (rather than discretely) change the nature of the denoising, and is the best setting this function offers for changing the amount of denoising.


Note to the OP: the code above is what you might want to use if you are using the latest version of MVTools2. Just change the AVISource statement to whatever you use to read your MOV video, and then see what the result looks like.

[feisty2]

What..? tr and thsad are 2 100% different and irrelevant things, you can't just say, like, one is continuous and one is discrete
Man, you can't even compare these two
They are just like... Apples and oranges...

[johnmeyer]

What..? tr and thsad are 2 100% different and irrelevant things, you can't just say, like, one is continuous and one is discrete
Man, you can't even compare these two
They are just like... Apples and oranges...Irrelevant to what?? thSAD is completely relevant to any discussion of using MDegrain2 for denoising.

As for your other statement, I totally agree that tr and thSAD are completely different. But I was not, in any way, "comparing" them.

So, I don't understand at all what you are trying to say. What is your point?? Also, how are you trying to help the OP (and anyone else) achieve better degraining results?

[feisty2]

I was just trying to get that misunderstanding about "thsad" as denoising strength straight
Thsad is not the strength of denoising
It's the strength of error tolerance of motion estimation

[johnmeyer]

I was just trying to get that misunderstanding about "thsad" as denoising strength straight
Thsad is not the strength of denoising
It's the strength of error tolerance of motion estimationI agree. I also agree that it does not provide ideal control over denoising. Unfortunately, the way the code is written, and given the variables that are exposed to the user, it is pretty much all we have.

[johnmeyer]

How much (length) of a sample would be best? Taking file size into consideration. The sample scan they sent me was approximately 10 minutes. I would assume you would only need 10, 15 seconds worth?5-10 seconds, preferably something with motion (i.e., static shots of a building are not as useful as something where people are walking or cars are driving by, etc.).

[Bruce/Fl]

This should be about 6 seconds of my sample. Here is the link. I used Vegas, rendered it as .m2ts

https://www.dropbox.com/s/wpgso9p8awqi3gq/Upload.m2ts?dl=0

[johnmeyer]

Wow, that is really grainy. As a result, any attempt to use VideoFred's script will result in a fine mess because his scripts do quite a bit of sharpening. Sharpening grain, even after "degraining" is going to produce bad results. In fact, this is one of the main things that drove me to create my version of his script. If you click on the link below, you can see my post in his original film restoration thread -- complete with several images -- that shows the problems his original script created with my grainy footage:

The power of Avisynth: restoring old 8mm films (http://forum.doom9.org/showpost.php?p=1405197&postcount=208)

Also, when you actually do the work, make sure to work with the original MOV. This sample you uploaded has been recompressed using the Sony AVC codec, and there are a lot of additional artifacts added to the grain.

Finally, if this clip really accurately represents the original (i.e., you didn't screw up when you rendered it), then you need to decimate half the frames before you do any degraining. This is because the frames are all duplicated, and the degraining will choke when it sees zero motion between half of the frames.

Here is the script I just used on your clip. I frameserved it from Vegas, which is what I always do in order to avoid having to figure out how to read dozens of different formats into AVISynth. I let Vegas do that job because uses professional codecs that seldom glitch or fail. Note the "selecteven()" statement in the first line. This gets rid of every other frame, thus eliminating all the duplicates. The Assumefps statement gets you back to the correct playback speed.

So, you will need to replace the AVISource() statement with whatever you have found works for getting your MOV files into AVISynth. As I remember from our PMs last week, you did figure that out and got it working.

Hopefully other people will provide some additional ideas. I'm sure they will be glad to critique my work :)

source=AVISource("e:\fs.avi").selecteven()
super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
final=assumefps(15/1.001)
return final
#stackhorizontal (source,final)

[Bruce/Fl]

This sample you uploaded has been recompressed using the Sony AVC codec, and there are a lot of additional artifacts added to the grain.


Does anyone here know if Vegas can trim a .mov clip losslessly, or if not, what is the best option for rendering a .mov file? I tried the quicktime 7 (.mov) options, but even to my eye they looked very splotchy. (<---- ya, my word)

Or possibly some other program? I'd love for these samples I'm uploading to be simply shorter versions with the same quality as what I received.

Thank you,

Bruce

[johnmeyer]

Use Mediainfo or similar tool to find out what codec is used by the MOV file. Vegas may give this to you if your right-click on the media and select "properties."

In general, Vegas does not "smart render" (a.k.a., lossless cuts) most video. It can smart render DV AVI and some forms of MPEG-2, but that's about it.

Having said that, if the version of ProRes (I think that's what you said this is) does not do interframe compression, Vegas may well be able to render it losslessly.

It is easy to tell: just start the render and watch the preview screen in Vegas while rendering. If the video is not being re-rendered, the display will show "no compression needed."

Did my script work for you?

[Bruce/Fl]

Use Mediainfo or similar tool to find out what codec is used by the MOV file. Vegas may give this to you if your right-click on the media and select "properties."

In general, Vegas does not "smart render" (a.k.a., lossless cuts) most video. It can smart render DV AVI and some forms of MPEG-2, but that's about it.

Having said that, if the version of ProRes (I think that's what you said this is) does not do interframe compression, Vegas may well be able to render it losslessly.

It is easy to tell: just start the render and watch the preview screen in Vegas while rendering. If the video is not being re-rendered, the display will show "no compression needed."

Did my script work for you?

No, it said "Avisynth open failure, there is no function named "MSuper" "

I also linked it to a .avi render I did, so that it would work with what you gave me as written.

Attached are the media info screen caps from the original .mov and also my AVC render, just because.

This is because the frames are all duplicated, and the degraining will choke when it sees zero motion between half of the frames.

I was curious about this, after reading your explanation about how the degraining process worked, when I suspected that I did have duplicate frames. The reason I suspected that was, when I was trying to find the first frame of a scene in Vegas, using the frame advance button, it always seemed like I needed to click it twice to see any change in the image.

[johnmeyer]

No, it said "Avisynth open failure, there is no function named "MSuper" "You have to put the MVTools2 DLL in your AVISynth plugins folder.

[Bruce/Fl]

You have to put the MVTools2 DLL in your AVISynth plugins folder.

It is now in there, now it says: "MSuper: Clip must be YV12 or YUY2

Attached is the media info on the avi. It's huge, it's 4:2:2 and it says it's lossless.

I can probably uplaod it if you'd like to see it, better quality than the m2ts maybe?

[StainlessS]

Bruce/Fl,

You can just copy and paste MediaInfo text into post, click 'Go Advanced', and then select text and click on the Hash symbol above the post entry box, it can take a long time for attachments to clear approval.

You can see what colorspace Avisynth thinks clip is by pasting


Return Info.ConvertToRGB32

immediately after the line that loads the clip.

[raffriff42]

And here's some help for cutting down that huge source file. (http://forum.doom9.org/showthread.php?t=172557)

[Bruce/Fl]

And here's some help for cutting down that huge source file. (http://forum.doom9.org/showthread.php?t=172557)

That worked great, thank you so much for that.

Now I'll upload a few seconds of the original, for anyone wanting to see it un-reencoded.

Bruce

[Bruce/Fl]

Here is a sample in the original format, .mov


https://www.dropbox.com/s/2xk8v5r36en6hss/Sample8mm_1.mov?dl=0

[Bruce/Fl]

Bruce/Fl,

You can see what colorspace Avisynth thinks clip is by pasting


Return Info.ConvertToRGB32

immediately after the line that loads the clip.

I added it. Now it says, "I don't know what "info" means"

And just to be sure there are no mistakes I've made, here is what I have writtin:

source=AVISource("C:\Users\Bruce\Desktop\upload.avi").selecteven()
Return Info.ConvertToRGB32
super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
final=assumefps(15/1.001)
return final
#stackhorizontal (source,final)

[videoFred]

It is now in there, now it says: "MSuper: Clip must be YV12 or YUY2

Avisynth is telling you that MSuper requires YV12 or YUY2 colorspace. How to fix this? By changing color space from the input of cource.

Change your first line like this:
source=AVISource("C:\Users\Bruce\Desktop\upload.avi").selecteven().converttoYV12()


Fred.

[Bruce/Fl]

Avisynth is telling you that MSuper requires YV12 or YUY2 colorspace. How to fix this? By changing color space from the input of cource.

Change your first line like this:
source=AVISource("C:\Users\Bruce\Desktop\upload.avi").selecteven().converttoYV12()


Fred.

Thanks Fred, that got rid of the trouble boxes, and I have an image in virtualdub now. A very large image, but an image, and it moves, slowly.

Unfortunately I have to run now, but will return to this later today and see what I can do/see.

Again, thanks all.

Bruce

[Boulder]

Based on my experiences, you definitely want to preclean the clip you analyse motion from if the amount of noise or grain is extreme. I'd try FFT3DFilter or some of those NLMeans-type denoisers.

[StainlessS]

I added it. Now it says, "I don't know what "info" means"

And just to be sure there are no mistakes I've made, here is what I have writtin:

source=AVISource("C:\Users\Bruce\Desktop\upload.avi").selecteven()
Return Info.ConvertToRGB32


Arh, OK, you assigned clip to source variable, so I should have posted:

return source.info.ConvertToRGB32


instead.
I assumed that you have not assigned to any named variable and so would have been assigned to the special 'implied' Last clip variable.

What I originally posted was equivalent to this:

AVISource("C:\Users\Bruce\Desktop\upload.avi").selecteven() # Implied assignment to special Last variable.
return Last.info.ConvertToRGB32
# return info.ConvertToRGB32 # EDIT: Or use implied Last without explicit naming


JFYI.

[mawen1250]

About thSAD, from what I have read before(just a glance at the mvtools code):
It actually affacts the denoising strength of MDegrain, since MDegrain weighted average the matched blocks, and the weighting is calculated from SAD and thSAD. Thus, a higher thSAD results in dissimilar blocks to have larger weight, and it can increase denoising strength as well as introduce more blending artifacts.
As for MCompensate based denoising, thSAD might just be a threshold to determine bad matches.

[feisty2]

inline float DegrainWeight(double thSAD, double blockSAD) {
if (blockSAD >= thSAD)
return 0.f;

return float((thSAD - blockSAD) * (thSAD + blockSAD) * 256 / (thSAD * thSAD + blockSAD * blockSAD));
}



if (blockSAD >= thSAD)
return 0.f;

threshold

weight = 256 * (thSAD^2 - blockSAD^2) / (thSAD^2 + blockSAD^2)
you got thSAD at both multiplication and division part, who knows what will happen to the weight if you increase it, not doing a monotonicity determination of "y = (x^2 - a)/(x^2 + a)" here

[feisty2]

well... I just did it anyways, cuz that's just some 15 years old simple math
turns out "y' = 4ax / (x^2 + a)^2", and y' always > 0
so, guess mawen1250's right, you increase the weight by increasing thSAD

EDIT:
but that doesn't really matter, you know, it's an "x/x^4" kinda thing... it grows really, really, really, slow, yeah, you know what I mean....

[feisty2]

So, theoretically, thSAD affects the weight a little little little bit, but, practically, it's just a threshold of motion estimation

[Boulder]

Thsad is definitely the parameter to control the strength of the denoising. There's also the limit parameter that can be used to limit the amount of change.

Usually thsad=400 already results in quite heavy smoothing, but that naturally depends on the motion vectors of the analyse clip. If that clip is precleaned, you need to apply a lower thsad to get the same level of denoising.

[feisty2]

Well, it's a threshold, sure it would do something to the denoising result, larger thSAD=more blocks will join the average process
But it almost does nothing to the weight, so that's not what you call it, "strength"
No, not strength
It's the error tolerance of motion estimation

[raffriff42]

Will the debating never end? While waiting for a final answer from the smart people here,
I have cobbled together something around my old pal QTGMC that seems to work.
There is still room for improvement: it might be too flat overall, and little artifacts crawl around the edges.
But with such a high grain level, this is the 'best' result possible (...or is it?)

EDIT Boulder (post #46 (http://forum.doom9.org/showthread.php?p=1737268#post1737268)) has a point - in fact, I think I prefer to see the original grain, after all ...
but keep the cropping, speed and color correction.

EDIT I see an objectionable fixed, or semi-fixed, noise pattern with all degrain methods I've tried,
(DeGrainMedian, SMDegrain, MDegrain2, Deen, KNLMeansCL, even QTGMC) when set strong enough for this source.

So I overlayed a little of the unprocessed video, with all its graininess, to break up the fixed pattern.
The results are good IMHO - at least on the short sample.

https://www.dropbox.com/s/19jsxzmynl507kc/Degraining%20script%20assist%20Sample-frm79-crop-frm80-00-org.jpg?raw=1
input, cropped

https://www.dropbox.com/s/ck4mvkfmlufiwdv/Degraining%20script%20assist%20Sample-frm79-crop-QTGMC-10%20%2810%2B0-0.5d%29%2Blvls24.jpg?raw=1
It's hard to tell from a static image, but what you see now are "fast moving" dark specks
instead of "fixed" or "slowly swimming" noise. Here is the video (2.7 MB) (https://dl.dropboxusercontent.com/u/108089426/Video_temp/Sample8mm_1%7EQTGMC-12%20rsz2%20%283%2B0-0.4d%29%2Blvls24%2Bwb%20vx28.mp4)

# http://avisynth.nl/index.php/QTGMC
#Import("QTGMC\QTGMC-3.32.avsi")

# http://avisynth.nl/index.php/FFmpegSource
# http://avisynth.nl/index.php/LSMASHSource
FFVideoSource(sourcefile, enable10bithack=1>0)
#LSMASHVideoSource(sourcefile, format="YUV422P16", stacked=true)
## choose either source plugin

## eliminate repeating frames (new framerate 14.98)
SelectEven

## pillarboxes
Crop(240, 0, -240, 0)

## denoise in 10-bit & convert to 8-bit
## http://avisynth.nl/index.php/Dfttest
#dfttest(sigma=64.0, tbsize=1, lsb_in=true, lsb=false) ## (strong denoising)
dfttest(sigma=6.0, tbsize=1, lsb_in=true, lsb=false) ## (weak denoising)
ConvertToYV12

Overlay(
\ BilinearResize(Width/2, Height/2)
\ .QTGMC(InputType=1, Preset="Placebo", EZDenoise=3.0)
\ .Spline64Resize(Width, Height),
\ Last, opacity=0.4, mode="darken"
\ )

## raise gamma (for preview only - it's better to color-correct in your video editor)
#Levels(16, 1.55, 235, 16, 235)
## SmoothLevels looks noticeably better
# http://forum.doom9.org/showthread.php?t=154971
LoadPlugin("SmoothAdjust.dll")
SmoothLevels(20, 1.3, 210, 16, 235)

## playback speed too fast - adjust it by eye (for preview only)
AssumeFPS(11)

return Last

[Boulder]

Maybe so, but it basically is the thing you need to use to control the result.

The docs do mention that the blocks with lowest SAD have the highest weight.

EDIT: replying to feisty

[Boulder]

Out of interest:why degrain heavily? The grain makes the result appear sharper than it is.

[feisty2]

Maybe so, but it basically is the thing you need to use to control the result.

The docs do mention that the blocks with lowest SAD have the highest weight.

EDIT: replying to feisty

Block sad comes from the vector clip, a in the "y=(x^2-a)/(x^2+a)", we are talking about thSAD parameter of MDegrain, which is "x", not "a"

[Bruce/Fl]

Riffraff42, pretty cool to see it with some results. Thank you for looking into this also. To my eye, FWIW, it looks like too much grain was removed in this case, but cool to see that it can be affected in that way.

I'm curious as to why there is so much graininess. Until John Meyer finally got to see what I was working with and confirmed my thoughts about the grain being somewhat excessive, I kind of convinced myself that maybe it was just the nature of the beast, that when you blow up an image on a, in my case 23" diagonal monitor, and you are starting out with only an 8mm source, well, you're gonna see every flaw.

My father took the film, I was the 7 year old in the image, so I had no idea, and didn't even think about or care about the ISO of the film he used, or anything, he was simply taking movies to me.

So I wonder if it was the film selected, the initial processing, or maybe the lenses on the camera, which was some model of a Keystone.

He's not here to ask anymore, so I will just have to wonder.

[Bruce/Fl]

Now that I had a functional script, I was practicing working with Vegas, the frameserver, and getting it back when I noticed I needed VAPIConv to complete that process. So I downloaded it, read the tutorial here (http://www.doom9.org/index.html?/mpg/vfapi_reader_codec.htm) and as I tried to run "proxyoff.reg" from the VDub subfolder, it failed, saying "Cannot import C:\Users\xxx.............xxx\proxyoff.reg: Not all data was successfully written to the registry. Some keys are open to the system or other processes."

I wasn't sure if my having Virtual dub running, or any ot the other affiliated programs possibly running was messing with it, so I did a hard reboot, deleted everything VAPIConv related, and tried again with only chrome running to get the download again and read the tutorial. I got the same trouble message.

Anybody run into this before? I can't get VAPIConv to work properly without this successfully loading.

[raffriff42]

I'm curious as to why there is so much graininess...High speed film = no worries about lighting but tons of grain. N00b photographer's mistake (been there)

[Bruce/Fl]

High speed film = no worries about lighting but tons of grain. N00b photographer's mistake (been there)

Very possible, and I have no way of knowing. But I'd like to say *possibly not*, he did most of his shooting outdoors, and when he did bring out the camera inside for birthday parties or Christmas mornings he had a light bar with four big floodlights that could probably give you a sunburn pretty quickly. :D

But now that I am thinking about it, he did sometimes take movies indoors without without the big light bar, in large venues with good lights, for school plays and such, and also every year he would take movies of "Holiday on Ice" at the local arena. (similar to "Ice Capades")

Maybe he loaded up with higher speed film for those events, and just kept that roll in until used up, even if we were going to be doing something outdoors next, like the clip I loaded up here, on a vacation.

So yeah, very possibly.

[Bruce/Fl]

AS I was working with the script that was finally running, and getting set to play with the frameserver and work with it, in the back of my mind I was thinking "it would really be better to be doing this with a script that is set up to use a .mov source" (The one that is working is for .avi)

To save everyone from having to go back a page or two, here is the script that is presently working for me with a clip I rendered as .avi:

source=AVISource("C:\Users\Bruce\Desktop\upload.avi").selecteven().converttoYV12()
super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
final=assumefps(15/1.001)
return final
#stackhorizontal (source,final)

If I wanted to run this script, but with a .mov source file, do I switch out the line pointing to the source:

source=AVISource("C:\Users\Bruce\Desktop\upload.avi").selecteven().converttoYV12()

with:

source=LoadVFAPIPlugin("C:\Users\Bruce\Videos\Tools\AVISynth\plugins\QTReader.vfp", "QTReader").selecteven().converttoYV12()
QTReader("C:\Users\Bruce\Desktop\Sample8mm_1.mov")

or something different?

When I did the swap and ran it through virtual dub it gave me this error box:

"Avisynth open failure:
Script error:Invalid arguments to function "MSuper"
(C:\Users|xxxxx.....xxxx.avs, line 4)

[videoh]

LoadVFAPIPlugin("C:\Users\Bruce\Videos\Tools\AVISynth\plugins\QTReader.vfp", "QTReader")
source=QTReader("C:\Users\Bruce\Desktop\Sample8mm_1.mov").selecteven().converttoYV12()

[Bruce/Fl]

LoadVFAPIPlugin("C:\Users\Bruce\Videos\Tools\AVISynth\plugins\QTReader.vfp", "QTReader")
source=QTReader("C:\Users\Bruce\Desktop\Sample8mm_1.mov").selecteven().converttoYV12()

Thany you, that completed the script, and VirtualDub runs it, but the image is upsaide down! I wasn't expecting that. I'm sure there is a line to flip it back, (or unflip it), but I'm not smart enough to know what that is yet.

Anybody?

Here's what I now have:

LoadVFAPIPlugin("C:\Users\Bruce\Videos\Tools\AVISynth\plugins\QTReader.vfp", "QTReader")
source=QTReader("C:\Users\Bruce\Desktop\Sample8mm_1.mov").selecteven().converttoYV12()

super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
final=assumefps(15/1.001)
return final
#stackhorizontal (source,final)

[StainlessS]

LoadVFAPIPlugin("C:\Users\Bruce\Videos\Tools\AVISynth\plugins\QTReader.vfp", "QTReader")
source=QTReader("C:\Users\Bruce\Desktop\Sample8mm_1.mov").selecteven().converttoYV12()

super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
final=assumefps(15/1.001)
return final
#stackhorizontal (source,final)


Try below (untested)


LoadVFAPIPlugin("C:\Users\Bruce\Videos\Tools\AVISynth\plugins\QTReader.vfp", "QTReader")
source=QTReader("C:\Users\Bruce\Desktop\Sample8mm_1.mov")

source = source.selecteven().converttoYV12() # delayed, can above use whatever source reader to assign to 'source'.
source = source.FlipVertical() # comment out if not required

super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
final=assumefps(15/1.001)
return final
#stackhorizontal (source,final)

[Bruce/Fl]

Try below (untested)


That fixed it, thank you!

Now, as far as getting my sample run thru the frame server and back into a 2nd instance of Vegas, as per this tutorial from John Meyer:


https://www.youtube.com/watch?v=wVP8BQSV2Ak

When I try to install the VFAPI program, it won't load into the registry. The details of my attempts are about 6 posts up, post #49.

Any ideas?

[johnmeyer]

What version of Windows are you using? VFAPIConv is an old hack, and it may not work with newer versions of Windows, and will definitely have to be installed in the 32-bit section if you are using 64-bit Windows. I haven't tried that yet, so I can't give you any instructions based on experience.

[Bruce/Fl]

What version of Windows are you using? VFAPIConv is an old hack, and it may not work with newer versions of Windows, and will definitely have to be installed in the 32-bit section if you are using 64-bit Windows. I haven't tried that yet, so I can't give you any instructions based on experience.

Thank you John,

I'm on Windows 7 Pro. It's 64bit.

The pro version that I ahve has two separate Program Files, one tagged (x86) which is supposed to play nice with 32 bit programs. That is where I installed it, but it won't do that proxyoff.reg command for some reason.

I saw it when I watched your youtube totorial on AVISynth scripts. You mentioned that it's an old hack, is there a newer way to go about getting the workflow going in the same fashion?

[johnmeyer]

I'm on my Win7 Pro 64-bit system and tried to install VFAPIConv. I found a great post here in doom9.org which addressed the exact problem I was having, but my installation attempts still failed.

There are other, newer, AVS-->AVI frameservers available, but I haven't used them, so I can't help you with that. If you Google VFAPI or VFAPIConv, you should be able to find references to some of these.

[johnmeyer]

Here's the link to the VFAPIConv installation instructions for Windows 7. I followed them exactly, but couldn't get it to work on Windows 7 Pro 64-bit:

VFAPI and Windows 7 Problems (http://forum.doom9.org/showthread.php?p=1454837#post1454837)

[Bruce/Fl]

Here's the link to the VFAPIConv installation instructions for Windows 7. I followed them exactly, but couldn't get it to work on Windows 7 Pro 64-bit:

VFAPI and Windows 7 Problems (http://forum.doom9.org/showthread.php?p=1454837#post1454837)

Thanks John,

I was able to do everything it asked for, and just like your results, it still don't work.

I'm now looking for work-arounds, or other programs that will serve the same function.

Bruce

[creaothceann]

You could try WinXP on VirtualBox. (Disabling/disconnecting the network adapter also means you can skip hours of installing updates.)

With all features enabled (like 2+GB RAM, I/O APIC disabled, all "green" cores, etc.) it might run almost as fast as the host machine.

[Boulder]

I just took a little look at the source, and I would definitely leave quite a lot of the grain intact. It's part of the picture, and when you remove it, you are removing details as well.

Having said that, this is what I quickly composed from parts of my denoiser made of out stol..borrowed spaghetti code:


FFVideoSource("sample8mm_1.mov",colorspace="yv12")
SelectEven()
Crop(248,0,-248,-0)
Denoiser(limit=3, thsad=200)

function Denoiser(clip c, int "limit", int "thsad", int "thscd1", int "thscd2", bool "debug", bool "predenoise")
{
limit = default(limit, 5)
thsad = default(thsad, 200)
thscd1 = default(thscd1, 400)
thscd2 = default(thscd2, 100)
debug = default(debug, false)
predenoise = default(predenoise, true)

# denoise the video fed to create the super clip
predenoise ? Eval("""
w = c.Width()
h = c.Height()
superclip=c.RemoveGrain(12,12).GaussResize(w,h, 0,0, w+0.0001,h+0.0001, p=2).MergeLuma(c, 0.1)
""") : NOP()

# create the super clips, one for analysis, one for degraining
superanalyse = (predenoise) ? superclip.MSuper(pel=2,rfilter=4) : c.MSuper(pel=2,rfilter=4)
supermdg = c.MSuper(pel=2,rfilter=4,levels=1)

# create the vector clips
bv1 = superanalyse.MAnalyse(isb=true,delta=1,blksize=16,overlap=8,search=5,searchparam=4,pelsearch=3,dct=5)
fv1 = superanalyse.MAnalyse(isb=false,delta=1,blksize=16,overlap=8,search=5,searchparam=4,pelsearch=3,dct=5)

# recalculate
bv1 = superanalyse.MRecalculate(bv1,thsad=100,blksize=8,overlap=4,search=3,searchparam=4)
fv1 = superanalyse.MRecalculate(fv1,thsad=100,blksize=8,overlap=4,search=3,searchparam=4)

# recalculate again
bv1 = superanalyse.MRecalculate(bv1,thsad=100,blksize=4,overlap=2,search=3,searchparam=4)
fv1 = superanalyse.MRecalculate(fv1,thsad=100,blksize=4,overlap=2,search=3,searchparam=4)

result = (debug == true) ? MShow(superanalyse,fv1,showsad=true) : MDegrain1(c,supermdg,bv1,fv1,thsad=thsad,limit=limit,thscd1=thscd1,thscd2=thscd2)

return result
}

I don't know if it makes any sense but feel free to try :)

You can use the predenoise parameter to see how much the predenoising of the analysis clip affects the result. Limit controls the maximum amount of change and thsad is..well..thsad.

Use the debug parameter to see the forward vectors and to determine the thscd1 and thscd2 parameters - you can see the average SAD (thscd1) and amount of bad blocks (thscd2) in the upper left corner - those values need to be set according to the source. With a noisy and shaky video, you can ruin the MDegrain output because many false scene changes are detected!

And of course, you need some color correction but that is definitely out of my league :)

[Reel.Deel]

@ Bruce/Fl

Save yourself the headache and forget about old deprecated software from 2002. The current way to create a fake avi that Vegas can read is to use AVFS (Avisynth Virtual File System) (http://www.turtlewar.org/avfs/). Very easy to install and also works very well. Of couse there's always the option to save to a lossless avi using UTVideo (http://www.videohelp.com/software/Ut-Video-Codec-Suite) or another lossless codec of your choice.

I see you're still using QTReader, here's using LSMASHvideo source, same source filter I recommended in post #4 (http://forum.doom9.org/showthread.php?t=172553#post1736980).
The following method will open the video in it's native colorspace 4:2:2 (YV16), if you want YV12 output use format="YUV420P8" or use ConvertToYV12() (http://avisynth.nl/index.php/Convert) after. MVTools only works with YV12 and YUY2 (planar YUY2 hack also but where not touching that), if you want YUY2 use ConvertToYUY2() after the source filter to losslessly convert YV16 to YUY2.

LSMASHVideoSource("Sample8mm_1.mov", format="YUV422P8")

If you want high bit depth output use this:
LSMASHVideoSource("Sample8mm_1.mov", format="YUV422P16", stacked=true)

To dither it back down to 8-bit you can use DitherPost() from Dither (http://forum.doom9.org/showpost.php?p=1386559) just like raffriff42 has already shown.

[raffriff42]

you can use DitherPost() from Dither (http://forum.doom9.org/showpost.php?p=1386559) just like raffriff42 has already shown.Whoops, I deleted that post, as it was at right angles to what was being discussed (frameserving to Vegas).
Anyway, now I think dffest (http://avisynth.nl/index.php/Dfttest)might be better for this video, as it does a little denoising in 10-bit before dithering to 8-bitdfttest(lsb_in=true, lsb=false).ConvertToYV12



EDIT
And now I notice something -the frames do not repeat exactly: for example, frame 61 is almost identical to frame 60, but with a subtle shift...
EDIT
No, dfttest artifact, sorry...

[johnmeyer]

You could try WinXP on VirtualBox. (Disabling/disconnecting the network adapter also means you can skip hours of installing updates.)Good idea. I have almost never used the WinXP emulator that I bought with my Windows 7 laptop. I expect that would work perfectly.

[Bruce/Fl]

This will probably be a little bit of everywhere, so I apologize ahead of time.

I gave up on VFAPI, at least for now, and am trying AVFS. It's not playing nice, so I just put a post in with details over there in the AVFS thread (http://forum.doom9.org/showthread.php?t=133313).



So I thought I'd step back for a second and look at/spell out what I hope to accomplish. Maybe someone here will see that I need to go a different direction than what I think I need to do at present.

To recap, I am having some old regular 8mm home movies transferred to files, in this case, ProRes422 .mov files.

My present plan of attack is to load them in Vegas, do what I can with them there (stuff Vegas does easily) them frame serve them out, through a program where I can apply the avisynth scripts to them, and then run them back into another instance of Vegas for the final rendering.

All of the serious video work I've done previously has been strictly with Vegas, so all of this avisynth magic is totally brand new and foreign to me, and the scripting language is even more so. But I'm trying to pick it up. I hope I don't frustrate too many people as I go along with what are probably not the greatest questions. I'm also very thankful for everyone here who has taken an interest, showed patience, and tried to help me out also, by the way. This is a great community.

Back on topic. My main hope is to then get these finished files usable for myself to view, either on BluRay or possibly even just as a file that I can play on my HTPC and send to my Panny Plasma. (I'm for some reason naturally wired into thinking something on a disc is better) Additionally, I need to get these files onto DVD's for others in my family who haven't kept up on home theater as much as most people.

And I want to do all of that in whatever way introduces the least amount of format (format may not be the right word, but I'm sure you get my meaning) changes, or any other actions that introduce artifacts, or degrades the picture in a negative way, the limits of the storage media notwithstanding.

Having read that, anybody have any idea what form my final renderings will/should take? AVI, mpeg, mp4, etc? Just curious.

Thank you

Bruce

[Boulder]

If you are planning on creating a DVD, you need to encode as MPEG-2 video (I'd expect Vegas to be able to handle this easily, if not, use HCEnc for very good quality) but for Blu-ray, you'll want to use x264 with Blu-ray compatible parameters to encode to h.264.

In any case, you'll probably need to author the final disc image separately. I don't know if Vegas can do this for you. For DVD authoring, there are some freeware options available.

[creaothceann]

All of the serious video work I've done previously has been strictly with Vegas, so all of this avisynth magic is totally brand new and foreign to me, and the scripting language is even more so.

You can write and preview scripts easily in AvsPmod. Applications that can encode a video include VirtualDub (though it can only write AVI files, which is not ideal for h264 streams), x264 (the command-line program) and frontends like Handbrake (try this first).

Avisynth has a reference of the syntax and internal functions installed to your computer; there's also an online reference of external scripts and plugins (http://avisynth.nl/index.php/External_filters). The language is relatively easy to use with a bit of practise: open video and/or audio streams with source plugins and pass them through filter plugins.

[johnmeyer]

It sounds like you have everything more or less working except for the frameserving out of Vegas into and AVS script and then back into a second instance of Vegas via VFAPI. Rather than worry about all that frameserving, is would be a lot easier to simply render from Vegas to a good intermediate format like Cineform (free from the GoPro site). You can read that into an AVISynth script. Then, use the Cineform codec again to save from VirtualDub (which reads the AVISynth script). Yes, this involves two intermediate renders, which is a no-no, takes up space, and takes time. However, you are only doing this once, and Cineform was created specifically for doing this sort of thing, and the video actually holds up quite well.

[raffriff42]

Of course there's always the option to save to a lossless avi using UTVideo (http://www.videohelp.com/software/Ut-Video-Codec-Suite) or another lossless codec of your choice.Agreed; do it the easy way, with a lossless intermediate file. You [Bruce/Fl] could have been done by now.

Swinging back to degraining, here's a different approach. I can't say if it's "better," but it looks OK. Here's a video (https://dl.dropboxusercontent.com/u/108089426/Video_temp/sample8mm_1%7Edft64-slvls26%2C1.25%2Bwb%2Binter30F%2Baddg12%20vx28.mp4) (2.4 MB).

The basic idea is to overdo the degraining a little bit, convert to 30 fps (which needs doing at some point anyway) with InterFrame, then add grain to taste - grain helps perception of detail, and since the new grain is running at 30fps (vs. 12fps) it is less "strobey." As a bonus, compressibility seems improved.# http://avisynth.nl/index.php/FFmpegSource
# http://avisynth.nl/index.php/LSMASHSource
## (pick either source, they both work)
FFVideoSource(sourcefile, enable10bithack=1>0)
#LSMASHVideoSource(sourcefile, format="YUV422P16", stacked=true)

Crop(240, 0, -240, 0)
SelectEven

## convert to 8bit with noise reduction
# http://avisynth.nl/index.php/Dfttest
LoadPlugin("dfttest.dll")
dfttest(sigma=64.0, tbsize=1, lsb_in=true, lsb=false) ## try sigma=6 to 64
ConvertToYV12

## optional color correction (CC is better done later, in your edit software)
# http://forum.doom9.org/showthread.php?t=154971
LoadPlugin("SmoothAdjust.dll")
SmoothLevels(26, 1.25, 210, 16, 235)
ColorYUV(off_u=-7, off_v=5)

## playback speed adjusted by eye (~75%)
AssumeFPS(12)

## 12fps -> 30fps
# http://forum.doom9.org/showpost.php?p=1486831&postcount=1
Import("InterFrame2.avsi")
InterFrame(Tuning="Film", NewNum=30, NewDen=1, cores=4) ## set cores per your CPU

## add grain (!)
# http://avisynth.org.ru/docs/english/externalfilters/addgrain.htm
LoadPlugin("AddGrainC.dll")
AddGrain(var=8, uvar=6, hcorr=0, vcorr=0) ## try var=6 to 12

## add silent audio
AudioDub(BlankClip(Last, channels=2, audio_rate=48000, sample_type="16bit"))
return Last

[Reel.Deel]

Using this "multilevel denoising (http://forum.doom9.org/showthread.php?t=161848#post1512464)" technique with some experimental modifications I was able to get results similar to this: http://diff.pics/GyfvZIUrFaI5/1
It works well on static areas but can be a bit harsh in fast motion areas. I might tweak the script to use the "luma rebuild (http://forum.doom9.org/showthread.php?t=153589&page=19#post1548318)" technique on the motion search clips (can help retain some detail in the darker areas) and also try to limit the denoising strength on fast motion areas. Might not hurt to do some levels adjustments before denoising also. If anyone has any ideas on how to further improve the script please share :).

[Bruce/Fl]

riffraff42 and Reel.Deel, those both look good to my eyes. The severity of the grain has been reduced, but it doesn't look too washed out. To my eyes, it has cleaned up some of the smaller details (like the rails on the pontoon boat in the background) and made them more precise.

Now once I figure out the best way for me to work with these scripts easily I'll be rolling. I've got AVFS downloaded and I'm trying to make it work out, I snagged the GoPro Cineform suite. I grabbed the UTVideo codecs. It's starting to overwhelm me some, but I'm working on all of it at various times. Thanks again to all.

Bruce

[Bruce/Fl]

OK, I have a flow going, and I even kind of understand the process. The details of everything happening in the script, not so much.

I like the idea of working off of the Vegas timeline, as different scenes in my clips might require different tweaks, or maybe even none at all. So that pretty much dictates using a frame server.

So what I have going now is: (I only used a single clip, a long clip, but just a single) I am using the script that John Meyer posted back in post #23, as it was the first one I got working, and it seems simpler looking at it, compared to some of the others here. Once I get a better grasp on things I can look at the others.

1. Put mov clip on Vegas timeline
2. Render to frameserver.
3. Run AVSF loading up the script (I'll post the script below) pulling the avi file from the frameserver signpost.
4. Load up a 2nd instance of Vegas, importing the AVSF processed avi file from the "Volumes" folder, where it was sent
5. Render in Vegas as AVI

Here is the script once again:

source=AVISource("C:\Users\Bruce\Desktop\fs.avi").selecteven()
super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
final=assumefps(15/1.001)
return final
#stackhorizontal (source,final)

Now, some questions.

I put my whole 9 minute sample that I have into it. It came in at 13 Gb, but then that file after frameserving, running the avs script and doing a final render comes in at a whopping 65 Gb. Is that normal?

Also, it seems sluggish to play. I tried it in media player, media player classic, and VLC player.
Additionally, when played, on scenes with even somewhat fast motion the frames seem to separate, I get two images with visible interlacing lines. (Theres probably a name for what I'm seeing, but I can't come up with it)

Is the size, and/or the sluggishness due to something that was overlooked in the script?
Is it because of my selecting to go with an avi file? I did that due to the frameserver defaulting to avi. I was trying to keep from rendering across codecs or whatever.
The rendering option I selected for the final rendering in Vegas was, under the avi section, "HD 1080-60i YUV" That is the one which appeared to best represent what I was feeding it.

Did I make some bad moves? Is there something missing? Is the file growing in size like that normal?

It looks like I have some answers, but have more questions.

Thank you

Bruce

[Boulder]

The problem probably is that Vegas will make a weird framerate conversion of 14.985p --> 60i fps which will create those artifacts.

[johnmeyer]

I put my whole 9 minute sample that I have into it. It came in at 13 Gb, but then that file after frameserving, running the avs script and doing a final render comes in at a whopping 65 Gb. Is that normal?The size of the output file depends on the bitrate, and nothing else. If you use a higher bitrate than was used in the original file, it will be larger. The 60i YUV output codec you chose was the wrong choice, although I can't recommend the "right" choice because I don't know what you want to do with the video that you output from Vegas. Is it the final output that you want to save and view for the rest of your life, or is it a stepping stone to something else?

If it is the final output, what are you going to play it on? DVD player? BluRay player? Memory stick inserted into a TV's USB port? Upload to YouTube? Something else? Each of these requires you to use a different codec for the render out of Vegas.

Also, it seems sluggish to play. I tried it in media player, media player classic, and VLC player. That could be due to one of several things, or perhaps more than one thing. You've created a very large file, and if your hard drive isn't up to the task, it won't be able to output the file fast enough to keep up with the video speed. Also, some media players aren't very efficient at decoding video from some codecs (you used a YUV codec). Your computer CPU may not be able to keep up. For the moment, that is the least of your problems, and I wouldn't pay any attention to it until you get the other things worked out.

Additionally, when played, on scenes with even somewhat fast motion the frames seem to separate, I get two images with visible interlacing lines.First of all, you may not need to render to 60i, unless you are trying to create a DVD or BluRay. For rendering to memory stick, or uploading to YouTube, and for other work, you want to keep the frame rate at 14.985, the rate created by the final statement in your AVISynth script. However, if you render to 60i, then you need to give Vegas the correct "instructions" so that it renders the video the way you want. If you do nothing, Vegas will blend fields together to create all the intermediate fields that are necessary to go from 15 progressive frames per second to 60 fields per second. This produces smooth motion, but your video will look soft (because of the blended fields), and if you freeze frame, you will certainly see interlaced offset fields on some frames, although this is normal for interlaced video and there is nothing wrong with this, and it will look fine when the video is played at normal speed.

The best way to render amateur film footage from Vegas (which I do almost every day) is to disable resample for all events (you can find Vegas scripts that do this in one click for all events). By doing this, you tell Vegas to simply duplicate fields in order to get the additional fields needed to make the fps conversion without altering the playback speed. The output will be very sharp, although any horizontal motion will show judder. That judder is simply the breakdown of the "persistence of vision" in the human brain when viewing low frame rate material. That is just the way it is.

Is the size, and/or the sluggishness due to something that was overlooked in the script?No, it has nothing to do with your AVISynth script.

[Bruce/Fl]

The size of the output file depends on the bitrate, and nothing else. If you use a higher bitrate than was used in the original file, it will be larger. The 60i YUV output codec you chose was the wrong choice, although I can't recommend the "right" choice because I don't know what you want to do with the video that you output from Vegas. Is it the final output that you want to save and view for the rest of your life, or is it a stepping stone to something else?

I guess at this point it is a stepping stone. But how long it will be that is dependent on new technologies, ideas, formats, etc. I'm of course keeping the raw files that I get from cinepost, as a set of "master" recordings, so to speak, along with the film stock. If some new better way of doing things come along, I can bring them back out and use them in it. Well, hopefully at least.

If it is the final output, what are you going to play it on? DVD player? BluRay player? Memory stick inserted into a TV's USB port? Upload to YouTube? Something else? Each of these requires you to use a different codec for the render out of Vegas.

Two fold answer. For myself, I want to be able to display the best quality I can on my home theater. Which presently is a 65" Panny Plasma. Whether that is through a BluRay, a memory stick, or some other way, I simply want it to look as good as it can. I'm flexible. For Blu, I have a Pioneer Elite, and a PS3, just FYI.

The second part of that answer is, I need to also make some plain DVD's ("plain", as in not BluRay) for my relatives who are not as dedicated to home theater. (Or technophobes, like my sister). So I assume having two suggestions would be ideal here, one for my use, and one to make the best DVD's for others.

Youtube isn't really a consideration at this point.

That could be due to one of several things, or perhaps more than one thing. You've created a very large file, and if your hard drive isn't up to the task, it won't be able to output the file fast enough to keep up with the video speed. Also, some media players aren't very efficient at decoding video from some codecs (you used a YUV codec). Your computer CPU may not be able to keep up. For the moment, that is the least of your problems, and I wouldn't pay any attention to it until you get the other things worked out.

I will put it on disregard until further notice.

First of all, you may not need to render to 60i, unless you are trying to create a DVD or BluRay. For rendering to memory stick, or uploading to YouTube, and for other work, you want to keep the frame rate at 14.985, the rate created by the final statement in your AVISynth script. However, if you render to 60i, then you need to give Vegas the correct "instructions" so that it renders the video the way you want. If you do nothing, Vegas will blend fields together to create all the intermediate fields that are necessary to go from 15 progressive frames per second to 60 fields per second. This produces smooth motion, but your video will look soft (because of the blended fields), and if you freeze frame, you will certainly see interlaced offset fields on some frames, although this is normal for interlaced video and there is nothing wrong with this, and it will look fine when the video is played at normal speed.

Well, DVD is definitely in my plans, and possibly BluRay, so I guess this is in play, at least for part of my goals.

The best way to render amateur film footage from Vegas (which I do almost every day) is to disable resample for all events (you can find Vegas scripts that do this in one click for all events). By doing this, you tell Vegas to simply duplicate fields in order to get the additional fields needed to make the fps conversion without altering the playback speed. The output will be very sharp, although any horizontal motion will show judder. That judder is simply the breakdown of the "persistence of vision" in the human brain when viewing low frame rate material. That is just the way it is.

I have selected that option from the switch, and am re-rendering now, to see what difference it makes.

No, it has nothing to do with your AVISynth script.

Cool, thank you John.

[johnmeyer]

For DVD, render out of Vegas using the MPEG-2 option, and the "DVD Architect NTSC video stream" template.

For BluRay, render out of Vegas using the MPEG-2 option, and the "Blu-ray 1920x1080-60i, 25 Mbps video stream" template.

While you can obviously play the BluRay on the big TV (that's what it's for!), you might get better quality for this "oddball" material (i.e., not normal sound film or video fps) by rendering to a memory stick at the native speed.

That phrase "native speed" brings me to a VERY important point. In the script I gave to you, I got rid of the duplicate frames through the selecteven() statement, but I set the video to play at a speed of 15 fps (14.985). This is a nifty speed because Vegas can get it back up to 29.97 fps for DVD or BluRay simply by duplicating each frame, which is what your transfer service did. The problem, however, is that the original film may not have been shot at that speed. While sound film has almost always been shot at 24 fps, and Super 8 film is always 18 fps, there has never been a standard for silent 16mm or silent 8mm film. I have seen silent amateur film frame rates as low as 12 fps (actually even lower, but the result was too jerky to play it at 10 fps) and as high as 24 fps (my 1960s high school football team games films). If there happens to be a clock with a sweep second hand in the background, or if you can track some law of physics, like a ball dropping from a known height, you can nail the speed exactly. Absent something like that, you just have to use your judgement as to what speed to set for playback.

So, before you get too far with this, you ought to look critically at a few minutes of film from your transfers and judge whether the playback speed is correct. If not, you can change the number in the AssumeFPS statement in your script. That statement works exactly like the speed knob on a film projector: turn it up (higher numbers) to make the film play back faster. Like the film projector running at a faster speed, no frames of film are thrown on the floor; they just run through the projector faster. This is in contrast to the Selecteven() statement which actually does throw half the frames away (which were duplicate frames in your film) which, if the playback speed is not adjusted, will result in the video appearing to play at twice normal speed.

I just re-watched your short clip of the kids running to the end of the pier, and the playback speed actually looks about right to me. That is somewhat surprising because, judging by the clothes and the vintage of the outboard motor, this couldn't have been taken any earlier than the mid-1960s, and most 8mm cameras at that point were filming at 16 fps.

BTW, speaking of the outboard motor (a Johnson?) that looks like a Lakeland float boat. I just sold mine two months ago. I think my uncle purchased it around 1963.

[raffriff42]

Very good discussion of speed issues - although I still think the clip needs slowing to 75% (from 14.985 to around 12)

The problem probably is that Vegas will make a weird framerate conversion of 14.985p --> 60i fps which will create those artifacts.Absolutely; proper conversion is vital, as I hinted at when I said:convert to 30 fps (which needs doing at some point anyway) with InterFrame...Interframe will do a much better job of framerate conversion than Vegas will - at least in this case.


Re frameserving etc, you seem to be ignoring the easy solution.Of course there's always the option to save to a lossless avi using UTVideo (http://www.videohelp.com/software/Ut-Video-Codec-Suite) or another lossless codec of your choice.This is very reliable, and fast.

[johnmeyer]

:Interframe will do a much better job of framerate conversion than Vegas will - at least in this case.
This is an interesting point. Many people who use VideoFred's film restoration script use motion estimation to synthesize the intermediate frames. Interframe is the front end to SVP which in turn is a GPU verison of MVTools. They all do basically the same thing, but with different plumbing underneath, and different dials to twiddle.

Interframe is like the girl in the old Longfellow poem: "when she was good, she was very, very good; but when she was bad, she was horrid." When using motion estimation to create the intermediate frames, the results can be stunning, and definitely better than Vegas' frame blending approach. However, when motion estimation fails, it fails spectacularly, creating monstrous morphs, broken legs, and other obvious anomalies.

I did not include motion estimation code in my version of VidoeFred's scripts, because I got burned too many times. However, I do use it on some film that I upload to YouTube because YouTube's conversion process seems to emphsize the judder when low framerate video is panned horizontally.

Here's some film I uploaded to YouTube last month. I used motion estimation to increase the frame rate from 14.985 to 29.97, just like we're discussing here:

1941 Flint Michigan Parade (https://www.youtube.com/watch?v=t8HjRN0rw5M)

Watch people as they appear behind the floats. Watch the batons as they are twirled. And worst of all, go to about the 1:35 mark and watch the antlers on the stuffed moose. They totally break on each synthesized frame. I've tried all the settings, and this simply cannot be prevented.

So, you have three choices: use pulldown (duplicated fields); blend fields (Vegas); or use Interframe to motion estimate the new frames. The first way is how it has been done since the beginning of time. It produces clear sharp results, but you will get judder on horizontal pans, and your mind will sense a slight unevenness for some pulldown cadences (not for this case where you are simply duplicating all frames). The Vegas approach produces video that looks "soft" because the new frames are simply blends of adjacent frames. However, it never, ever produces surprises. I've already described the final approach which, when it works, is absolutely spectacular, but when it fails, it can be pretty nasty.

When I'm doing really critical work, I combine the two approaches. I'll render video using either #1 or #2, and also render using #3 (e.g., Interframe). I'll use #3 as my "preferred" video, but when I see a place where it breaks down, I'll cut to my other render.

Best of both worlds, but a lot of work.

[Bruce/Fl]

At work, posting from my phone..... If it can be easily explained, what's the process utilizing UTVideo? I downloaded it, but haven't done anything with it yet, was busy trying to get the frame server process figured out.

Thank you

[raffriff42]

Interframe is like the girl in the old Longfellow poem: "when she was good, she was very, very good; but when she was bad, she was horrid."Ahh, so true; glad you mentioned it. Interframe and its relatives are not things you set and forget, they require close watching! Tuning="smooth" is especially dangerous that way.