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

Filed under: Editing •Post Production •Vendor Blog •

RED+FCP: Native REDcode Importing

Changes in Color

In Color, you can import RED clips directly from the R3D files, or from Logged & Transferred QuickTimes in Final Cut.

Browsing a RED “folder” in Color.

Note that Color shows a REDcode clip’s timecode using the time-of-day timecode. If you’ve set up the camera to use edge code for the displayed timecode track, FCP’s Log and Transfer shows edge code, but Color still shows time-of-day (regardless of whether the clip is a raw R3D or a Logged and Transferred QuickTime). This display discrepancy doesn’t break sending an FCP project using edge code to Color, but it can be a bit disconcerting.


As in FCP, Color halves the size of 4K files, importing them as 2K. Unlike FCP, Color also haves the size of 3K files, whether loading them directly or through an FCP-logged QuickTime.

This asymmetry of treatment makes 3K RED-native files problematic in an FCP/Color workflow; you might find it useful to work with 3Ks for some room to zoom / motion-stabilize / pan ‘n’ scan, but Color will return you 1.5K rendered versions—probably not what you were hoping for! If 3K is in your plans, you should render it to ProRes, uncompressed, or another format before sending it to Color, and bear in mind that Color can’t work with project resolutions beyond 2K regardless of how the clips come in.

The installer adds a RED tab in the Primary room:

Fiddling with REDcode raw decoding in Color.

FCP-imported QuickTimes come in with their color temperature, tint, and other parameters intact; if you brought them in with a look created in RED Alert, those settings persist. If you bring a raw R3D file in, you get the look metadata set in the camera during the shoot.

You can tweak the RED tab parameters to affect how the raw data is decoded and deBayered (crucially, you can change the color space and gamma used for the decoding/deBayering in Color, which FCP does not allow you to fiddle with). Since tweaking happens with the full 12-bit raw image, you’ll preserve quality by making these changes in the RED tab compared to making comparable changes “downstream” in the primary in, secondary, and primary out rooms.


I only ran into one issue with the FCP-Color roundtrip, and that may be due to my unfamiliarity with the workflow. All my 2048x1152 REDcode clips are shrunk to 93.75% to fit into a 1920x1080 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 1920x1080 sequence with graded 1920x1080 ProRes clips in it… shrunk down to 93.75%! I had to go through manually and reset the clip’s sizes to 100% to properly fill the screen. (I’m sure that someone will add a comment telling me what I should have done to avoid this problem… please!)

Quality

• 2K and 3K files import at full resolution and size, equivalent to choosing “Debayer Quality: Full Res” in REDRushes.
• 4K files come in at half size using “Debayer quality: Half Res (Standard)” by default; you can change this to “Half Res (High)” if you prefer.

If you want to tweak 4K decoding, use the System Preferences REDcode control panel. This requires installing the v.3.5.0 (beta) QuickTime codec to get the control panel—yes, I know it’s an older version than the one that’s in the RED FCS Installer. Quit whining, willya?

The REDcode settings option appears in the “Other” section of System Prefs.

REDcode settings in 10.4.11. Whoops! The SysPrefs window isn’t wide enough for this panel, which was designed for 10.5. (The settings work nonetheless.)

REDcode settings look a lot better in 10.5.5, and work the same way.

You are offered three simple choices:

• Half High: Higher-quality, but slower decoding.
• Half Standard: default; roughly twice as fast as Half High, but slightly less accurate.
• Auto: The codec chooses based on what the app requests: REDcode-native clips are rendered in standard or high quality depending on whether the timeline is set for 8-bit or higher quality rendering. Clips transcoded to ProRes422 during Log and Transfer always seem to transcode as High quality in Auto mode.

The quality of the decode appears to be identical to the standalone RED tools given the same parameters. As discussed above, if the same gamma and color space parameters are used in REDrushes or REDCine as in FCP, the color and tonal scale of the FCP-imported clips will match those of clips from the standalone RED tools, with one exception: FCP-imported clips have darker midtones.

This is the same 1.8 vs. 2.2 gamma shift that has plagued FCP users for years, and no, setting user preferences to import RGB at a 2.20 gamma level won’t fix this one: the gamma shift appears to be hardwired. You can match things after the fact by adding a gamma correction of around 0.82 to the FCP-imported clip, or a 1.22 correction to the RED-transcoded clip, and then adding minor gain and saturation tweaks as needed. Tedious, but workable.

High quality debayering takes roughly twice as long as Standard quality on my MacBook Pro, but the actual time ratio seems to depend on clip content; I’ve seen time ratios ranging from 1.4:1 to 2.3:1 depending on the clip.

High quality is very slightly better than standard: at first glance, a High quality and a Standard quality clip are identical. It’s only when one looks at pixel-level details that one sees marginal improvements in the High quality images compared to Standard. Even then, one might prefer Standard: it’s a bit coarser, but a bit sharper looking.

For most HD shows, I might not sweat the difference. For film-out, or if I’m feeling really finicky, I would. All the following images are from ProRes422 HQ renders:

An entire frame (4K 16:9 original, REDCODE 36 capture).

Detail: Standard quality half-res decode to 2048x1152.

Detail: High quality half-res decode to 2048x1152.

Of course, there’s just a tiny increment more detail in a full-res 4K decode, which gives the sharpness of Standard but with smoother diagonals and contours:

Detail: REDrushes full-res decode to 2048x1152.

That’s the advantage of supersampling; 4K of data in a 2K frame looks better than 2K of data in a 2K frame.

Of course, a full-res decode takes about four times as long as a half-res decode, whether using REDCine or REDrushes; whether the slight increase in detail is worth it given the time hit is something you’ll need to decide for yourself (but then, if you’re on a time-sensitive schedule, you’re probably using, or should be using, an Octocore MacPro—or several of them—to crunch your data for final output).

Don’t worry if the differences don’t leap out at you; they’re subtle. You might better be able to see them by downloading the images, enalarging them 2x or 3x, and flipping between them. Arguably, if you have to go through this much work to see the differences, then “half standard” is good enough for real-world work, or “half high” if you’re really picky—and practically speaking, there’s probably not a lot to be gained from a slow, full-res decode of a 4K image at 2K size.

For resizing the 4Ks, the standalone RED tools let you choose the resampling filter, while the Log and Transfer plugin does not. For what it’s worth, I normally use Lanczos filtering in REDrushes for downsampling, and the Logged and Transferred clips look identical in the fine details. I haven’t done any side-by-side tests with other REDrushes resampling filters yet, but I haven’t found anything to complain about with Lanczos (which, like sinc, is frequently recommended for downsizing images).

Performance

I measured performance using a couple of half-minute clips, and also when processing all 24 minutes from a recent fake commercial shoot. I saw a fair amount of variance in performance using the standalone RED tools, with some test running about 30% faster at some times than at other times. Generally, the faster times were seen on the single clip, with the slower times on the entire show, but sometimes I’d see variance even on the same clip. Based on this, and on the nature of my setup, take my performance numbers as rough indicators only, not firm measurements.

All my performance measurements were done on my dual-core 2.33 GHz MacBook Pro, reading and writing to a two-drive ESATA RAID 1 (using OS X’s software RAID, so writes require twice the data transfer that reads do). I used 4K 16x9 (4096x2304) REDcode36 originals, which were converted to 2K 16x9 (2048x1152) clips in all the methods I tried.


Importing REDcode into FCP is much like importing DVCPROHD from a P2 card: you’re simply rewrapping the native essence in a QuickTime wrapper. It’s a lot faster than transcoding, taking about 1.6:1 to 2:1 to transfer, or about 60% longer than real time to 2x real time. That’s mostly I/O time; the lights on my ESATA card were almost constantly illuminated.

Importing ProRes422 HQ at standard quality ran at about 8:1, or 8x real time. That’s not fun, but consider that the same transcode done in REDrushes took about three times longer (23:1 to 27:1), and REDCine, transcoding at “standard” quality, took twice to three times as long (16:1 to 26:1).

Clearly, on a dual-core machine, Log and Transfer is a much quicker way to generate ProRes 2K clips than the standalone tools. (Posts on reduser.net imply that 4-core and 8-core machines fare considerably better with the standalone tools, using all cores, while Log and Transfer does not scale quite so well across more than two cores. Once I get my hands on an 8-core machine, I’ll test the tradeoff myself.)

Bumping up to high quality led to an increase in ProRes transcoding times: Log and Transfer ran at about 18:1, while REDrushes took 37:1, or twice as long as Log and Transfer.

For comparison, a REDrushes export at full, 4K debayering quality took 128:1, while REDCine’s full-quality transcode took 69:1.

While Log and Transfer is the clear winner here, I think it’s safe to say that regardless of transcode or transfer methods, you probably don’t want to crunch all the data for your feature, or even a half-hour TV show, on a solitary MacBook Pro!

As far as playback goes, I was pleasantly surprised. When I dropped my 2048x1152 REDcode-native clips into a 1920x1080 sequence, and turned on Unlimited RT with dynamic quality and dynamic frame rate, I got a solid 6 fps update rate and continuous sound, and that’s with a second display showing Digital Cinema Desktop output (Video Scopes, however, refused to play in real time with either REDcode-native or ProRes 2K files). During playback, image resolution dropped perhaps by half, but it was still fully usable, and it sharpens up as soon as the playhead is paused.

If I selected high playback video quality, I still saw 3-4 fps updating, with a pin-sharp display.

Setting REDcode preferences to “Half High” slowed high-quality playback to roughly 1 fps, but didn’t affect dynamic-quality playback speed.

(By comparison, ProRes-coded 2K clips play back at what appears to be around 12fps in dynamic quality, or about 8fps at high quality: the slow playback appears to be due to the resizing needed to fit a 2K clip into a 1080p timeline; 1920x1080 ProRes clips plays at high quality at a full 24fps.)

If I left playback quality at dynamic but set playback frame rate to Full, I was able to get 10-12 fps from the REDcode clips (after turning off “Report dropped frames during playback”), and 24fps from the ProRes clips, even as they were being resized to fit the 1080p timeline.

Turning on both full frame rate and high quality proved to me that quality wins for REDcode footage: sharp, 3-4fps playback, or 1fps with REDCode prefs set to “Half High”. But I don’t recommend this; it made the Mac cranky. I’d sometimes see a brief spinning pizza of death when I started playback, as the MacBook Pro futilely tried to preload enough frames for full-frame-rate work, and its responsiveness to mouse clicks or keypresses slowed down. High speed or high quality is the way to go to on a MacBook Pro: I found that the blurrier 12fps playback with “full” frame rate was surprisingly usable.

Overall, performance, even on a MacBook Pro, is adequate for ingesting and editing short projects, like the :30 spoof spot I’m currently cutting. ProRes transcodes complete in an acceptable amount of time, and even REDcode-native10-12 fps is tolerable for rough cutting, when I choose to preserve the raw files through my editing process. I can cut long, or at least choose my selects; export the project to Color for grading, and then finalize my edit using the ProRes clips output from Color.

Still, I’d want more cores to throw at the problem for longer-form work, especially if there’s a client looking over my shoulder instead of simply reviewing exported versions.

The whole process feels very much like working on DV25 footage in the early days: I had to set my Canvas to 25% on my 233 MHz Wallstreet G3 Powerbook to get full-frame-rate playback in FCP 1, and onscreen playback was always fuzzy (the G3 just didn’t have the oomph to fully decode DV25 in real time). The DV25 editing experience got better; the RED cutting experience will grow better, too.

Now, where can I find an Octocore MacPro (or five) on the cheap, eh? 

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

Why does “Detail: Standard quality half-res decode to 2048x1152” appear to be the sharpest?

Posted by Kendal Miller  on  01/28  at  01:32 PM

---

“Wow great article” - Thanks, Phill!

“Why does ‘Detail: Standard quality half-res decode to 2048x1152’” appear to be the sharpest?

Funny, isn’t it?

I’m not privy to the details (pun intended) of REDcode decoding, but in looking at a variety of shots, I might hazard a guess that “Half Standard” decode just pulls out 2K data and doesn’t attempt to perform any low-pass filtering on it (since REDcode uses wavelet coding, you can literally pull out half-res, quarter-res, or any other inverse-power-of-two subsampled set of data). Transitions are a little bit sharper as a result, but diagonals are a bit more jagged and tonal transitions overall seem a bit harsher, a bit more coarse.

At least, that’s what it looks like, even if I have the mechanism entirely wrong—which is quite possible, grin.

“Half High” does look softer, but fine details are a bit smoother, especially on the diagonal. And “Full” decoding is even smoother than “Half High”, while looking nearly as sharp as “Half Standard”; it’s clearly the best (even if you have to squint to see it). In real life it’s not clear that the increase in quality is worth the longer rendering times: for a feature, sure, no worries, but for an episodic TV show on a tight schedule? How many MacPros can you afford to throw at it?

Even so, image quality is subjective. The sharper image may not be as accurate, but it may be more pleasing, depending on the subject and on your preferences. There isn’t a right answer, just what’s right for you. At least the RED preferences let us choose between Standard and High.

Posted by Adam Wilt  on  01/28  at  05:45 PM

---

“The sharper image may not be as accurate…”

Indeed. I have participated in image quality shootouts where quite literally, one man’s aliasing artifacts is another man’s sharpness. It’s certainly a case where you need to judge a moving image (to see if that sharpness ends up sparkling, indicating aliasing), rather than bet the farm on one still…

thanks again for the great article -
Chris

Posted by Chris Meyer  on  01/30  at  10:31 AM

---

Adam, any chance you can get your PVC overlords to supply a “print” link?

Articles like this are perfect to print out for my commute.

Even better would be a pdf link to send to my Kindle (though all your pretty pictures would get seriously mangled).

Anyway, thanks for the article.

Patrick

Posted by Patrick Inhofer  on  02/07  at  12:16 PM

---

My PVC overlords tell me it’s on the to-do list. Until then, copying content to a word processor and printing it to a PDF is probably your best pathway to portability.

Posted by Adam Wilt  on  02/07  at  01:53 PM

---

Whew .... I don’t know how anyone can look at the less that 24fps playback frame rates of RED proxies and “native” RED QuickTimes and call that acceptable playback frames rates for an edit. I can’t even rough cut and barely view footage with that kind of choppy playback…. much less do any kind of real editing. And I’m doing this on a Mac Pro with all 8 cores humming!

As someone who sits in from of RED edits for days and weeks at a time it’s transcode to ProRes for the offline 100% of the time. I just can’t handle it any other way!

Posted by Scott Simmons  on  02/09  at  11:19 PM

---

“I don’t know how anyone can look at the less that 24fps playback frame rates of RED proxies and ‘native’ RED QuickTimes and call that acceptable…”

Grin. I said adequate, not acceptable (or desirable!)—and I sure wouldn’t want to do it on anything longer than a :30 spot with about 12 shots in it!

But even there, I’m coming around to your way of thinking; I’m working on ProRes versions of the clips now, and trying to decide whether to do a 1-light grade in REDCine and then doing my final cut with the ProRes, or whether to just Log & Transfer ProRes copies as offlines and then conform a REDCODE timeline thereafter (using various matchback tools, or just the Media Mangler), or do other things altogether.

Why all this madness? I’m using this :30 as a workflow development and testing tool for longer-form work coming up; I want to try working through many (if not all) of the possible transcoding pathways and offline/online workflows and get a feel for the speed / quality / simplicity tradeoffs.

I’ve been spoiled enough by FCP in the past few years that I don’t want to return to the bad old days of the offline / online dichotomy. I’ve gotten used to ingesting both SD and HD video in high quality, editing with it, and outputting finished product—so much nicer than cutting 3/4” dubs linearly, or tape-splicing 16mm workprint and adding grease-pencil dissolve marks! So I’m trying to find a way (or several ways) to preserve that WYSIWYG simplicity with no loss in quality while working with R1 files. It may NOT be that simple, but I’m stubborn, and I learn interesting things along the way…

You say you’ve got an 8-Core MacPro. What sort of playback frame rates can you get out of that beast with REDCODE-native files?

Posted by Adam Wilt  on  02/10  at  01:44 AM

---

I can get decent 24 fps playback on the Mac Pro about 3/4 of the time. That’s a single layer only, Unlimited RT, quality set lower. It might work fine one day and literally the next day it drops frames. But that goes back to my point that IMHO you can’t do “real” editing in Unlimited RT. Started adding transitions or fx or grouping a music video or multicam shoot and wham! No more even Unlimited RT.

If you had the fasted Mac with the fasted hard drives on a very slim system with no background processes and no internet surfing then you can get decent playback though I don’t think it’s acceptable for anything other than a simple single layer edit.

The whole offline - online thing? Yea, know what you mean. Everything new is old again huh?

Posted by Scott Simmons  on  02/10  at  07:43 AM

---

8 core indeed - the lotto tickets are looking more enticing, lol

I have a MBP and trying to do something in RED Alert is an exercise in madness. I seem to remember Scott saying something about RED Rushes taking forever (twitter)? Sorry if I miss quoted you. One 2K layer in FCP is not too bad, even Shake was relatively smoothish when keying.

But I am forced to work with the 2K or 1K proxies (offline?)
My question us how do you go back online to 4K? Maybe with the final output being web/dvd/blu-ray you don’t need to go back to 4K, but then what is the point in starting with 4K if you can only use the proxies and output at 2K or less? Well like you say the 2K images derived from the 4K ones is better, if that is what u meant by: “That’s the advantage of supersampling; 4K of data in a 2K frame looks better than 2K of data in a 2K frame.”.

Personally I would prefer to edit and key in 4K, but I have go offline to 2K because Shake and FCP and Color only do up to 2K

Something to see in FCS3? But then again how can you monitor 4K? You would need to down convert or used some really specialized equipment.

hmmm

Posted by Synaptic Light  on  02/10  at  08:12 AM

---

“[Y]ou can’t do ‘real’ editing in Unlimited RT. Started adding transitions or fx or grouping a music video or multicam shoot and wham! No more even Unlimited RT.”

Not as such, no; it’s add / render selectively / play, much like doing stuff in tape-to-tape: program, preroll, perform, review. It works—not quickly, true, but it works. But yeah, for multicam it’s hopeless. Online using ProRes422HQ, or offline with ProRes or DVCPROHD and then conform REDCODE.

“[T]rying to do something in RED Alert is an exercise in madness.”

Well, we all need our exercise…

“[H]ow do you go back online to 4K?”

Currently the only ways are outside the FCP/FCS universe, using REDCine, Scratch, SpeedGrade, or the like.

But do you really want to? (That’s a rhetorical question; the practicality and financial tradeoffs of a 4k finish vs a 2k finish are topics too large for a mere comments section.)

“But then again how can you monitor 4K?”

You’re in luck: Sony is having a blowout sale on B-stock and demo SXRD 4k projectors. You can get a DVI-equipped 5,000 lumen SRX-S105, normally $78,000, for only $39,000 if you buy before March 20.

Piggy banks throughout the post world are quivering in terror at this news.

Posted by Adam Wilt  on  02/10  at  10:52 AM

---

“I seem to remember Scott saying something about RED Rushes taking forever (twitter)? “

I have had problems with REDrushes crashing when I give it a very large batch to render. It’s fast when it works though!

Posted by Scott Simmons  on  02/10  at  04:57 PM

---

cool, I am still to Try REDrushes
Sony 4K cameras, hmmm, glad my interest worries about them and not my budget - at half price is still a big investment.

Looking forward to try Redrushes and REDCine
and learning (which get accelerated because of you guys - thanks)

Phill

Posted by Synaptic Light  on  02/10  at  11:00 PM

---

Adam,

Good article. Finally had the time to sit in front of my computer and digest.

“All my 2048x1152 REDcode clips are shrunk to 93.75% to fit into a 1920x1080 sequence.(I’m sure that someone will add a comment telling me what I should have done to avoid this problem… please!)”

1080/1152 = 93.75

But the aspect ratios are the same, yes? I’m thinking this is probably originating in Color with that mystical “resolution preset” project preference which is trying to fit the 1152 width onto a 1080 frame. For all its complexity Color sometimes has an IQ of 40.

Like you say in the follow up article - probably an issue that the ProApps folks have to fix.

- pi

Posted by Patrick Inhofer  on  02/12  at  09:51 PM

---

“1080/1152 = 93.75”

Yes, indeed: that’s the shrinkage that FCP put on the 2K clip originally to fit it into an HD sequence. I just didn’t expect to see Color apply that same shrinkage to the 1920x1080 clips it renders out when it exports the sequence back to FCP.

As I note in the follow up article, 2K ProRes clips are not treated the same way; they get rendered to 1920x1080 but are placed in the exported sequence at 100%, so it appears to be Color getting confused by some of that RED “mysterium”, grin.

Posted by Adam Wilt  on  02/12  at  10:00 PM

---

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?