(Page 1 of 2 pages for this article  1 2 >)

Filed under: Editing •Post Production •

RED+FCP+Color: Making It All Work

I had previously reported that 2K REDCODE footage (2048x1152), shrunk to 93.75% to fit an HD timeline in FCP, came back from Color as 1920x1080 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 2048x1152 down to 1920x1080) 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 1920x1080, not as 2048x1152. 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 2048x1152 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” (3840x2160) which FCP resizes directly to 1920x1080 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 16x9, both 4096 pixels wide, or true 2K, FCP brings those in as 2K (2048 wide), which needs that 93.75% resizing to fit a 1920x1080 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 16x9 (which FCP treats as 2K 16x9) 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 1920x1080 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…

(Page 1 of 2 pages for this article  1 2 >)

I have had issues with making a .8 gamma correction in Color. I have found setting my monitor gamma to 2.2 for Color, and 1.8 for FCP to work nicely.

Posted by Charles Angus  on  06/02  at  10:27 PM

---

Issues? What sort of issues?

How do you reconcile the differences in monitoring gammas between the apps? How do you conform your materials to a common specification when all is said and done?

Posted by Adam Wilt  on  06/03  at  12:45 AM

---

Do have any suggestions if you shot 2k, 3k and 4k?

Posted by .(JavaScript must be enabled to view this email address)  on  06/03  at  02:59 PM

---

I reconcile the difference in monitoring gamma by changing the monitor gamma, as I said. I have tried this and compared it to a KONA output, and it looked as similar as can be expected (considering the differences between computer displays and broadcast monitors).

FCP expects a monitor gamma of 1.8, and Color expects a monitor gamma of 2.2 - I just keep two profiles, and switch as necessary. Shake also expects a monitor gamma of 2.2, and also requires the 2.2 monitor gamma profile.

So, if you use each app with the correct monitor gamma, everything seems to work OK.

The issue I had is that it seemed to me that adding a .818 gamma correct in the primary out room didn’t seem to concatenate perfectly with my primary in corrections, even when rendering in floating point. Maybe I’m crazy, though.

Posted by Charles Angus  on  06/03  at  03:00 PM

---

“Do have any suggestions if you shot 2k, 3k and 4k?”

Treat 2K and 4K the same way. 3K doesn’t fit into a standard frame size, but the same guidelines can be applied: try to avoid resizing/rotation in Color. All the other tweaks (speed changes, overlapping clips, etc.) work the same way regardless of size.

“FCP expects a monitor gamma of 1.8, and Color expects a monitor gamma of 2.2 - I just keep two profiles, and switch as necessary. Shake also expects a monitor gamma of 2.2, and also requires the 2.2 monitor gamma profile.”

I wasn’t concerned about how the footage looked in Color vs how it looked in FCP; I was concerned that footage I sent to Color from FCP *came back* looking identical, assuming I didn’t do anything to it in Color. Since Color renders an RGB format (REDCODE) to YUV (ProRes) in my workflow, QuickTime’s screwy gamma assumptions much with the midtones; the 0.8182 correction counteracts that.

(I should also mention that I have FCP set up to assume a 2.2 gamma on RGB imports, not the default “Source” setting.)

“The issue I had is that it seemed to me that adding a .818 gamma correct in the primary out room didn’t seem to concatenate perfectly with my primary in corrections…” I applied my correction in Primary In, not Primary Out. Maybe that’s the big difference?

Posted by Adam Wilt  on  06/03  at  11:29 PM

---

Hi, great thread, especially for the gamma issue. The best way we found is:
1 transcode R3D with clipfinder to 1k+ high proresSQ
2 edit in fcp
3 export the fcp xml
4 import the xml in clipfinder and run conform fcp xml (this will replace the proresSQ with F,H,M or P proxies)
5 import the new xml into fcp
6 prepare the timeline and send to color
7 close color project
8 import color project into clipfinder and run the command “fix looping bug in color project” (it’s instantaneous)
9 reopen color project, grade and render
10 send to fcp, finalize and output

Posted by luca immesi  on  06/04  at  02:42 PM

---

i have been using clipfinder to reconform back to the R3d files via the qt reference movies

I did find some issues around frame sizes of sequences using this technique

what I did was to send to color and then set my output frame size to 2k 16.9 and proreshq for the output settings

in the geometry room I presumed that all the settings were now wrong and that when working with red r3d files it is using the DPX style resizing Apple Color is designed for (the scaling is done in color not FCP when using image files rather than video files)

so I reset all the geometries using reset all in geometry room and left as this, it should work at 100%

if I needed the fcp proreshq 2k files to scale to 1080 I just used the Kona card and its 1080 easy setup, if working with 24p then it is possible to get an easy setup at 2k, this seemed impossible with 25fpx PAL however, so I went 1080 instead.
this could have been achieved by nesting sequences like you have suggested

basically main part of story is, RED onlining is not the most intelligent when trying to recreate the effects within a sequence, if the offline editor thinks of it as what it is (film quality and therefore tricky) then these expectations dont come up, the scaling etc gets done at online stage

Posted by bongiben  on  06/08  at  03:21 AM

---

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below: