Category Archives: blog

This is the place where I write down my general thoughts on post-production software.

Exploring Temperature and Tint

By | | ,
4 Comments

When dealing with footage which was shot at improper white balance, and trying to correct it, I sometimes wished that Premiere had the temperature slider present in Camera Raw or in SpeedGrade. When a friend expressed similar concern, I decided to take my shot at it. After all, it should be relatively simple, right? It’s only moving the pixels towards blue or orange, and in the case of tint, towards magenta or green.

I even found a sample approximate algorithm to calculate the white point at a given temperature, and almost ended up using it. However, after reading on how the proper mixing requires conversion to HSL colorspace due to change in luma value of each pixel, I decided to explore the issue in more detail. It turns out, like with many other issues, that there are differences on what “temperature” exactly means in various software packages. Consider the following images:

original

Original image.

camera-raw-temperature

Camera Raw/Lightroom temperature adjustment set to -100. The image is brighter, and the tint is much stronger, washing out the shadows.

speedgrade-temperature

SpeedGrade’s temperature adjustment at -1.0 (equivalent of -100). The shadows are not washed out, although the image is darker due to clipped blue channel.

Clearly, Camera Raw is brightening the image, and almost looks like it is trying to mix the blue or orange solids with the picture. Perhaps similarly to what Tanner Helland described in the comments to his algorithm, but without the attempt to retain luminance. I find this adjustment not so great, especially for images with rich shadows that get washed out in the process.

On the other hand, the blacks in SpeedGrade are untouched, and it seems that the temperature/tint sliders operate only as gain adjustments, multiplying red and blue (temperature) or all three (tint) channels at the same time by roughly the same amount, and leaving the luma mostly intact except for the places, where the blue channel is clipped.

I even explored playing with gamma on the a and b channels in Photoshop L*ab color space, which directly code the interesting information (a is the tint scale, b is the temperature scale), but these were also not as satisfying as SpeedGrade’s. In the end, I decided to stick with the color correction software.

I experimented for a moment with the formulas and values, but in the end, I turned to Nuke to find how it resolves the issue, because it does provide an immediate numerical output. Finding out the exact adjustments was quite easy. Using grade and expression nodes I was able to mimic what Nuke was doing during temperature or tint adjustments, and came up with very simple formulas.

nuke

A very simple setup in Nuke allows to find the proper formula for handling temperature and tint adjustments to mimic SpeedGrade’s controls.

Implementing them as a plug-in for Premiere was relatively uncomplicated, and took me less time than writing the documentation for it. In fact, I was also able to successfully tackle OpenCL acceleration as well, but this will be incoming in the paid version some time in August.

A Storm Or A Spoon

By | | , , ,
3 Comments

Update: The 7.1 version due out in October is going to fix the issue altogether. Great job, Adobe!

Being the one to spoil the party is no fun, especially if you like the host, or enjoy the meals. But when your favourite dish was rotten and received only a little ketchup treatment, well… sometimes you have to be vocal about it.

Let me at first say that I love the party. To have an update within a month of the release, that fixes a major multicam bug (which for some reason I have not fallen prey to) and adds plethora of new features that will make life and editing easier is awesome. This is the power of Creative Cloud that a lot of people were talking about. There’s no denying, that the party is well deserved.

If you want to learn of all the new features and improvements to Premiere Pro which come with version 7.0.1 update, take a look at the official Premiere Pro blog or reTooled.net tutorial. They will show you the goodies, and these are plenty.

But unfortunately for me, one issue is not completely resolved. And it’s not for the lack of trying.

I wrote before about a nasty curves issue, and for some reason my post was not received with enthusiasm at the home of Premiere Pro. I really, really hoped it would be resolved in this update, and that I will be able to join the happy fest. Well… it is, and it isn’t.

The good news is that the curves no longer clip superwhites and superblacks on input. Depending on how you use the curves it might or it might not be the solution. If you never move the starting and ending points of the curves from their places, you’re good to go. Also, if you only move them up or down, to reduce the dynamic range, you should rejoice, because it works as it used to as well.

But if you ever move these points to the inside, namely the point on the left to the right, or the point on the right to the left, to add contrast, and you hoped to later recover the clipping, your troubles did not go away. Sometimes they might even be compounded.

Unfortunately the curves still not work as they used to. This example of course is exaggerated to the extreme to make a point.

Unfortunately the curves still do not work as they used to. This example of course is exaggerated to the extreme to make the point.

Because the curves will flatten everything what is beyond the leftmost or the rightmost curve points up until the left or right border. Then they will resume their 45 degree slope. To many it might be a non-issue. To me it is. To me it means that most of my old projects will still have to be rendered out in CS6, and I will have to be careful with the new ones, especially when using Jarle’s grading presets.

I am not happy. Depending on where you sit, this is either a storm in a teacup or a spoonful of tar that spoils the barrel of honey. Unfortunately, I belong to the second group, and it’s no fun at all.

Dr SG, or How I Learned to Love SpeedGrade…

By | | ,
1 Comment

sgSome time ago I mentioned that due to certain turn of events I ended up learning more about SpeedGrade than I ever expected. Since the cat is out of the bag now, let me elaborate. I was contacted – of all days on April 1st – with an offer to become the technical editor for the “Adobe SpeedGrade CC – Classroom in a Book” book authored by none other but Alexis van Hurkman himself.

After making sure that it was not April Fool’s Day joke, I was happy to accept the job. It turned out to be a great experience. Granted, Alexis is an experienced technical writer, so I ended up having very little input, but the side effect was that I learned SpeedGrade from top to bottom – something that would most likely never happen otherwise.

Regardless of my still present love for Resolve, I ended up appreciating several nifty features that SpeedGrade does have. The shortcuts to quickly adjust the interface, the ability to create grading layers spanning over several clips, quick adjustments for tonal ranges (shadows, midtones and highlights) really emphasize the “speed” part of the application.

Of course, the limitations which I described before still apply, and Resolve is still king when it comes to power windows, tracking, secondary selections and automatic grade management. But SpeedGrade definitely has potential, and from what I know, it is not going to go to waste.

I’d like to thank Senior Editor Karyn Johnson for the opportunity to be part of the team, and sincerely recommend the book to anyone interested in learning SpeedGrade. And if you are a Premiere CC user, you might need it sooner than you think. Be prepared.

Warning about using RGB and Luma Curves in Premiere Pro CC

By | | , , ,
8 Comments

Update: The 7.1 version due out in October is going to fix the issue altogether. Great job, Adobe!

Update: The 7.0.1 patch for Premiere Pro CC fixes some of the below mentioned issues, although unfortunately not all of them.

To my great chagrin Premiere Pro CC changed the way curves operate. Right now the curves, both RGB, and Luma, clip the superwhites and superblacks, and there is no interpolation going on after the curves hit 0 or the white level (255 or 1.0). In CS6, the curves followed the general slope, and it was possible to recover some of the “overshot” material. Right now, if you stick to curves, all clipped data is lost.

cs6

Curve's interpolation in Premiere Pro CS6 allowed to recover superwhites or superblacks, and correct the contrast in the same instance.
cc

Premiere Pro CC clamps all superwhites and superblacks, and recovering the detail is not possible with the use of RGB or Luma Curves.

This is completely new, unexpected, and if you ever used curves, it changes your workflow dramatically, even if you don’t know it yet.

It means that you must remove the superwhites and superblacks from the clip before you use RGB curves. It means that if you were like me, using curves to apply the basic correction and contrast in one go, you cannot do it now. You have to first make the signal “legal” – reduce the superwhites and raise the superblacks with for example Fast Color Corrector, so that they fit between the range that curves operate on – RGB scale that is not overshot in either direction, even if you are working in the floating point (max bit depth).

fcc

In Premiere Pro CC you need to use Fast Color Corrector or Three-Way Color Corrector to bring the superwhites back into the RGB scale. Only then you can apply curves, and be sure that you are not loosing data.

It also means that there is no real backwards compatibility within the projects that used curves. Your colors will not be the same, if you had any superwhites in the project. I highly advise you to finish your current projects in CS6, and only then create the new ones in CC, being mindful about the necessity to use Fast Color Corrector before applying curves.

Adobe is aware of this issue, and hopefully some fix will come soon, but while using CC 7.0.0 version of Premiere you need to remember about this very real problem.

D is for “Deselect Before Applying a Default Transition”

By | | , , ,
13 Comments

The very first thing that you should do… no, let me try again. The very first thing that you must do after installing and opening the new Premiere Pro CC is to set a keyboard shortcut for Deselect All. Trust me. This will save you a lot of trouble later.

This is something that you must do as well, if you think that applying transitions in Premiere no longer works.

Open the Edit menu, choose Keyboard Shortcuts…, and in the search box type “deselect”. Fortunately only one option will be visible, the one that appears in the Edit group – “Deselect All”. Assign a shortcut to it which will be easy for you to remember. I sincerely recommend D , because D is also used to apply default transitions. And if you have used Premiere before CC, you will have to learn this new shortcut combination:  D , Cmd /Ctrl + D to apply the default video transition, or  D , Shift + Cmd /Ctrl +D for audio transitions.

 

shortcut

Set this shortcut right now!

Why?

Premiere Pro CC introduces what is called “the primacy of selection”. Translated to plain English it means, that if you have anything selected in the timeline, Premiere will attempt to use the selection for any operation you choose, disregarding track selections, playhead position, etc. While there is an argument to be made that it’s more effective, more consistent (well, perhaps some day), it is changing the behavior which was long established in Premiere – using the playhead position for applying transitions.

Here’s how the new behavior works: if a clip is selected, and it is between two other clips, nothing happens. If the clip has at least one edit point where it does not touch anything, then the selected transition is applied to the loose ends. And if multiple clips are selected, the transitions are additionally applied between these clips. Not very obvious, right?

before

The clip on track V2 is selected. You might not even notice it. At least I didn’t!

after

And here’s the result – instead of applying the transition to the edit point under the playhead, the selected clip receives the transitions on both sides.

If you are like me, and you select and deselect clips all the time, whether to adjust effects or for any other reason, then this new behavior is going to bite your muscle memory hard. Before you learn the  D , Cmd /Ctrl +D combination, you will find yourself cursing two times: once when the desired transition does not appear in the place you think it should, and the second time, when during preview you find stray transitions in various places.

This is the collateral damage or “the primacy of selection”. If you forgot to deselect, and want to use the old way of applying transitions – by the track selection and playhead position – then you are screwed, and need to adjust. It does not help to know that this behavior is the result of Final Cut Pro’s inability to select multiple edit points at once, and was introduced there as a remedy to this limitation. Supposedly a lot of FCP users asked for this functionality in Premiere. They got it, and it came at a cost to established workflows. Like the introduction of patch panels in CS4, only more mischievous, because the results may not be immediately visible.

before-2

Here the selection is a bit more obvious. Watch what happens, when the shortcut is pressed now.

after-2

The transitions are applied at the end, and in between the clips. Remember to learn the new combination of keys – D, cmd/ctrl+D – if you want to use the playhead to apply the transitions.

To add confusion, there is a keyboard shortcut to “Apply Default Transition to Selection”, which works exactly like Apply Default Transition if clips are selected, although it applies both audio, and video transitions.

My little mind can’t comprehend the idea behind this change, especially since I’m not the only one who was taken aback upon the first encounter with the new behavior. But I know of others who are happy about it, and I found some use of it as well… only to encounter a stray transition during the final viewing of a recent production.

So remember – D , Cmd /Ctrl +D is your new shortcut for Apply Default Transition at the Playhead.

Apple’s move to FirePro GPUs in the new Mac Pro

By | | ,
4 Comments

Perhaps one of the biggest surprises during the recent sneak-peek of the new Mac Pro was the inclusion of AMD FirePro GPUs. While at first it might look like Apple again showing the middle finger to all CUDA users, and perhaps to Adobe or BlackMagic, “it ain’t necessarily so”.

Personally, I always liked AMD and ATI for their affordability, power saving, and sensible performance. Even though they usually lagged a bit behind nVidia and Intel, it was good to have competition which would keep the big players in check. In fact, the Pentium 4 fiasco was the moment when I really hoped that AMD will become the leading player in the CPU game. I have this personal love of underdogs. Alas, it was not meant to be.

The trouble began when Adobe started to use nVidia’s CUDA technology for acceleration, and when the performance of Intel’s new iCore series left AMD far behind. Essentially, if one wanted to use Adobe software, the choice was completely gone. It was Intel CPU and some kind of CUDA GPU. Adobe officially pushed heavily for Quadro solutions, which were way overpriced, and in terms of performance always behind the latest GTX series. Personally, I never bought into Quadro hype, because the benefits were not there.

On the other hand, Apple stuck to ATI cards, giving the users very limited offer, if they wanted to profit from CUDA. It was GT8800, GTX 285, or Quadro 4000. All terribly outdated or pricy. Now, this could really have been considered the middle finger to Adobe, considering FCP and Motion as competing products, and we know that Adobe engineers were not happy about the turn of events. Of course, it was also Apple’s way of promoting their own standard – OpenCL – which came about partly as the competition to nVidia’s CUDA. So the situation was a bit complicated, especially for Mac users.

Granted, nVidia was collaborating with Apple, AMD, IBM, and Intel on OpenCL since its inception, as part of the Khronos Group. Therefore the support for OpenCL soon became a standard for nVidia GPUs. Also, while CUDA is proprietary and optimized for Fermi/Kepler architecture and performance, OpenCL is open, and able to utilize any device, which can support its extensions. In OpenCL even CPUs can be put to work using the same code that programs GPUs. Of course, while there are only 4 to 12 cores in a single CPU, as compared to about a thousand in a decent GPU, the CPU input tends to be neglible, but it is there. The performance on equal hardware lagged until very recently, but last year OpenCL bridged the gap, and the two seem to operate on the parity level now.

Besides, Adobe has supported OpenCL in Premiere since CS6. BlackMagic claims that Resolve 10 will also have OpenCL support, and they seem to be pretty happy about it. The end user should not experience any problems, perhaps with the sole exception of the Ray-traced 3D engine in After Effects, which requires CUDA for accelerated processing. But this will most likely change in some future version as well.

I should indeed be cheering for OpenCL for having finally taken off. After all, it’s superior to CUDA in all but performance, and Adobe users should in fact be happy that the new, open, and less expensive alternative to nVidia/CUDA has been created. Especially if you consider that the hardware is not equal, and the recent AMD W-series GPU cards seem to fare pretty well against its Quadro equivalents. I might consider it myself in my future upgrades. My lack of enthusiasm stems perhaps from the fact that I wanted to add GPU acceleration to my plug-ins, and invested a bit in researching the CUDA engine, and not OpenCL.

After giving it some thought I agree with Philip Hodgetts, that there is no point in panicking, and that CUDA is the solution that will either go away in the future, or be relegated to some obscure niche in certain specialized applications. OpenCL is indeed the future. So at least in this regard the Apple’s bet is absolutely spot on.

And the new Mac Pro? Well… it’s a completely different story.

Label users, beware!

By | | , ,
Leave a comment

Beware of a nasty bug in CS6:

If you import the footage in such a way that a bin or a number of bins is created upon import, and you label your clips on the timeline, you might be in for a nasty surprise at some point.

If you choose to move your files from the bins, or sometimes even simply select them by the innocent “Reveal in Project” command or so much as click on them, you are going to loose labels in the timeline for selected footage in the given folder. *Pooof*, gone. Like this. Without any possibility of undoing it. If you have not saved your project for some time, you face either loosing the labels, or loosing the changes since your last save, because I tell you, these labels are not coming back!

Now, if you are lucky to have a saved project with your labels still applied, don’t breathe with relief yet, because they are not safe! First follow the following steps to the letter:

  1. Save the broken project under a different name
  2. If your Premiere window is maximized, click the maximize icon and set the window size as you like, just so that it is not maximized.
  3. Open the old project.

This bug propagates across projects! If you have Premiere opened in the maximized window – as most of us usually do – then the moment you open your project, the labels will evaporate as well. But if for some reason you do not have your window maximized (it might be larger than one screen, but it must not have the maximized icon turned on), you are safe for the time being. The labels will remain on the timeline until you trigger the bug again by selecting your files or moving them.

I have no idea why, but having your window non-maximized gives you a chance to save your work. This is the weirdest bug I have ever seen, and it is a nasty one.

The solution is to either import media in such a way that no folder is created, or to move them to another folder immediately after import. It does nothing to save your existing projects, but it will protect you in the future.

I stand corrected…

By | | ,
Leave a comment

In an excellent recent article on Pro Video Coallition Alexis van Hurkman explained how the terminology which I use in my Power Window filter, and in my Lift, Gamma, Gain tutorial is incorrect. The control called “Lift” should in fact be called “Offset”, based on the way it works.

Similarly, the formula which I used to calculate the resulting pixel value in the filter is also a bit different than the approved ASC CDL standard. In my case I decided to apply the power function (gamma) to the input value of the pixel, and the CDL order applies gamma as the last operation, affecting the result of the offset and gain corrections. Come to think about it, it makes a bit more sense than the way it is implemented now, especially for the footage which was shot in log space. If you set your black (offset) and white (gain) levels, you don’t want them to move, when you change the midtones (gamma).

Perhaps for the compatibility sake I should add another (sigh…) control where the user would be able to choose between color calculations, but after giving it some thought, I will definitely correct the order of operations in the next release of Power Window plugin.

The Case For Three-Button Mouse Editing

By | | , , ,
5 Comments

RzrNaga2012_view3Mouse-driven editing has usually been associated with the lower end of video editing, and to a certain extent justifiably so. If I see a person using only his or her mouse to edit, I don’t consider them very seriously. Editing is a tough job, and a human being has two hands, so why not put both of them to work? Put that left hand on the keyboard right now!

The question of whether the right hand should spend more time there as well or not is debatable. Even though I have been driven through CS6 mixed bag of innovations to make more extensive use of my touch-typing skills during editing, I am still looking to improve on the mouse side of things, because the hybrid mouse + keyboard editing has been historically the fastest way to use Premiere.

When it comes to mouse mastery, nothing can beat 3D artists, especially modellers. The necessity to constantly change the point of view in three dimensions clearly showed that not only a single mouse button is not enough, but that even two will not suffice. You need a 3-button mouse to work in a 3D application. Period.

Granted, using the middle button with most mice is something that requires a bit of practice, since often it entails pushing on the scroll wheel. However, the newly acquired skill gives you more flexibility, and options. Why then not use a 3-button mouse in editing? And why not take advantage of the fact, that pushing the middle button is not as easy, as pushing the other ones?

One thing that I found myself using a lot during mouse-driven editing was delete and ripple delete. Even after remapping my keyboard, it still remained a two-click process. First select the clip, then hit delete. Fortunately you can use both hands, but still, there is some space for optimization here. The middle mouse button could be used to perform a single click ripple delete.

Another idea for middle mouse button is to map it to “Deselect all”, and it might become pretty handy with the incoming CS Next confusion about the primacy of selection over playhead, or targeted tracks for example during applying transitions.

Both of these options are available now via many macro recording and automation pieces of software. Personally I use the ones that came with my mice – either Microsoft’s IntelliMouse or Razer Synapse. They both allow remapping the middle mouse click for certain applications to a macro or a shortcut key (and much more, if you wish to explore them further). Therefore I first make sure to create the keyboard shortcuts to “Ripple Delete” or “Deselect All”, and then to map these shortcuts to the middle mouse button. And voila! Single click ripple delete or deselect all are literally at your fingertips now.

The quest for ever more efficient editing continues, and I hope to have some exciting information for you soon.

Adobe Anywhere – Currently An Enterprise Solution Only

By | | ,
8 Comments

On NAB we’ve seen a few reveals from Adobe, and among them also the premiere of Adobe Anywhere. I speculated extensively on Anywhere in the past, and I was perhaps a bit too optimistic in my assessment for required hardware and bandwidth, motivated mostly by the hope that we would be able to install it in our small facility as well. Alas, it’s not going to happen.

As of now, Anywhere requires at least 4 servers to run: one being a collaboration hub, and 3 Mercury Streaming Engines. Karl Soule explained, that this is a required minimal structure, because the MSE machines also take care of the rendering. This hardware should cover the needs of 6-8 editors, and supposedly scales well by adding additional machines. It’s certainly not inexpensive (starting at $5000 but most likely achieving $15,000 to $20,000 per piece), and the cost is certainly increased by Windows 2008 Server Enterprise Edition (about $2300 per license) and MSE requiring at least one Tesla K10 processing unit costing $3000 each.

I was not mistaken though about replacing expensive SAN licences with something a bit more affordable. The two currently recommended systems (Harmonic MediaGrid and Isilon X400 series) sport their own filesystems which cover most of the SAN benefits, without incuring the overhead. Plus they work via Ethernet, lowering the price of backbone architecture even further. However, don’t get your hopes up, these solutions are still pretty expensive, going into hundreds thousands of dollars.

Obviously, Anywhere is not a plug and play solution, it requires tailoring to the specific workflow and solutions in one’s facility, and Adobe has their own servicemen who will install and configure it. Judging by the fact that the cost of software and installation is also not publicly available, it is safe to assume that it does venture into the “if you have to ask, you can’t afford it” territory.

My bandwidth estimation was also too optimistic. The suggested pipe for seamless experience seems to be 25-40 Mbps, which is not insignificant, and in fact might be the biggest limiting factor to the actual spread of Anywhere. While it’s easily achievable locally, it is far beyond standard 3G data rates (2 Mbps), requiring LTE or HSPA+ connections, not always easily available, and is slightly beyond WiFi 802.11 a and g standards, requiring at least 802.11n communication using multiple antennas. It is also at the edge of what the most recent ADSL modems can provide (40 Mbps in the ideal conditions). So perhaps Bob Zelin’s dream of remote editing will still be limited by the last mile infrastructure, at least for a time.

In the end, the message is pretty clear: right now Adobe Anywhere is aimed at the enterprise players like CNN and large post houses who can afford the necessary equipment or perhaps can fit it into an already existing hardware structure. Certainly, the benefits are great, but the little folk can only hope that at some point these solutions will trickle down.