Thanks for the reply. Would you say that this is the best stabilizer out there.

What would you say would be the difference between the two with regard to performance.

regards
Stephen

I like the stand alone. It is all I have used.

I like getting the analysis and stabilization out of the way from editing and playback where it might hamper performance. The disadvantage is and extra render but Mercalli has good bitrate output and uses x264 for encoding so I feel fine about this. If you have camera material with 4:2:2 color then you might not want this extra render. Having said that I do not know if Mercalli can output 4:2:2. x264 support its, so that is not a limitation.

I like the user interface with the graphs and such. For me with mountain bike stuff I do not fully stabilize, cannot really, and the graphs show me where stabilization suppression will occur and I can go to that portion of the timeline and see how things look.

I use version 3 Stand Alone on almost all my hand-held footage. One advantage of the stand alone is that you can batch stabilize. Put multiple clips in the batch and let it stabilize and render all of them unattended. As mentioned, it renders at a high bitrate. I have not seen any noticeable degrading of the video as a result of the extra render. (I do see some degrading as a result of the fact that Mercalli has to zoom-in to stabilize without borders, so it lowers the resolution somewhat. That applies to the version 2 plug-in too.)

With the Version 2 plug-in for Vegas you have to do one event at a time and wait for it to finish before going on to the next one. It takes over Vegas while it does it's analysis so you can't even do other editing tasks during that time.

>>and is this must have tool?<<

It is to me because my hand-held footage is always quite shaky. I can get it to near tripod stable with Mercalli.

+1 for Mercalli 3 SAL. I find that 3SAL gives a better more stable result than the Mercalli 2 plug-in when comparing the plug-in and SAL on the same trim of a video clip. 3SAL is very impressive and is a must-have in my book.

Mercalli SAL is really quite brilliant, but I really haven't been able to make much use of it because of a perfect storm of issues.

Here is the thing. Mercalli SAL 3 treats interlaced and progressive footage differently. With progressive footage it stabilizes the image by looking at the differences between frames and stabilizing on I believe six axises. With interlaced footage, it separates the even and odd frames, stabilizes them separately, then folds the two field separated and stabilized fields back into an interlaced fram by even and odd lines. The way it determines which process to use Is by reading the header. If the header says it is progressive, it processes it frame by frame, and if the header says it is interlaced, it separates the fields and treats it like interlaced.

The problem is that on a lot of AVCHD cameras, the image is actually progressive even though the header says that it is interlaced. This is especially true of cameras like the Panasonic hybrid cameras like my GH3 which put their AVCHD footage in a Bluray type file structure.

What happens when you stabilize progressive footage as though it was interlaced is that you actually generate interlace comb artifacts. If you look at the AVCHD before it is stabilized in Mercalli SAL 3, there are no comb artifacts. After running it through Mercalli the comb artifacts are everywhere that there is motion.

Most media players these days will deinterlace on the fly when they see the 60i header on the stabilized footage so this isn't immediately obvious, but if you use these clips in a progressive project you will lose about half your vertical resolution by the time you render out your final master. Not good.

Mercalli SAL 2 allowed you to override the auto settings so you could work around this, but SAL 3 took away these controls.

One way around this would be to use the GH3 MOV format which has a progressive description in the header that matches the actual footage and indeed this works as it should. The problem is that Vegas stretches the color range of the GH3 MOV footage from 16-235 to 0-255. Any footage run through Mercalli SAL 3 will show up on a Vegas timeline as being between 16-235, but unstabilized shots in their original MOV format will be stretched out to 0-255 and need a cRGB to sRGB corrector to display correctly. This correction needs to be done with the project properties set to 32 bit color to avoid banding, and any detail that happened to be in the blacks below 16 or in the whites above 235 will be hard clipped.

This same problem occurs with all the new ProDAD SAL products: Mercalli, Defisheyer, and Respeedr.

We had a big discussion about the difference in the color range between footage before and after Mercalli SAL 3 stabilization a while back. I also had in depth discussions with ProDAD about this and they introduced an MOV output at that time that unfortunately was quite terrible.

I would not recommend Mercalli (or any of the new ProDAD stand alone products) for anyone using an AVCHD camera which shoots progressive footage in an interlaced wrapper. It will work, but you'll be giving up about half your vertical resolution. If your camera shoots in modes that are wrapped correctly in the header, you will be thrilled.

For my GH3 AVCHD footage, the version 2 plugin or SAL 2 stabilization looks twice as sharp, so that is what I use.

It's a shame because the SAL 3 stabilization is really very good.

I sure wish somebody else would complain to ProDAD about this. So far, it is just me, and engineers don't do code rewrites when only one person is complaining.

One more thing: if you are using an MOV format camera, compare the pre and post Mercalli SAL 3 stabilized footage for color. Turn on the video scope in Vegas so you can quantify it. What I expect you will see is that the unstabilized footage appears on a Vegas timeline as being between 0-255. Look closely at the scope and you will probably see a bunch of vertical lines in the graph, especially if you zoom into the graph. Those are the the moiré lines that you will see if you look closely at any gradients in your image.

Now look at the graph of the stabilized footage: is everything nicely in the 16-235 range? Now zoom into the video scope graph: where rate the banding lines? Gone? Look at any gradients (blue skies): what happened to the moiré lines? Did Mercalli fix them too?

No Mercalli didn't change the color or get rid of the moiré. It just wrote the footage into a format that Vegas doesn't stretch.

I may be out and alone on this, but on this one I am absolutely certain that I am right. None of this is going to be fixed while I'm the only one complaining though.

Mercalli is probably just normalizing the output to a 16-235 range. I did not write the program so I cannot say for sure.

AVC data streams support a VUI option which flags the contained data as full range. It is well known about Canon and Nikon DSLRs set this flag in their output files. I believe this is so for GoPro Hero3 Black as well given my observations. I wish MediaInfo dumped this flag so we had a better idea of our source files.

With such a flag an application can reliably auto normalize its decoding on the input AVC stream to 16-235.

The Vegas decoder does not normalize input to a 16-235 range, IMO. Premiere supposedly does normalize. I have MP4 and MOV files, all AVC, which come in 16-235 and files which come in 0-255.

>Mercalli is probably just normalizing the output to a 16-235 range. I did not write the program so I cannot say for sure.

I have done hours of testing over many days. I am sure. Mercalli is locking the colors or they are supposed to be. Certain pre stabilized MOV files are also in the 16-235 range if they you put them on an Adobe timeline. It's only on a Vegas timeline that they are expanded. That and certain media players. In VLC the levels are expanded. In Windows Media Player they are not. I used to think that it had something to do with the how Vegas uses VFW, but VLC uses it's own built in playback engine and codecs.

Anyway, as far the original poster's question goes, if you are using AVCHD that is described as 60i even though it is actually progressive, use Mercalli version 2, either the plugin or the stand alone. It will give you sharper, better looking results.

If your are using MOV, use SAL 3 and don't worry about the color change. It is a correction, not an error. Just put a cRGB to sRGB correction on the unstabilized MOV stabilized footage and they will both match and be correct. Do this correction with the project properties set to 32 bits to avoid banding.

Laurence, I'm looking for the Before and After Banding. I've used some blue and cloudy skies. This is what I am getting for the MercPro3 SA. I'm using footage from my Point and Shoot Bridge Canon SX. It produces MOV which MediaInfo interprets as follows:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L4.1
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Format settings, GOP : M=1, N=12
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 32s 282ms
Bit rate : 25.1 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.506
Stream size : 96.7 MiB (94%)
Language : English
Encoded date : UTC 2013-10-06 09:59:53
Tagged date : UTC 2013-10-06 09:59:53
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


OK, apart from the zoom-in as part of the Merc Steady process, making for a bigger Graph spread, and the oft stated levels shift, I don't see or can't tell from the Graphs any difference in the banding issues. I have banding before and banding after. What should I be looking for?

BEFORE MercPro3 SA cRGB to sRGB:


BEFORE MercPro3 SA sRGB to cRGB:


AFTER MercPro3 SA cRGB to sRGB:


AFTER MercPro3 SA sRGB to cRGB:


Grazie

I'll also add that in activating 32-bit away from 8-bit and rotating thru' Levels and then BACK to 8-bit I was able to remove the "gaps" and retain a filled graph while in 8-bit?!? What's all that about? It's as if Vegas "woke-up"?

Is this at all possible? Well, I'm seeing it. I suppose what I'm saying, is it possible needed to be trained to register the difference between 8- and 32-bit?

Interesting.....

Grazie

I've not upgraded to SAL 3 as I have been completely satisfied with the Version 2 Plug In although this might change if and when I make the switch to HD,

With this said, the Plug In is exceptional and many (here and elsewhere) have made comparisons with other stabilisers before concluding that Mercalli is the best around. If you are only working in SD this Plug In should be sufficient for all your needs but if you're into HD, then see what the others have said above.

Ads an example of how good it is, I recently had some old Standard 8 cine film converted to AVI (via Telecine to deal with the problem of the different frame rates) only to find that there had been a sprocket problem on the camera which meant that every frame juddered quite badly. Mercalli dealt with this extreme problem with no difficulty although the render time for a 40 minute film was inevitably longer (part of this was probably to do with the numerous other FX I applied to each event to deal with faded colour). Even so the render time was not unacceptable.

Richard

GH3 mov file issues have previously been documented...now the new GH4 has an option of recording 0-255, which means that Mercalli should stabilize these without further problems in Vegas, no?

On a side note: is it preferable to run SAL Mercalli on a transcoded intermediate since there will potentially be multiple renders downstream? Or is it simpler to just use the originals and accept a minor degradation in quality?

Grazie, what you are seeing is further evidence that I am correct about Vegas stretching the levels of certain MOV camera formats.

If the MOV levels were indeed 0-255, what you would expect to see is 256 levels of each primary color spread out over the entire cRGB range. On the other hand, if I am correct and Vegas is stretching 15-235 out to 0-255, what you would expect to see is about 219 levels of each primary color spread out to the cRGB range and since that would mean skipping some numbers at spaced intervals, what you would get is the gaps you are seeing in your histograms.

Ask me about whether or not God exists as described by a particular religion and I will tell you I don't know. Ask me about which political party is the best for the future of my country and I'll tell you I'm not sure. One thing I do know for sure though is that Vegas is stretching these levels. I may be all alone here, but I am absolutely sure I am right.

One thing I do know for sure though is that Vegas is stretching these levels.

You have to explain is exactly why only some inputs get expanded and not others.

In other words, why does Vegas expand the input from a some sources (aka DSLRs from Canon/Nikon/Panasonic) and not the input from any other AVC MOV and PCM source.

I wrote to Mercalli about this issue (not recognizing my Canon C100 footage as progressive and not letting me override when it see it as interlaced. They've asked me to send them a sample which I am about to do.

Sony Vegas Pro (12) sees the files as interlaced, but at least SVP allows me to force change to progressive.

There's one more issue with the SAL version of Mercalli. When it finished rendering the stabilized file, it gives it the same file name as the original. Sure, I can go in an change it, so that it doesn't overwrite the original clip, but that is an extra tedious step.

Len

Last night I downloaded a demo of Mercalli v3 SAL for 4k. I tried with some 4k clips from my Panasonic GH4.

All clips were shot MOV @ 100Mbps 24p, 0-255. The stabilized footage was "lighter" so it is indeed Mercalli that compresses the color levels, not Vegas. Result was the same in both mov and mp4 output. If delivery is 16-235, I suppose it's not a big deal - otherwise you can transcode the native mov to an intermediate and then stabilize, or just do the cRGB/sRGB conversion on the timeline.

I am very impressed with the stabilization. Test clips were shot handheld on a manual 85mm equivalent lens wide open, and Mercalli completely eliminated all the shakes and micro-jitters. Viewing on a 1080 monitor, sharpness is outstanding. I was filming a concert from 20 feet away, and you can make out notes on the music sheets.

>All clips were shot MOV @ 100Mbps 24p, 0-255. The stabilized footage was "lighter" so it is indeed Mercalli that compresses the color levels, not Vegas[

Aahh! Did you try the unstabilized footage and stabilized MOV clips and Windows Media Player? If you had you would see that the matched and that the stabilized footage wasn't lighter in WMP! did you load both the stabilized and unstabilized footage onto an Adobe timeline? If you had you would see that they also match and that the stabilized footage IS NOT LIGHTER ANYWHERE OTHER THAN A VEGAS TIMELINE! Well, that and in VLC. The lighter look you are seeing with the stabilized footage on a Vegas timeline is actually the correct unstretched look. This happens because the stabilized footage is now in a format that Vegas no longer misreads and stretches. Yes, I know it looks the other way around, and because of the way Vegas handles video, the oversaturated look looks better in the preview window, but it is oversaturated and will look oversaturated when you render it. The levels on the stabilized footage are what the camera actually shot. I have spent one heck of a lot of time on this, much of it in discussions with ProDAD engineers I am beyond sure of this!