Idea Advanced Vegas Pro Tools for Us Challenged Users!

Three weeks ago Wayne Waag released a public beta of his Happy Otter Scripts for Vegas. His plugin extension includes many advanced tools accessed from a easy to use and understand front end interface. The tools hidden beneath the interface are open source and available to all who care to venture into the deapths of video and audio far beyond my understanding, but the interface allows users to easily apply these advanced tools, as well as, drill deeper if the desire for lower level knowledge is your thing.

I don't know this for sure, but I think Wayne is waiting until the first of the year, after seeing the responses he gets from beta testers, to determine if he can successfully release a finished version. I hope he is successful. I do not personally know Wayne, I only know him from the years he has spent contributing to the Vegas community with helpful scripts and advice.

At the end of November I downloaded his Happy Otter Tools (I even like the name, otters always seemed to me to be happy little critters), along with a couple of his posted tutorials and tried it out. I took some older footage samples that I had previously used testing Vegas Pro, DaVinci Resolve, ProDad, and Twixtor, in which some needed stabilization and others slow motion. I followed Wayne's tutorials (the simple way of getting started) and was quite impressed with the results.

The results of the stabilization, I found that Happy Otter Tools did much better than Vegas Pro Video Stabilization and as good as, or better than ProDad Mercalli 4+. For slow motion I found that Happy Otter Tools did much better than anything internal with Vegas Pro, better than ProDad ReSpeedr, and almost as good as Twixtor, and in one case better than Twixtor! My testing was far from scientific, but for me it provided some pretty amazing results without the need for me to spend countless hours, days, and weeks trying to use the open source programs Wayne has included behind the scenes. I just simply followed his tutorial by entering data and selection in his interface and was very pleased with the results. In addition his interface permits a whole much of customization far beyond my understanding and of course it will save presets of options I will used repeatedly in the future. It's not perfect yet (it's beta), but I think he only needs a bit more polishing on an outstanding product.

There is a small learning curve, but easy enough I think even for Vegas Pro beginners with some experience with NLE's.

Here is the link for those interested in trying his public beta Happy Otter at tools4vegas.com

Thanks for educating me about this.
I have bookmarked Tools4Vegas and will be sure to check it out.
Cheers

I did a short Slow Motion comparison of 25% slow down using Twixtor, Happy Otter, ReSpeedr and Vegas Pro 16. If anyone is interested they can download the video, put it in Vegas Pro and step through frame by frame to make a comparison. Twixtor, Happy Otter and VP16 work within Vegas Pro. ProDad's ReSpeedr is a stand alone application.

Vegas Pro 16 of course just adds frames, 3 to be exact to achieve a 25% slow down of motion (4X). ReSpeedr used a combination of combining frames and adding frames. Twixtor and Happy Otter both combine frames (comparison of the previous and past frames to create intermediate frames) and as would expect provided the smoothest slow motion results.

However, interpolating frames (combining the previous and past to create an additional frame), doesn't work well for all scenes, especially when forcing a super slow motion slow down. In this example, Happy Otter and Twixtor is creating 3 new frames from the previous and next frames. Using algarythiums they guess at what an inserted frame should look like when it is created from parts of the first and parts of the second (works pretty good for half 50% motion), but when pulling the slow down greater it is guessing at creating frames from other created frames (so to speak). Sometimes in the process pixels get a bit mixed up. How bad depends on the source media and only the user can determine if the flaws are acceptable or not.

This flag source media was shot on a cloudy day with cloud background (if I had waited a few hours I had sunshine!!). I have found the best scene to slow down has lots of light and contrast on the subject matter which adds more separation on the edges of moving subjects and seems that the slow motion math finds it easier to keep cleaner edge lines. Dull lack of contrast and/or a lot of extreme contrast (shadows) seems to create troublesome challenges for slow motion techniques.

If we examine frame to frame of this example there are parts of the flag (in the first series of frames) that Happy Otter and Twixtor did not get correct and they are a bit different between the two options. Even though some of these minor errors are different, I would rate the results, at least for this example, equal results between Twixtor and Happy Otter Render Plus. There are not many and they are difficult to notice when viewed at 60p, so for my eyes and this example they are acceptable.

For each of these examples I pretty much just changed the speed (4x - 25%) and left the other options as default. Using various other options within the Twixtor plugin could very well have resulted in much better results, but I haven't played with it for this comparison. As I understand, Twixtor has some tricky options that can improve the quality of difficult scenes.

BTW: The orange lines in the Twixtor version are created because I do not have a license for this plugin, but often use it as a comparison.



Slow Motion Comparison Video: i.imgur.com/dLjVDRE.mp4

Source Media: The source for this comparison was DNxHD 1080 422 10 bit 59.940 fps in an MOV comtainer, rendered here using Magix AVC (mp4).

Here is another Vegas Pro (or other NLE) tool released by Wayne Waag at Tools4Vegas that is named Render Quality Metrics, and is used to make to mathematical comparisons between two media files, the original and a render, to judge quality lost/kept by the codec selected for the render. The RQM application program and instructions can be downloaded here: tools4vegas.com/library/

Today I had the time to make a few comparisons. Just for explanation, the RQM provides 'Mean Squared Error' and 'PSNR' comparison readouts. Read the instructions for RQM for an explanation of MSQ and PSNR, but in short, the lower the MSQ number the closer the rendered files is to the original, and the higher the PSNR value the closer the rendered file is to the original. For example, if you used a lossless/uncompressed codec to render an original file, the readouts should be MSQ = 0.00 and the PSNR = 99 (99 be the highest).

The comparisons I mage today started with a source media original file recorded with a GH4 camera into the Atomos Ninja Flame using the Avid DNxHD 422 10 bit codec. The render samples I made were with the Vegas Pro Magix AVC, Handbrake Youtube preset, and DaVinci Resolve 14/15 Youtube preset.

First I compared the file size which is a concern to many rendering out to a delivery format for Youtube or Vimeo and even home viewing.....

File 1 - Original source media file size = 621 meg
File 2 - Magix AVC = 28.6 meg
File 3 - DaVinci Resolve = 6.87 meg
File 4 - Handbrake h264 = 5.61 meg

Here are the comparison readouts for the rendered files (2, 3, 4) in comparison to the original file (1)

File 2 - MSQ = 1.738, PSNR = 45.744
File 3 - MSQ = 2.54, PSNR = 44.093
File 4 - MSQ = 37.482, PSNR = 34.536

When I load these files into Vegas Pro 16 and compare several different frames of the video to the sames frames of the others using the scopes, I see a difference between the original source media and the rendered files as we should expect. And, the difference is in direct relation to the comparison math that RQM provides. Magix AVC receiving the best comparison score from RQM shows me a very slight difference in color shift in the Vegas Pro scopes. The DaVinci Resolve render showed a tiny bit more, and the Handbrake h264 render showed the most and very noticeable shift in color scopes.

For those who may not be familiar with the Avid DNxHD 422 10 bit codec, the files size recorded is considerably larger than from cameras that will record h264 (mp4 wrapper), so there may not be as much a dramatic size difference from other source media as I have in my example, but there will be some and that is the advantage of rendering to a delivery format in h264/x264 as it requires much less bandwidth to upload or transfer across a home network and of course storage space.

The down side of delivery formats is the loss in quality from the original, so picking the delivery codec render which retains the most quality is to be an advantage and that is the advantage of using the Render Quality Metric tool, as it provides a real mathematical comparison that we may not otherwise be able to detect with our human eyes.

Because I use DaVinci Resolve for editing and production I will favor using it's Youtube preset h264 render codec which provides a relatively small file size and little quality loss in comparison, which I was surprised. I was also surprised at the quality loss provided by Handbrake and just as surprised by the quality kept using Magix's AVC codec (in MainConcept mode). There is a trade off in file size between Magix AVC and Handbrake and if file size is a major concern, then the quality loss may be acceptable. Every user is going to have different criterion to follow and decisions to make, but I think Wayne's RQM tool is a method users should enjoy to compare and determine if what they thought was true is actually true or note.

The use of the RQM would be even more important to those who are using intermediate files, as these get rendered several times and each time there is a loss of quality and it is important to the end results to hold this loss to a minimum. Of course rendering in a lossless/uncompressed format would solve the quality loss problem, but lossless files are huge and create the problem of storage space requirements. We know the idea of intermediate files is to render out with minimum loss or quality while keeping the files size to a manageable size, and or to work with files that are more preview friendly on computers that may struggle previewing in Best Full preview quality.

I hope I have presented this well using my feeble knowledge and understanding of RQM and codec rendering, nonetheless I think the Render Quality Metrics tools is of great value.

I made some more render/codec comparisons using the Render Quality Metrics tool and placed the results of all comparisons into a simple table sorted by the MSQ value.

BTW: the source media for these comparisons is Avid DNxHD 220 4:2:2 10 bit 1080 59.940p, file size 628 mg, length 11.23 seconds (707 frames).



All renders were performed using default settings, so there is flexibility using some codec such as variable bit rate or constant, or increasing/decreasing the maximum/average bit rate, etc. which will make a change in the comparison values. For example the h.264 codec is usually used as a delivery format reducing the file size and still retaining a reasonable quality for 4;2:0 8 bit products which are common with consumer cameras, phones, etc. But h.264 is also capable of rendering a lossless files when setup for that purpose.

The letters in brackets after the render/codec is my note on playback speed/smoothness. 'A' will playback in Best/Full preview quality at full speed, 'B' will playback in Best/Full preview quality mostly at full speed, while 'C' will not playback even at Draft/Half at full speed.

The Render Quality Metrics comparison tool is not the do all end all method of selecting a render codec because there are too many other considerations, but it does provide a more scientific/mathematical way to determine quality to either confirm what our eyes see, or go beyond what our eyes predict. Seems like a logical tool to me considering what we see on the screen is pretty much just a bunch of math!

Edit: Updated Table
Edit: Updated Table 01-12-2019
Edit: Updated Table 02-02-2019

I updated the Render Quality Metrics table (in previous post) adding several more codec renders, correcting the files size column to reflect megabytes, and adding a column to list Bite Rate of the codec.

I made another update to the Render Quality Metrics table (in previous post) adding one more codec render, and making a couple corrections in the notes.

Thanks George
I do appreciate the advanced knowledge you share on this forum.
Thank you.