RED and Shake

[Jack_Felis]

Just a little thought came to mind as I checked on the shipment of my copy of Shake 4.1, if there aren't going to be any new versions of Shake, will Shake be compatible with the RED Codec? I've never used Shake before so I don't know how it handles video (ie. Universally accepts any video files or uses only Quicktime/AVI/ect.).

Anybody able to give an answer for this yet?

[pretopost]

I would think that since Shake is built off of QT architecture that as FCP is developed to edit RED than it would naturally update the codeq into OT.

So it probably just be a QT update and your set...

[therock]

Its proabably not even a QT update.
It should be a codec only, the QT version stays the same.
(If the codec is not implemented by Apple which might be due to the rumors of working together..)
And then every app using QT is able of working with it.
Thats the simplicity of QT.

[stokestack]

Shake has implemented QT support, but it is not "built off the QT architecture." That's a better description for FCP.

That said, Shake should be an excellent application for the manipulation of Red footage. It's designed for large images to begin with, and its QT implementation is designed to retain the full color depth offered by greater-than-8-bit codecs. It's also an RGB app, and since the Red is RGB, you won't have to undertake any RGB-to-YUV conversion.

As long as the Red codec supports the 16-bit pixel format used by Shake, it should work fine.

QuickTime is the only multiple-frame format that Shake supports directly. Because of its heritage as a high-end professional tool, the rest of its formats are still formats; scanned film comes in as sequentially numbered stills.

"And then every app using QT is able of working with it.
Thats the simplicity of QT."

This is generally true for READING, but as of late it's no longer always true for writing. When compressing files with interframe-compressed codecs like MPEG-2 and H.264 (which apparently the Red codec will NOT be), apps need to use a new QuickTime API.

This shouldn't be a cause for concern, however, because even if the Red used this type of compression, Shake should be able to read it. Once you ingest and process the images, you wouldn't want to write them with this kind of codec anyway; you'd want something lossless.

[oneinfiniteloop]

I would think one would just export an image sequence out of FCP for use in Shake. Simple as that, like stokestack said, most people don't work with QT's in Shake...just about always image sequences.

[stokestack]

I would think one would just export an image sequence out of FCP for use in Shake. Simple as that, like stokestack said, most people don't work with QT's in Shake...just about always image sequences.

Unfortunately, I doubt that going to stills would avoid the aforementioned issues coming out of FCP. You could probably get just as good results using a lossless third-party QT codec. And with stills, who knows what'll happen to gamma.

I would strongly recommend starting with the "camera original" (or a copy, of course) in both FCP and Shake. Mark your cuts in FCP and then bring the clips that you need for any compositions into Shake. If you're going to render anything to pass between the apps, render out of Shake and then finish up your edits in FCP.

QT hasn't seen a ton of use in Shake historically, of course, but that will undoubtedly change with the new low price and more and more users of the Mac version. People rendering comps that incorporate Red footage should render to a lossless RGB codec and then bring that back into their FCP timeline. We'll see what the best method for color-correcting all your footage turns out to be.

[Jarred Land]

once the codec is installed any app that supports the resolutions on the platform should allow operation.. on pc or mac.