Red makes many workflows possible, but as of right now, the most clearly defined one is the one that will be made possible by the REDCODE support in Final Cut Pro 6. This post will lay out how that’s going to work, to the best of my understanding. Like the post on REDCODE QuickTime support (which you should read before reading this post), this information was pieced together from many sources, and as a result some things are still unclear and others might not be completely accurate.

First off, it’s useful to be a bit more precise about exactly what level of support exists for REDCODE in Final Cut Pro.

All versions of Final Cut Pro will see REDCODE footage through QuickTime reference files (see QuickTime link above). You should be able to cut footage at 1K and 2K (more on 4K later) even in FCP 5.x. So, what’s the big deal with FCP 6? An updated version of FCP 6 (note: not 6.0, but an update that will come later) will add two important things to the mix.

The first of those is RT support. As folks familiar with FCP know, in order to get real-time features, a timeline has to be using a “blessed” codec — one which Apple explicitly supports for RT. In this FCP 6 update, REDCODE will be such a codec. Until that update ships, you’ll be able to play back and make straight-cut edits in FCP on a timeline that uses REDCODE, but anything more than than (transitions, filters, etc.) will require rendering.

The second big thing that will come in that FCP update is an FxPlug plug-in that brings many of the features of REDCINE right into Final Cut Pro. (For those unfamiliar with FxPlug, it’s Apple’s newish plug-in architecture for Final Cut Pro and Motion, which opens up many more possibilities than the previous plug-in mechanisms for FCP and allows for vastly higher performance.) This plug-in will allow for fine control over the “development” of RAW footage, and can actually share look files with both REDCINE and the camera (more on that in another post).

It’s unclear exactly what the implications of not having Red’s FxPlug will be. This is an important question for people looking to cut Red footage in FCP prior to the release of the update that adds explicit support. FCP will certainly still be useful for an offline edit (it was used like this on the Peter Jackson short, Crossing the Line), but will it be possible to get decent results for your final conform? Since the REDCODE codec will apparently be giving data in a full float color space to FCP, the data you’ll need to get your image to look the way you want it to should be in the image data presented to FCP, but will you be able to massage it to look the way it should without a tool designed for this task?

Another thing that’s presently unclear is whether Apple’s new Color app (previously Silicon Color’s Final Touch) will be able to work with footage directly from a REDCODE timeline. My guess is that it will, but that you’ll have to render a clip that has had its look tweaked with Red’s FxPlug (or probably any clip that has had any FCP filters applied to it), since Color doesn’t, as far as I’m aware, have support for FCP plug-ins.

What about 4K? Well, that’s a mixed bag. Some apps in Apple’s toolset support it with no problem, like Shake. FCP doesn’t officially support it, but can be coaxed into doing it. Color only supports 2K. Motion, I believe, technically supports 4K, but you have to have the right video card. As of right now, plan on finishing at 2K with this workflow. This is not, mind you, a major problem, as there’s almost no venue where 4K is actually beneficial at present (more on that in a future post).

Ultimately, based on the information I’m familiar with and a bit of speculation, here’s how I expect a typical Mac-based workflow for a Red feature to go, once the FCP 6 update with additional REDCODE support hits the streets:

1. Shoot 4K REDCODE RAW.
2. Download to a RAID attached to your editing system. (See many previous posts on storage.)
3. Bring preview-quality footage at 1K or 2K into FCP via appropriate reference movies. (See previous post on QuickTime REDCODE support.)
4. “Develop” as desired using Red’s FxPlug.
5. Render VFX or CG shots out of Shake, Maya, etc. as REDCODE RGB at 2K and bring them into FCP timeline.
6. Edit, with full RT support, etc.
7. Re-link FCP project so it points to reference movies that specify full quality 2K footage. Change timeline resolution if it was previously 1K.
8. Open clips from the timeline in Color, grade them, and render back to the FCP timeline.
9. Output to desired format via Compressor or QuickTime conversion (much more on creating appropriate deliverables in future posts).

If this is accurate, it’s a fairly straightforward workflow, that should allow for 2K deliverables to be produced with a reasonably priced workstation and a fairly moderate amount of storage. That’s pretty impressive, given the speed of Red’s development program and the fact that they were also working on some other stuff (like, you know, the camera) at the same time. It’s interesting to see an upstart like Red coming out of the gate with a better post workflow than most major vendors do. (I didn’t see Sony shipping an HDV QuickTime component the day its first HDV cameras shipped.)

Anyway, this is basically the workflow we plan to use, so expect lots more details about it in the future.

So, Red is making an affordable camera that produces great footage. What do you do with it? Well, it depends what platform you’re on, what sort of content you’re working with, and what your budget is.

Information is still a little hazy on some workflow issues, so this is the first post in a series that will continue as more information comes out.

Everyone is focused on using Red for digital cinema, and certainly that’s the most exciting application of the camera This blog is, nominally, about digital cinema, and I’ll get to that soon. Odds are a lot of people are also going to be shooting broadcast material with the camera, and this has gotten somewhat less attention. So, let’s start there.

First off, for broadcast delivery, you might not want to shoot 4K RAW. Why do I say this? The two standards for HD broadcast are 720p60 and 1080i60 (or PAL-country equivalents). Shooting REDCODE RAW on-board at 4K, you can only go up to 30 frames a second.

For some material, like narrative work, it’s possible you’ll still want to shoot at 24 fps and add appropriate pulldown to conform to these standards. In that case, you’ll probably want to shoot 4K RAW. But for other sorts of material, you’ll probably want to shoot in a format which captures 60 or 50 frames a second, which means shooting at 1080p or 2K.

If that’s the case, your workflow becomes:

1. Shoot 1080p60/1080p50 RGB (won’t be enabled when the camera first ships) or 2K RAW @ 60/50 fps.
2. Process footage into Apple ProRes or Avid DNxHD 1080i or 720p through REDCINE. Or, if using Final Cut, through the new “Log & Transfer” interface. (The tapeless equivalent of “Log & Capture”.)
3. Edit material online in ProRes or DNxHD.
4. Go out through a Kona card or similar to the appropriate tape format, and hand that to your client.

If you’re going out to a tape format which uses a codec your editing environment has native support for (e.g. DVCPRO HD in Final Cut), you might want to change this a little, and convert directly to that format from REDCINE, and then output over FireWire. This results in a final product that has only been through two generations of compression (REDCODE and your delivery codec) rather than three (REDCODE, your editing codec, and your delivery codec).

What determines whether you should shoot 1080p RGB or 2K RAW? That’s a rather complicated subject that I’ll address in another post.

Up next: how do to a 2K (or possibly even 4K) DI on your desktop, and higher-end DI options.