My vision of Adobe SpeedGrade

SpeedGrade seems like a very promising addition to Adobe Creative Suite, which I have already mentioned. However, after playing with it for a short moment, I found with regret that it does not fit our current infrastructure and workflows. Below is a short list of what kind of changes that I consider pretty important. These requests seem to be quite common among other interested parties, judging by the comments and questions asked during Adobe SpeedGrade webinar.

First, as of now the only way to output a video signal from SpeedGrade is via very expensive SDI daughter board to nVidia Quadro cards. This is pretty uncommon configuration in most post facilities. These days a decent quality monitoring card can be bought for less than 10 times the price of nVidia SDI. If the software is to gain wider popularity, this is the issue to be addressed.

Adobe seems to have been painfully aware of its importance, even before the release. I’m sure that had it been an easy task, it would have been accomplished long ago. Unfortunately, the problem is rooted deep in the SpeedGrade architecture. Its authors say, that SG “lives in the GPU”. This means that obtaining output on other device might require rewriting a lot – if not most – of an underlying code – similarly to what Adobe did in Premiere Pro CS5 when they ditched QuickTime and introduced their own Mercury Playback Engine. Will they consider the rewrite worthwhile? If not, they might just as well kill the application.

Second, as of now SG supports a very limited number of color surfaces. Unless the choice is widened to include at least Avid Color, and new Tangent Elements, it will push the application again into the corner of obscurity.

Third, the current integration with Premiere is very disappointing. It requires either using an EDL, or converting the movie into a sequence of DPX files. It’s choice of input formats is also very limited, which means that in most cases you will have to forget about one of the main selling point of Premiere – native editing. Or embrace offline-online workflow, which is pretty antithetical to the flexible spirit of other Adobe applications.

The integration needs to be tightened, and (un)fortunately Dynamic Link will not be an answer. DL is good for single clips, but a colorist must operate on the whole material to be effective. Therefore SG will have to read whole Premiere sequences, and work directly with Premiere’s XML (don’t confuse with FCP XML). It also means that it will have to read all file formats and render all the effects and transitions that Premiere does. Will it be done via Premiere becoming a frame server for SpeedGrade, as is After Effects for Premiere when DL is employed? Who knows, after all, Media Encoder already runs a process called PremiereProHeadless, which seems to be responsible for rendering without Premiere GUI being open. A basic structure seems to be in place already. How much will it conflict with SpeedGrade’s own frame server? How will effects be treated to obtain real time playback? Perhaps SpeedGrade could use Premiere’s render files as well?

An interesting glimpse of what is to come can also be seen in an obscure effect in After Effects which allows to apply a custom look from SpeedGrade to a layer. Possibly something like this is in store for Premiere Pro, where SG look will be applied to graded clips. The question remains, if the integration will follow the way of Baselight’s plugin, with the possibility to make adjustments in Premiere’s effect panel, or will we have to reopen the project in SG to make the changes.

This tighter integration also means that export will most likely be deferred to Adobe Media Encoder, which will solve the problem of pretty limited choice of output options presently available in SpeedGrade.

As of now SpeedGrade does not implement curves. Even though the authors claim that any correction done with curves can be done with the use of other tools present in SG, curves are sometimes pretty convenient and allow to solve some problems in more efficient manner. They will also be more familiar to users of other Adobe applications like Photoshop or Lightroom. While not critical, introducing various curve tools will allow SG to widen its user base, and will make it more appealing.

Talking about appeal, some GUI redesign is still in order, to make the application more user friendly and Adobe-like. I don’t think a major overhaul is necessary, but certainly a little would go a long way. Personally I don’t have problems with how the program operates now, but for less technically inclined people, it would be good to make SpeedGrade more intuitive and easier to use.

These are my ideas on how to improve the newest addition to Adobe Suite. As you can see, I am again touting the idea of the container format for video projects – and Premiere Pro’s project file, being an XML, is a perfect candidate. Frankly, if SpeedGrade will not be reading .prproj files by the next release, I will be very disappointed.

Advertisements

About Bart Walczak

I'm a video editor, and an aspiring colorist and VFX artist, with some experience in desktop publishing, web development and programming.
This entry was posted in color grading, usability, video editing and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s