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

Filed under: Editing •Post Production •

RED+FCP+Color: Making It All Work

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…

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

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: