In my previous RED+FCP article I looked at importing RED clips using Log and Transfer, and focused on using REDCODE-native files in FCP and Color. This time, after clearing up a nagging question, I’m going to concentrate on working with ProRes422 clips created with Log and Transfer, and fixing tonal scale issues caused by the camera’s View setting.
First, the nagging question. I said:
All my 2048×1152 REDcode clips are shrunk to 93.75% to fit into a 1920×1080 sequence. When I use FCP’s File > Send To > Color, grade my clips in Color, render, and then use Color’s File > Send To > Final Cut Pro, I get a new 1920×1080 sequence with graded 1920×1080 ProRes clips in it… shrunk down to 93.75%! I had to go through manually and reset the clips’ sizes to 100% to properly fill the screen.
I found this to be the case with REDCODE clips only: ProRes clips were properly sized in the timelines returned from Color. This sizing bug appears to be something unique to REDCODE clips sent from FCP to Color; I expect RED and/or Apple will fix it in the next spin of the software.
Now, on to Logging and Transferring REDCODE, transcoding to ProRes422, and dealing with the tonal scale.
If REDCODE works in FCP, why transcode to ProRes? One word: speed.
Using REDCODE-native QuickTimes on my 2.33 GHz MacBook Pro, I was seeing playback refresh rates around 6fps for a single stream of 4K media (the timeline played in real time, but I only saw six frames out of every twenty-four). Even those with 8-core MacPros are only seeing 24fps intermittently. I declared this “adequate”, as in, “I can see what’s going on, and I can hear the sound”, but it’s very much a dancing-bear kind of adequacy: the miracle of REDCODE-native playback on a Mac is not that it plays well, but that it plays at all.
As others have observed, the miracle wears off after a bit: you just want to get some flippin’ work done without having to render every effect and every transition just to get it to play, and without having to selectively render chunks of the timeline just to be able to see critical cuts at full frame rate, fercryinoutloud.
Transcoding from REDCODE to ProRes422 HQ on input gives you the needed speed, and with very little loss in image quality, but there is a gotcha: you bake in the basic “look” of the clip when you Log and Transfer it. Assuming you’ve gone through as described previously and done a simple “one light” grade in RED Alert, you’ll have all the tonal scale info you need for further grading, but the color space and gamma space used—Rec.709 vs. REDSpace—will be determined by how you shot the clips, not by the changes you make in REDSpace (remember, when using REDCODE-native clips you can change these in Color, using the Primary Room’s RED tab, but with any transcoded clips, what you get on ingest is what you’re stuck with thereafter).
In what follows, I’m going to go through a lot of work to “unbake” REDSpace gamma from some FCP-ingested clips and recover the look of RED’s Rec.709 gamma—maybe too much work. You might well ask, “why bother?”, and I’ll answer with a range of “becauses”:
- You might want to use the ProRes clips as-is, as online media, and not bother with the whole offline/online hassle.
- Even if the ProRes clips are only offline proxies, you might want to see an offline that’s closer in appearance to a final, graded online.
- You might want to see what’s involved, and how choice of a shooting setting (Rec.709 vs. REDSpace) affects your ingested clips, even if you vow never to do this, ever, because you’re just way, way too clever for all this foolishness.
I used Log and Transfer in FCP to ingest some RED clips that had been shot using the REDSpace setting in the R1’s “View” menu. REDSpace is handy for shooting because it give a brighter and snappier monitoring image, and REDSpace color rendition is far better than the R1’s Rec.709 color rendition (as described here using Camera RGB, which tracks REDSpace very closely aside from a lack of saturation).
I also had a “one-light workprint” I’d rendered to ProRes in REDCine, using REDSpace color and Rec.709 gamma. Try as I might, I could not get the FCP-ingested clip to match the REDCine clip; the FCP clip was contrastier and had crushed highlights and shadows.
The REDCine “workprint” (with filename and timecode burn-ins), before grading.
FCP’s ProRes version, before grading (different color balance used on ingest).
Note especially the differences in the sky, both in the pix and the WFMs. I had a lot of leeway tweaking the sky in the REDCine clip, but try as I might I couldn’t get any decent results in the bright part of the sky using the FCP-ingested clip, either in FCP or in Color. Similarly, the shadows in the FCP ingest blocked up compared to those in the REDCine transcode.
What gives? I had thought that REDSpace gamma was just a “brighter” gamma than RED’s rendition of REC.709; after all, displaying a properly-exposed chip chart on the WFM using either gamma showed similar results. A bit of exploration in Color showed me how wrong this assumption was.
I took some REDCODE exposure tests I’d shot a while back, zoomed in on the chip chart, and looked at Color’s waveforms (in parade mode simply because it’s prettier, grin). Yes, “normal” charts looked very similar, but check out the flattening of highlight and shadow contrasts when decoding with REDSpace:
Dark, “normal”, and bright frames decoded with Rec.709 gamma
Dark, “normal”, and bright frames decoded with REDSpace gamma.
(Note that I chose the dark, “normal”, and bright frames in those two different decoding tests separately; they aren’t the same actual exposures in the two different tests, rather they were chosen for the graphic nature of their waveforms.)
Two things leap out at me from these images:
- REDSpace is contrastier than Rec.709 in the midtones.
- REDSpace adds aggressive S-curves to, and thus compresses, both shadows and highlights; Rec.709 stays very “linear” by comparison.
When I say “linear” here, I’m not referring to “linear light” encoding (gamma = 1.0), but a “perceptually linear” tonal portrayal, one that visually matches the original scene’s tonal scale when viewed on a monitor. One way to think of it is that in such a perceptually linear decoding, the steps on the chip chart form linear diagonals, not curves. A visually “linear” gamma in this sense would be an encoding gamma of about 0.45, assuming a display gamma of about 2.2, but that’s a topic for a different discussion.
This matches what I saw in my real-world comparison, but it’s nice to have confirmation: REDSpace is taking liberties with the tonal scale for a snappier image, but those liberties may not be the one you want taken in post: I like the open shadows and gentler sky gradient in REDCine’s Rec.709 gamma rendering. REDSpace gamma is very nice for on-location monitoring, but as a postproduction transfer curve I find it too limiting, too “pre-deterministic” about how I wanted to handle the gradations in the scene.
My first thought was to set up a one-light grade in RED Alert that avoided the highlight and shadow regions, so that my tonal scale would be more “linear” across all regions of interest, and I’d have more ability to fiddle with it in the ProRes clips.
Default RED Alert settings, and the histogram for the outdoor scene.
A “flat” setting designed to keep scene tones away from the extremes.
I saved this flat setting out of RED Alert as a preset (imaginatively calling it “flat”), and returned to FCP, where I used it in the Log and Transfer window as my preset for another ingest:
An FCP ingest using the “flat” preset.
The original FCP ingest, for comparison.
Compared to the original ingest (and bearing in mind that the two presets used different color balances), the flat version has more tonal scale variation in the sky and in the shadows. It is flatter overall; the image is squeezed into a narrower tonal range. Yes, I lose a bit of fine tonal discrimination by doing so, but I’m counting on the 10-bit-deep ProRes codec to have precision to spare, assuming I don’t have to do any extreme grading changes (and if I’ve set up my initial RED Alert preset properly, I shouldn’t have to).
The proof is in the pictures: I took all three clips and did a quick ‘n’ dirty color grade to match them up roughly, just using FCP’s Color Corrector:
The REDCine, Rec.709 gamma clip.
FCP’s original ingest (using REDSpace gamma).
The “flat” ingest (using REDSpace gamma).
The sky is definitely better in the “flat” clip than in the default ingest, though it’s still a bit squashed in the highlights compared to the Rec.709 transcode. (And yes, it’s a rough match.)
Playing back a four-second selection of all three clips back-to-back showed no noticeable increase in noise or artifacts in the “flat” clip compared to the others; even with the flat clip’s compressed tonal scale, ProRes had enough precision to capture the RED image faithfully and preserve it through two generations of rendering.
To go one step further, I tried taking my clips and grading them in Color, where I could apply an “inverse S-curve” to the REDSpace-gamma ingests:
Setting up an “inverse S-curve” in Color’s Primary room
In this manner I was able to get both REDSpace-encoded clips even closer in appearance to the Rec.709-encoded clip, though each time I modified the luma curve I had to go in and tweak saturations, too.
In short: if you bake the “wrong” gamma into your ProRes clips, you can fix it in post, albeit with a fair bit of faffing about.
This may be overkill for most situations: if you want Rec.709 gamma encoding but the camera recorded using REDSpace gamma, or vice versa, you’ll probably either make your ProRes clips in REDCine or REDRushes, or you’ll online the show using REDCODE-native clips and change the gamma space in Color. But you may not have that luxury; the schedule or the budget might not allow leisurely rendering in RED’s apps, or the two-step offline/online process, so knowing some coping strategies in Final Cut Studio can be a useful thing.
And who knows: with the next release of RED plugins and/or the next version of FCP, the rules may change. We might be able to take advantage of color space, gamma space, and curve settings from RED Alert, and be able to tweak image-decoding parameters completely during Log and Transfer. When that day comes, we’ll look back on articles like this and laugh—but until that day arrives, forewarned is forearmed.
See also:
3 Ways to Get RED Footage into Final Cut Pro, by Scott Simmons
RED+FCP: Native REDcode Importing