message deleted by request

Thank you John -IMPRESSIVE indeed!

I notice the:

LanczosResize(720,576)

I was reading the advice about using: "The result is that Lanczos4Resize produces sharper images. Especially useful when " and as this is resizing upwards, wouldn't availing the script with this alternative syntax be beneficial?

And here is my ignorance showing, why is there the difference between what the "comment" says " . . from a 640x480 still camera into 768x576 . . " But the script has the 720 revealed in the "comment" LanczosResize(720,576)? Why the difference?

Great work John!

Grazie

So that there is no ambiguity it was I that requested John remove the links. This is work in progress.

John, thank you for complying with my request. You are a gent!

Grazie

@John...

I am not good at AviSynth, at all, but I was wondering if you've tried to inset the MT filter set-up into this at all?.. if it works etc & your experiences? Any hints on MVTools v.1 vs. 2?

A bit O/T, I'm surprised no one has tried to emulate the old wave theory stuff in software... Now I barely understand even the basics, but from what I *think* I understand, using wave theory it's possible to construct missing frames rather than estimate them, though in this case (MVTool) the estimation is quite good. A basic analogy would be the dithering process they use converting 48 to 44.1 audio -- since the actual audio signal is a waveform (albeit a digital representation), reconstruct the waveform from the digital & sample it somewhere else, using the different frequency.

Of course we think of digital video as more binary than analog, but it's after all the evolution of sampling signal waveforms. The same process of sampling those waveforms I'd think would work in reverse, then just express the relevant parts of wave theory math in code. 'Course in ignorance I'm probably being terribly naive -- just don't see the math being any harder than what they're doing right now with MVTool.

"I'm surprised no one has tried to emulate the old wave theory stuff in software... "

That concept is used. Dithering has nothing to do with however. Dithering is simply adding one kind of noise to mask another, it's not used in sample rate conversion, it's used during bit depth reduction.

Where waves are used is in trying to estimate where the pixels might have moved, various curves are tried to find a 'fit' for how the objects might have moved between samples (actual frames).
There's a massive disconnect though between how things work in audio and video.
With sound assume the limits of hearing as 20KHz. We sample the sound pressure at a point in space 44,1000 or 48,0000 times per second i.e. more than double the Nyquist limit. Simple interpolation works very well to determine what the original sound pressure was between real samples.
With vision the limits of human motion perception is thought to be around 400fps, the highest frame rate in common video cameras is 60ps but yet to get the same accuracy with video as we have with audio we'd need to be recording around 1,000fps.

Bob.

Astounding . . . we have some truly amazing talent here on this Forum . .

OK, what am I doing now . . well, I thank John Meyer for his patience and truly elegant approach, however my brain cell is quaking 'n quivering at the the thought of AviSynth and the filters. I have now Frameserved outta VP9 into a PAL 25fps Vegas5 project, render that and the results are quite excellent.

Also, I have to say, using straight cut and mpeg2 (MC) and playing on my SONY DVD Upscaler to the 40" BRAVIA is very acceptable indeed. Now, I have no way of "checking" any of the fidelity, other than my pair of eyes, but it is pretty darn good.

I'm just wondering that through this whole process is the framerate being ironed out? Is my brain becoming accustomed to what I'm seeing? OR, is this a process that has borne fruit? Of course I am hoping for the latter!

Thanks guys, esp Mr John Meyer and Bob, for all your input.

Grazie

"I have now Frameserved outta VP9 into a PAL 25fps Vegas5 project, render that and the results are quite excellent."

Why the frameserving, why not simply render / encode directly?


"I'm just wondering that through this whole process is the framerate being ironed out? Is my brain becoming accustomed to what I'm seeing? OR, is this a process that has borne fruit? Of course I am hoping for the latter!"

I can't see anyway in which this process has borne any fruit, sorry. There's no escaping the simple fact that the camera recorded an image 30 times per second and you want images recorded at 25 frames per second. This means that at some points in time as something moves in the frame you do not have a record of it therefore it has to be invented.

It might help to take this to a somewhat absurdly extreme example.
One could take an picture of a sunset with a still camera once per minute and you'd have a fairly accurate record of the event, the world doesn't turn very fast. We actually did this decades ago. We projected the 35mm slides using two projectors and did very slow dissolves (using the motor driven iris in the projectors and crude automation) between the two projectors. The result was an entirely natural looking sunset, you'd swear it was 35mm film shot and projected as 24fps.

The artists involved wanted to make a VHS of the show so we recorded the screen to 1" tape and made VHS dubs, still looked perfect. Well maybe not, but that was because of the huge difference in latitude between film and video.

There's a very real problem though with what we did. If a bird flew through the frame while the shutter was closed it would have never been seen. Maybe not a big deal. If a plane far off flew through the scene we have a real problem. The viewer would see the plane in one position and then it'd slowly vanish from that position and appear further across the frame. In fact at the 30second mark the viewer would see two images of the plane some distance apart but both dim. Our little trick would have been exposed and the result rather unsettling.

This is what Vegas is doing. Of course you have 30fps not 1 frame per minute but the same sort of thing is going on. Doing a 30fps to 25fps conversion is quite likely to yield reasonable results most of the time or not, it depends.

The issue that can arise is beats/harmonics in how motion appears. A certain number of time per second the 30fps camera will have recorded an image at exactly the same time as a 25fps camera and no interpolation is needed. This can create a rather strange juddery feel to the outcome, it depends. If nothing is moving quickly the result is going to be perfect. If something is moving very quickly it'll be obscured by the motion blur anyway or simply have never been recorded if it was travelling really fast. But some things moving at just the right speed will make the problem quite obvious. All this is much like my sunset, bird and plane above.

This probably explains why some of us think the simple interpolation that Vegas does is great and others think it stinks. Both are right because it depends on the content and motion within the frame.

What MVtools and the like is trying to do is work out where that plane was moving and put in into each frame at the right place. Note though it cannot find the missing bird at all, no record exists of it.

Anyways that was the long winded simplistic answer. The short answer is if looks fine then it is fine. Just bear in mind as I (hopefully) explained there are potential gottchas in this process. For example a panning shot with just the wrong panning rate could go really wierd. A scene with cars driving through the frame at differing speeds might show just one of the cars looking wierd. Certainly if you plan to use this method then locked off shots on a tripod would be recommend. If you want to pan or zoom then do it real slow.

Bob.

Of course you are correct in what you say, Bob. And I really appreciate your going to such lengths so that I don't pull my OWN wool over my eyes - I accepts ALL of that - I really do. Maybe I am lucky in as much as I don't pan much, and if so, I do it slowly. PLUS fast movement isn't flowy enough - I agree. But I DO have a female drummer with much flowing hair and the hair is swaying rather nicely and smoothly.

No, I will not "blind" myself to the actuality of the maths that HAS to be going on. It could very well be that my filming technique has somehow provided/allowed for "better" outcomes/results. Your, "The short answer is if looks fine then it is fine." I accept. And NO this doesn't mean I have jetisoned the actual maths that blatantly needs to happen to do the 30<>25 shuffle.

Why the Frameserver Tango? 'Cos I can, AND I wanted to see if there were any advantages in the process.

Grazie

"Dithering has nothing to do with however. Dithering is simply adding one kind of noise to mask another"

I'm sorry Bob, kind of thinking/writing out loud rather than paying good attention to what I was putting down. I believe the dithering you're talking about is for reducing word clock, dumping the extra bits between 16 & 24. The sample rate OTOH is basically a bunch of static measurements along the wave... 44.1 thousands per sec vs something like 48K, or 96K. I believe when you're converting sample rates or frequencies, a good dithering process tries to redraw the wave, using the sample values to plot a curved graph, & then remeasure or re-sample along that drawn curve. Or at least I believe that's something Sony marketing came out with at one time or another to promote Sound Forge. ;-)

At any rate, I should have been more specific... Dithering is used quite a few places, many of which I dare not mention. ;?P

If you're interested, they've got some of the old Snell & Wilcox docs up here: http://www.media-matters.net/resources.html, & I think one or two might talk about how they applied wave theory to broadcast signals, & I imagine used that as the basis for their famous NTSC <-> PAL hardware. While we're talking digital, I thought maybe the old math might still apply, to in essence draw a curve touching the sampled points, then remeasure the curve, re-digitizing it.