I had previously reported that 2K REDCODE footage (2048×1152), shrunk to 93.75% to fit an HD timeline in FCP, came back from Color as 1920×1080 footage shrunk once again by another 93.75%. I’ve since explored this further and found out what was going on—as well as run into and characterized one of the oft-reported “softening” issues in Color. With these and other minor surprises in mind, I’ve developed a RED+FCP+Color workflow that works for me; maybe it’ll work for you, too.
For the purposes of this article, I’m going to assume you’re shooting RED, editing in FCP using transcoded proxies or the REDCODE clips directly, then sending the original REDCODE clips through Color for grading. It’s a bit more of a hassle to work this way than to apply a “one-light” grade in RED’s own tools and then stay in ProRes for both editing and final grading, but it allows you to keep the full quality of the REDCODE files up to the final grading stage, and lets you work with Final Cut Studio tools throughout the process. I’m also assuming that we’re all working with FCP 6.0.5, Color 1.0.4, and the RED Final Cut Studio support package.
If once is good, then twice must be better?
Basic FCP Motion tab effects—scaling, repositioning, and rotation—are sent to Color as part of the FCP-XML metadata. Color shows the effects in its Geometry room, but is supposed to keep those effects as metadata and return them to FCP for final rendering once an FCP-to-Color round-trip is performed (the ol’ FCP “Send to Color”, Color “Send to FCP” XML two-step). Color is not supposed to “bake in” basic Motion tab effects during its own renders.
With ProRes clips, that process works as expected. For example, 2K ProRes clips scaled 93.75% (from 2048×1152 down to 1920×1080) get sent to Color at a full 2K size, where they render out and come back to FCP as 2K graded clips. Motion tab settings conveyed through the roundtrip in XML files then scale them to fit the HD timeline. Repositions and rotations likewise translate into Color and back to FCP via XML data, while the clips output from Color have no Motion tab effects rendered into them.
With REDCODE-native clips, though, Color renders clips out with scaling/translation/rotation applied. Furthermore, it clips the images as needed to fit the bounds of the sequence: graded clips come back as 1920×1080, not as 2048×1152. Nonetheless, the XML that Color returns to FCP retains the Motion-tab / Geometry room settings, so that any changes applied in the Motion tab (that got rendered into the clip by Color) get re-applied in FCP, for double the fun!
A sequence of frames in Final Cut Pro: no motion effects; 90% resize, 15º rotation, and a 10,10 pixel move.
The same timeline, as returned from Color.
There are two simple fixes for this problem: either remove all basic Motion tab settings before sending the timeline to Color and apply them after grading, or let Color render the effects and remove them from the Motion tab after the timeline comes back (select all the graded clips, and choose Edit > Remove Attributes… > Basic Motion).
But, soft! What light through yonder power window breaks?
Another complication: Color doesn’t do nearly as good a job of scaling or rotation as FCP does. Any scaling or rotation rendered in Color causes considerable softening, compared to the same change rendered in FCP. Even a minor resizing, such as the 93.75% required to fit 2048×1152 images into an HD frame, blurs the image noticeably. Note that this isn’t a REDCODE-specific issue; it happens using ProRes422, DVCPROHD, and other codecs as well. This complicates the when-to-apply-a-move question somewhat.
90% rescaling applied in Final Cut and in Color. Clips not scaled render identically in the two apps.
If your source material is the same size as your sequence, such as when you shoot “4K HD” (3840×2160) which FCP resizes directly to 1920×1080 HD, there’s no real issue; send your clips unaltered into Color, and apply any moves when they come back. The same applies cutting 4K or 2K source material (both seen by FCP as 2K images) in a 2K-native timeline.
If you’ve shot 4K 2:1 or 4K 16×9, both 4096 pixels wide, or true 2K, FCP brings those in as 2K (2048 wide), which needs that 93.75% resizing to fit a 1920×1080 HD frame at full width. If you want to use the full image width, you may want to edit your show at the native 2K frame size, send it through Color, and then nest the returned sequence in an HD sequence to apply that final rescaling in FCP. Likewise, rescaling for 720p or SD output may be best done with nests instead of forcing the 2K clips into a smaller sequence to start with.
Alternatively, don’t resize: on a recent spot, I shot 4K 16×9 (which FCP treats as 2K 16×9) and edited the clips into an HD sequence at 100%, giving myself some “overscan” to work with. I had 64 pixels on either side of the image, and 36 pixels above and below, allowing minor reframing of the image in post. As long as you reposition the image by whole pixels (not fractional pixels), Color renders as crisp an image as FCP does, so this was a safe Motion-tab effect to apply. I used that extra overscan in my edit to match the position of shots from different takes, and sent those changes to Color. Of course, I had to be sure of my choices before sending the clips to Color, because Color trimmed the REDCODE images to the HD sequence’s 1920×1080 dimensions when it rendered them out. I also made sure I repositioned clips by whole-pixel increments to preserve sharpness.
One other note: FCP’s motion-tab keyframes don’t survive the translation to Color. Clips with keyframed motion are best dealt with by moving them to their own, native-frame-size sequences (if you’re not already working with a native-size sequence), sent through Color for grading without any effects so as to preserve the full 2K frame size, and then edited back into the show (or nested into the original sequence) with keyframed motion added after the grade. That way you keep full-quality, crisp rendering, as well as having the full-sized 2K frame available to bounce around in.
Now how much would you pay? But wait, there’s more!
Speed changes on REDCODE clips sent to Color don’t work as expected. I had two speed changes in my recent spot, one a 200% speedup, the other a 1300% speedup. When I did a quick roundtrip test through Color using my ProRes proxy clips, both speed changes rendered perfectly, just as they did in FCP. However, when I sent REDCODE clips through Color, the 200% speedup rendered as a 20%, slo-mo gentle dissolve of four frames, repeating over and over. The 1300% speedup seemed to render the correct speed, but from a completely different section of the source clip!
I simply copied the offending clips into a new sequence with no speed changes applied. After grading them in Color, I re-applied the speed changes in FCP and edited them back into the main sequence.
Still frames created in FCP, when sent to Color, cause the entire source clip to be rendered. With REDCODE clips, that can take a considerable amount of time. Also, as with speed changes, the frame you get may not be the frame you wanted.
Whenever a still frame is part of a full-motion clip already in a sequence, I found it best to avoid rendering a separate freeze-frame clip; I’d simply round-trip the full-motion clip through Color, then re-create the still frame in FCP after the grade. Alternatively, I could simply edit in a one-frame-long clip for my desired freeze frame, grade it, then turn it into a freeze frame of the desired length once it came back from Color.
Freeze frames and speed changes caused me to do those bits of extra work, but once done, I didn’t have to revisit them: even if I went back into Color and updated my grades, FCP relinked to the new files output from Color automatically—I didn’t have to re-edit anything. The trick here is to avoid using “Send to Color” after the first roundtrip; instead, launch Color directly and open the saved project. When Color re-renders a grade, it’s saved to the same location and filename as the previous grade, which gets renamed with a version number. When you switch back to Final Cut Pro, it will automatically link to the new render.
Transitions can be an issue: throw a multi-frame transition on a clip, and Color shows it as a straight cut. Normally, that’s not an issue, but if you have a traveling or motion-tracked vignette (correction window) on a clip, your ability to keyframe the vignette through the transition ends at the point where Color switches to showing the second clip (Color properly renders both clips through the entire transition, but it only shows you one or the other for any given frame in the timeline).
Two clips with a transition applied in FCP, and how they appear in Color. If you’re keyframing a vignette on the hero product in the first shot, you’re SOL (simply out of luck) once you pass the midpoint of the transition.
In such a case, simply move the overlapping clip to a separate video track before sending it to Color. Toggle between the two clips by toggling the upper tracks’s visibility in Color, and you can grade both clips for their entire visible durations. Upon return to FCP, move the overlapped clip back down into V1 and re-apply your transition.
Moving the first clip to a new track allows it to be fully keyframeable all the way through the box wipe.
And speaking of vignettes, user-defined shapes don’t appear in the right place once linked to a REDCODE clip if Color’s Playback Proxy is set to Quarter Resolution. Setting the Playback Proxy to Half Resolution solves this problem.
Gamma shifts are an issue roundtripping REDCODE through Color. If you want Color’s rendered clips to look like FCP’s originals, at least until you start applying corrections to them, you’ll need to apply a basic gamma correction of 0.818182 (1.8/2.2) in Color’s Primary Room.
The necessary gamma correction
Adding handles in Color’s Project Settings is a good way to hedge your editing bets with many formats, but not with REDCODE: the resulting renders are returned to FCP slipped late by the duration of the handle. Also, keyframed Color effects don’t take the handle into account when rendering, so they’ll all be offset early by the handle duration. Few things look dumber than a windowed correction bobbing around onscreen, out of sync with the object it’s supposed to be attached to!
Color always renders enough material to fully cover all transitions with handles set to 00:00:00:00, so just make sure your edit is truly locked before sending the timeline to Color, and leave handles off.
Next: Suggested RED+FCP+Color workflow…
Suggested RED+FCP+Color Workflow
I’ve developed a workflow that works for me. It lets me work using efficient ProRes proxies, easily re-ingest my timeline as REDCODE-native files for grading, color-correct in Color, and then apply any finishing touches in FCP. I keep all the flexibility to change REDCODE’s color and gamma spaces in the final grading, applying primary and secondary corrections to the original 4:4:4 12-bit files, and rendering out ProRes422 HQ files for final assembly.
Ingest clips as ProRes422 using Log and Transfer
I’ve already covered the basics of using Log & Transfer with REDCODE clips. My conclusion, after trying things several ways, is to ingest initially as ProRes422 (not HQ) for the best performance and least storage consumption during editing.
Yes, you can ingest as ProRes422 HQ, but that takes more space. I’m treating this initial ingest as an offline, so the slightly coarser rendering of plain ol’ ProRes422 isn’t an issue, and it still looks just fine for editing work: plenty of sharpness to see the nuances of expression and gesture on which editing depends.
You could also ingest as QuickTime-wrapped REDCODE files initially, but timeline performance, even on an 8-core MacPro, is less than entirely satisfactory. It’s a workable method for short tests, but I find the sub-realtime update rate of 2K REDCODE interferes with my editing efficiency. I’d rather take the time hit transcoding on the initial ingest in return for snappier timeline performance.
RED’s Ted Schilowitz also suggests using the camera-generated Quicktime reference files, specifically the “_M” 1K proxies, as an immediately editable format. That works, but (a) I find the 1K files don’t show me critical focus and other fine detail, and (b) media management becomes more of a hassle with this method. Using Log and Transfer to ingest the clips initially makes prepping for Color much easier, as we’ll see.
Edit your show
Edit as you normally would, with only a few complications:
- Set your sequence to the native frame size to avoid rescaling in Color. If your final output is a different size, you can deal with that by nesting the returned “from Color” sequence into a new sequence at the target size.
- Keep your RED-sourced clips on the lower tracks, like V1 and V2, and put other media on higher-numbered tracks. That makes it easier to isolate RED clips from titles, Motion files, and other media that you don’t need to send through Color. Of course, if you have non-RED media on the timeline that you do want to process through Color, put them on the lower-numbered tracks, too. I also like to keep V3 available as a “reference” track; I’ll put un-color-corrected copies of speed-changed clips there to aid in reconstructing the timeline after grading.
- Tag all RED media needing special handling: speed changes, freeze frames, motion-tab effects. That’ll make it easier to isolate those clips for special processing later. I find that assigning such clips a label color (Modify > Label) makes them easier to find in the timeline.
- Refrain from adding any color-correction filters in FCP itself. If you really must see how a clip will look, add a color corrector, then delete it when you’ve satisfied your curiosity.
Prep for Color
Here’s the cool part: if you’ve used Log & Transfer for the initial ingest, FCP remembers where your original REDCODE files live and remembers that they came in via Log & Transfer. FCP will take care of frame-accurate re-ingestion without your having to manually enumerate and re-transfer clips.
- Duplicate your sequence, so you have a backup in case you mess something up! It doesn’t hurt to save off a backup copy of your project file while you’re at it. I like to save the project under a different name, so that the retransfer step uses a different Capture Scratch subdirectory; that way the offline ProRes proxies I originally captured won’t be overwritten by online-ready REDCODE clips.
- If any gradable clips needing keyframing overlap in a transition, you’ll want to move one of the clips in the transition to another track, as described above, so that its entire duration will be visible in Color. (Don’t forget to turn off linking if your clip links audio and video, or the clip’s audio tracks will also want to move.)
- Open Log and Transfer. Set Import Preferences for REDCODE to “Native”. Make sure any needed source disks / directories appear in Log and Transfer’s media list, so that the source clips can be found.
- Select all the RED clips in your timeline (which is easy, because they’re the ones on V1 & V2, right?) and choose “Capture…” from the context menu. FCP will re-ingest the selected clips as REDCODE-native files.
- Take any clips with speed changes and move them into a new sequence, or to the tail end of the current sequence, removing the speed changes when you do so. (You may want to leave copies of speed-changed clips in the original timeline with their speed changes intact for reference, but move them to their own track, such as V3, to keep ’em out of Color’s way.)
- For freeze frames, replace each one with the single source frame of the original clip, and leave a gap for the rest of the freeze-frame’s duration.
Send to Color, Grade, and Send to FCP
Send your show to Color, grade it (remembering not to grade stuff on tracks 3 and higher), render to the codec of your choice such as ProRes422 HQ or Uncompressed 10-bit, and send it back to FCP.
You may find it easiest to work with the un-speed-changed speed-change clips, and match them to the looks of the main timeline, if you sent them to Color as part of the original sequence, tacking them on the tail end of track V1. Alternatively, liberal use of saved grades and a common still store pool shared across the two Color projects (created from the original sequence and the sequence of un-speed-changed clips) will help you keep things in sync, color-wise.
Re-integrate your FCP timeline
When the sequence(s) come back from Color, you’ll need to undo the changes you made prior to sending to Color. If you have the original sequence handy (the dupe you made before sending to Color), you might want to toggle between it and the “from Color” sequence for reference; alternatively you might find it useful to render out that original sequence as a standalone clip and drop it on the top track of the “from Color” sequence, where it can be toggled on and off as a quick reference.
- If you separated transitioning clips for grading by putting them on separate tracks, re-merge them on the same track, re-applying their transitions.
- Re-apply speed changes to the clips than need them, and re-edit them back into the original timeline as needed. Similarly, recreate Freeze Frames from their single-frame sources and put them back in their original places.
- If you need to change the pixel dimensions of the program, you can now nest the native-size sequence into one with the target size, or copy all the clips from the native-sized sequence to a new sequence at the target size (since all the clips are now safely out of Color’s clutches, resizing in FCP is a safe and clean thing to do).
- Apply any other Motion-tab effects.
Render and enjoy
If all has gone well, you’ll now have your color-graded show rendered out in the format of your choice. Just be sure to watch it very closely to make sure everything really made it through the whole process as intended!
Seem like a lot of work? It is when compared to the more streamlined process with FCP-native media types, but it’s still the least error-prone way I’ve found to get REDCODE media in an FCP project through Color’s sophisticated grading without “baking in” a look ahead of time, and without stumbling too much on the rough edges in the FCP/Color RED roundtrip.
Got any better ideas, or any improvements? Don’t be shy; let’s hear ’em…