Major improvements in Vignette and Power Window

matrices

Some of you have complained that my plugins sometimes take a lot of memory to run, and that they are not CUDA accelerated. Well, GPU acceleration will have to wait for a moment longer, but I have coded a few improvements to the Power Window and Vignette which will result in less usage of memory, and much quicker render times.

It used to be, that on the faster machines the CPU usage during rendering these plugins fell from 90% to 15-20%. I did not really know why. It was not multithreading – this is something that Premiere handles on its own. As it turned out, it was an issue of poor coding, and lack of knowledge.

I fixed that, and I also added clamp input black control to Power Window which should fix the problem with low blacks causing problems in gamma calculations, and added various alpha falloffs to the Vignette. The impatient ones may follow to the downloads page, and grab the newest versions. Those interested in details please read on.

Both Vignette and Power Window use the same part of code to calculate the position of the mask. Up until this release, these calculations were performed separately for the move, scale and rotation, for each pixel, for each frame. I was clever enough to calculate the sinuses and cosinuses at the effect setup, but it still turned out to be a significant number of calculations.

Those of you who know about matrices, affine transformations and homogeneous coordinates, have already most likely buried their faces in their hands, crying “why, oh why did you do this? Didn’t you know any better?” As it turns out, I didn’t. And I should have.

I’m a physics major. The knowledge and skills I gained during the studies are really helpful in many aspects of my life, including coding these plugins, and – of all things – understanding how camera sensors work. I used to learn algebra and matrices as far back as high school. And I was pretty decent in understanding them.

And yet, I missed the obvious: that I should have created a single transformation matrix for all the transformations, and apply them all in one go. And had I attended a course on computer graphics during my studies, I would most likely know, that the mathematicians have already came up with some nifty way to resolve my problems. As it was, I learned about the proper way to do this only recently, when I found strange 4D matrices for 3D transformations in Nuke. After doing some research on homogeneous coordinates, with a subtle push from my friend Wojtek Bagiński, I finally decided that I’m going to apply this knowledge to my plugins as well.

The result was far more dramatic, than I would have ever anticipated. Finally the plugins started to use 90-100% of CPU power, and the memory usage dropped down considerably.

Originally there were 11 multiplications, 3 divisions, 4 subtractions and 2 additions to calculate an ellipse. I changed it to 4 multiplications and 4 additions, so it’s a reduction by the factor of 3-4 with a few type conversions lost as well. And the end result is that, even though these plugins are not yet GPU accelerated, you can preview them in the real-time on most of the machines.

It’s good to learn new things. And even better – it’s better to know things so that you don’t have to reinvent the wheel, since somebody has already done it for you. When you don’t know that something exist, you don’t even know what to look for, and your solutions to common problems will most likely be suboptimal.

Go out and learn then :)

Fixed rendering bug in Feathered Crop for OS X

Thanks to the generosity of Adobe I received a time-limited licence for CS6 Production Premium on OS X to test and debug my plugins. The response to my inquiry was immediate, with no additional questions asked. I admit I am totally impressed with their reaction. Kudos, guys!

I was able to fix a really nasty render bug that made the Feathered Crop almost unusable with the latest version of Premiere, what a few users pointed out to me, some in a kind manner, others not so much.

As far as I was able to test it, the version 1.2.1 of the Feathered Crop should be production ready. Download it here and enjoy:

Feathered Crop CS6 OS X v1.2.1 (1813 downloads)

 

There might still be a few issues with displaying when the paused resolution is less than full, which I will try to address in the future, but if you find out that there are still some big problems, please let me know. And yes, test the plugins within your workflow before you start applying them en masse.

Premiere Pro doesn’t export markers of 0 duration to FCP XML

While doing research for a commission that I recently received, I found out that Premiere Pro CS6 does not export markers of 0 duration to FCP XML. This proved to be a bit of a surprise, and also turned out to be a major flaw for the software that I am supposed to develop.

I had to find out the way to automatically convert all the markers into the ones with specified duration. Fortunately, as I wrote many times, Premiere Pro’s project file itself is an XML. Of course, as it was kindly pointed out to me, it’s pretty complicated in comparison to the exchange standard promoted by Apple, however it is still possible to dabble in it, and if one knows what one is doing, to fix a thing or two.

Marker duration proved to be a relatively uncomplicated fix.

In the project file, markers are wrapped into the <DVAMarker> tag. What is present inside, is an object written down in JavaScript Object Notation. I’m not going to elaborate on this here, either you know what it is, or you most likely wouldn’t care. Suffice to say, that the typical 0 duration marker looks like this:

<DVAMarker>{“DVAMarker”: {“mMarkerID”: “3cd853f0-c855-46de-925c-f89998aade87″, “mStartTime”: {“ticks”: 6238632960000}, “mType”: “Comment”}}</DVAMarker>

and the typical 1 duration marker looks like this:

<DVAMarker>{“DVAMarker”: {“mComment”: “kjhkjhkjhj”, “mCuePointType”: “Event”, “mDuration”: {“ticks”: 10160640000}, “mMarkerID”: “7583ba75-81f5-4ef2-a810-399786f3a75d”, “mStartTime”: {“ticks”: 4049893512000}, “mType”: “Comment”}}</DVAMarker>

As you can see, the mDuration property is missing in the 0 duration marker, and the duration 1 marker is also labeled as “Event” in the “mCuePointType” property. It turns out, that it is enough to insert the following string:

“mDuration”: {“ticks”: 10160640000},

right after the second curly brace to create the proper 1 frame marker that gets exported. You can do it in your favourite text editor yourself, and then the corrected marker would look like this:

<DVAMarker>{“DVAMarker”: {“mDuration”: {“ticks”: 10160640000}, “mMarkerID”: “3cd853f0-c855-46de-925c-f89998aade87″, “mStartTime”: {“ticks”: 6238632960000}, “mType”: “Comment”}}</DVAMarker>

Granted, it’s a bit tedious to do it by hand for hundreds of markers (as was my client’s request), and unless Adobe decides to fix it in the near future (I already filed a bug report), or Josh from reTooled.net releases it first on his own, some time at the beginning of the next year I might have a piece of software that will automatically convert the 0 duration markers to 1 frame ones, so that they get easily exported to FCP XML. I understand that this is a pretty rare problem, but perhaps there are a few of you who could benefit from this solution.

The main bugger? Most likely it will be Windows only, unless there is specific interest for the Mac platform for something like this.