if the clip had DV dimensions, it would use the Main Concept DV codec, if it had HDV dimensions it would use the Cineform codec, and if it was neither of these, it would pass the file back uncompressed. Is that a good idea?

VERY sharp observation. That's how I originally changed deamlx's script, and is why my script is constructed with those Switch/Case statements. But, I then realized that there are many instances where the clip has those dimensions, but isn't DV.

The big problem here is that the Vegas scripting language does not provide any access to rendering settings, other than to choose templates. This has been the most-discussed shortcoming over in the scripting forum since the day scripts first debuted back in version 5. The only way around it is to create a whole bunch of presets and have the user load those into their system. That's a big installation chore and clogs up the user's system. In addition, even with that, there is always some combination of settings that the user wants that the programmer won't have thought about.

By contrast, the uncompressed template always follows whatever the project settings are. I now just change the project settings, temporarily, to match the media for each event, and the template changes. The template IS actually set correctly for the PAL clips (lower field first, and the correct PAR). You can even set it manually and render a short clip, uncompressed, and then bring the result back into Vegas and, oh my gosh, the fields are reversed and the PAR is wrong (for widescreen). This is apparently a problem with ALL programs because they are following some strange industry convention. See this old post from this forum:

Old Post

... a wide-angle shot DeShaken has a subtle "warp wiggle" in the corners of the video ...

This is due to using edge compensation. If you run Deshaker manually, there are changes you can make to this, including turning it off, or letting Deshaker zoom in instead (losing resolution, although this is OK if deshaking HD footage for SD delivery), and other things. See my final comments below for more.

Since the audio on the Vegas timeline is still from the original clip, how would I turn the audio off on the clips being transferred back to Vegas from VirtualDub?

You don't have to. The audio from the deshaken clip is NOT transferred to the timeline (notice that there is no new take added to the audio).

I added lines that redefined the compression variable for cases where there are 480, 576 or 1080 lines

Way to go, Laurence. That is exactly how the script actually worked when I first started modifications, and I may change my own version back to work that way. However, as you discovered, there are lots of "gotchas" trying to match that up to the VirtualDub codec, especially since some of those codec settings are not available via the VirtualDub script and must be set via the codec dialog (they are remembered globally across all applications, and across application sessions). The beauty of the uncompressed template is that it is the ONLY template in Vegas, for any codec, that has its settings automatically follow the Vegas Project settings. Thus, by temporarily changing project settings (which you CAN do from the script), you can control the template settings, but just for uncompressed. That was my little "discovery" that allowed me to make this script run on multiple format video within the same project, and also work across any possible project. "Set it and forget it" was my goal.

I have been informed that to have VD to use MainConcept outside of the Vegas Uncompressed, then I'd need to purchase the MC codec?

No, Grazie, you don't have to buy anything unless you truly want to have a DV version of the deshaken video. In that case, you would need to purchase the MainConcept DV codec, whether you were using this script or not. There is a Panasonic DV codec available for free download. However, the problem you highlighted with PAL field reversal (and which is not a bug in the script, but apparently a very strange industry convention dating back to "the old days") is FIXED with the latest script, at least as long as you just use the deshaken video inside the VEG from which it was deshaken. If you need to use it elsewhere, you can use nested VEG files and you'll still be OK. If you need to use the raw AVI files, then you must manually change the field order and PAR for each, within the new Vegas project.

For others reading this, the problem only appears with PAL clips, and only when using the uncompressed codecs. If you are using NTSC, you will not have problems.

It needs an option for more zoom and less filling in edges from other frames for those cases where you need to use that approach.

Yes, this is why, in the latest script, if you read the comment lines, you will see that I keep saying "Need to replace these lines with a dialog box ..." The "right"way to do this script would be to create a faux Deshaker dialog, complete with all the settings, and have it appear within Vegas. You could set each and every one of the Deshaker parameters. This still would not be quite as flexible as doing it the old-fashioned "manual" way because you couldn't, for instance, try out several pass 2 settings without having to re-run pass 1, but it would still be pretty slick.

I have created complex dialogs in jscript and it is extremely time-consuming. Normally dialogs are easy to create, using any sort of tool, and I have all the Microsoft tools lying around here that a client gave me in a "payment-in-kind" exchange a few years ago. I know how to use them, but so far have not found anyone that has figured out how to take the dialog code and marry it up with jscript. The alternative is to do the whole thing in C#, but that is a learning curve that is WAY beyond anything I am going to attempt. As already pointed out, I got sucked into this thing way beyond what I expected, and I barely was able to complete a major deadline this week as a result and will have to scramble next week to catch up.

The template IS actually set correctly for the PAL clips (lower field first, and the correct PAR). You can even set it manually and render a short clip, uncompressed, and then bring the result back into Vegas and, oh my gosh, the fields are reversed and the PAR is wrong (for widescreen).

Yup, I found this 2 days back and reported it to John. Last night I sent the file over to John and has used my clip and confirmed this to be true.

Where do we go now - with an "industry standard"?

Almost in my grasp - huh?

Grazie

Grazie,

You are confusing me. Doesn't the new script fix your problem? I tested extensively last night, including frameserving the resulting deshaken images back out of Vegas into TMPGEnc, and then using its odd-even deinterlacer to check for field reversal (a neat trick, if you ever need to confirm field order or spot field reversal). It all worked here.

Did you download the latest script (which was uploaded while you were sleeping)? Is it not working there??

At least for me the latest version 0.7.1 works fine regarding pixel aspect ratio and field order. I noticed the values were reverted in the earlier version but I first thought I mabe had a certain file format defined that way before (I sometimes do so when working on certain projects).
Retested with 0.7.1. and in a widescreen project with widescreen files which are lower field first after deshaking each value keeps unchanged. Right the way I supposed it to be.

Marco

You are confusing me.

Well, the Script dated: 25 May 2007 timed at 20:56pm - IS producing 16:9 BUT also producing UPPER field first.

Are you saying you have a more recent script that produces LOWER field first?

Grazie

I'm glad for you Marco - good!

I just repeated the testing and, yes I have got 16x9 but the field order is stubbornly remaining at UFF, not LFF.

Just to repeat: Prior to executing the script I have the Project settings at 16x9; it displays as 16x9 and the Properties of the Media on the Timeline is confirmed as being 16x9.

Grazie

Well, the Script dated: 25 May 2007 timed at 20:56pm - IS producing 16:9 BUT also producing UPPER field first.

Did you download the new script from the link I gave in the earlier post? I specifically said that I had uploaded a new version while you were sleeping ...

The correct (newest) script starts out like this:

Vegas Deshake (version 0.7.1 beta)

written by David Arendt from Luxmemories Sarl

Homepage: http://www.luxmemories.lu



Modified (quite a bit) on May 25, 2007 by John Meyer



0.7.1 Now keeps the audio with the deshaken video. 

      Resets PAR to match input PAR (PAL uncompressed widescreen changes PAR to 4:3!)

      Resets field order (PAL uncompressed always reverses fields!)

      Provides error message if no event selected

SUCCESS . .and my most humble apologies!!

What did I do? - It is what I DIDN'T do . . and slept through the difference!!

I HAD downloaded an INTERIM JS update, but it wasn't until I went to the "other" updated thread by John - dated today! - and thence to the download site that I realized that I had missed the "overnight" uploads by John. I was reading here, but the updates I discovered on that other thread.

Me bad!!

.. and now . . I have the 16x9 AND the correct LFF.

JOHN, thanks for putting up with me!!

Best regards,

Graham "Grazie" Bernard

John, the WarpWiggle I'm refering to is not the edge-fill-in effect. I never use zoom because I want to maximize the resolution of the results, so rather than leave black moving edges as DeShaker does it's thing I choose to have DeShaker fill in, to the best of its ability, using 30 prior and post frames. Most of the time it's never noticed or covered by the 4% cookie cutter frame I put on all my finished stuff. Sometimes it's not, and then I go in and figure out how to tweak the parameters to mitigate the effect.

But the WarpWiggle effect is entirely different. DeShaker does the best job it can stabilizing the overall frame, but stuff maybe 75% from the center towards the corners sometimes has a breathing effect. I attribute this to the fact that wide-angle lenses can't quite keep things linear towards the extremes of the field of view, so when Deshaker applies the computed shift to the entire frame (field, actually) then the nonlinearity of the corners becomes apparent. It's always there under non-DeShaken conditions, but I guess our eyes automatically recognize that artifact and tune it out.

In any event one can minimize the effect by turning down the amount of DeShaking. I used values of 1000, 1000, 1000, and 0 (no zoom DeShaking) for my most recent project, and it still does a wonderful job of taking out most of the handheld shakiness.

John, the WarpWiggle I'm referring to is not the edge-fill-in effect

Ah, I didn't understand that. Yes, I know what you mean. If you (or anyone else) hasn't read the author's own notes on his product, go here:

Gunnar Thalin's Site

All of it is useful, although sometimes a little difficult to understand, which is why I wrote my guide several years ago. However, if you go near the bottom of that page, starting with the "Things to Think About" section, you may get a few ideas of settings you can use to minimize this problem.

Unfortunately, one of the things he says is: "Video with a high degree of barrel or pincussion distortion will not look good when deshaked. If you get a lot of distortion in your video, try avoiding the extreme zoom positions of your camcorder."

Of course, you'll have to do this with the manual usage of Deshaker, since my script really doesn't let you be interactive. I'm still trying to figure out how, without any real work, I can add a dialog. I can construct the dialog in MS Visual Studio in less than ten minutes, but can't figure out how to generate code that can be used in jscript. Others have said it is impossible, so ...

John, WOW! I had to read the entire thread twice, then realize I had to configure the VDub Video Compression to the VDub instance within your file rather than my standalone 1.7.0, and it works beautifully.

Thank you. This is a fabulous aid.

Darryl

Many, many, many thanks for this incredible useful script for Sony Vegas. Version 0.7.1. works like a charm. The adapted script also runs under the german version of Vegas 7.0 without any problem.

Having a good software stabilizer for shaky video was one of the most import advantages of Adobe Premiere Pro. But now this killing feature is also available in Vegas! Although it is not an integral part of Vegas, it works like an internal effect. The only drawback left in Vegas is the realy too simple titler. Let us hope for the next version 8.0.

Greetings from Austria!