Red .R3D render speeds in Color – sloooowww
Good news/bad news –
Good news – the new Apple Color version 1.5 (part of the new Final Cut Studo) reads R3D files natively – you can even start a new project and pull in a clip! You have controls for directly accessing the 12 bit RAW Redcode controls in the Primary Color room – this is great! It also does a full resolution, high quality debayer, which is the highest quality way to do this – better than the half res solution that Final Cut Pro utilizes. For the money, this is definitely the easiest, highest quality, most control solution for grading your Red footage. All good news.
Bad news – for now, it is SLOOOOOOOOW – on an maximally pimped system*, it was rendering about 1.43 fps – so about 17 times slower than realtime. And this was only with a simple lift/gamma/gain adjustment, no color adjustments, no secondaries, no filters, no rescale, etc., all of which can make the process take even longer. Ouch! Here’s to hoping that Apple will support the Red Rocket card to accelerate debayering and scaling of Red .R3D files directly within Color in a future version.
Read on for details.
Quality nurd that I am, I like this approach. But with no network render solution offered, only the indies with waaaaaaay more time than money can afford to sit around with their station tied up rendering. For example, based on that clip test I did, rendering the following would take:
30 second commercial (all cuts no dissolves): about 8 1/2 minutes (client survivable – get coffee or talk/distract)
your 10 minute short film: about two hours and 50 minutes – go take a long lunch and/or see a movie
90 minute feature: start it on Friday afternoon, or be ready to take the next day off, because it’ll take about 25 hours to render
Realistically, you render bits of it as you go, so it isn’t likely that you’d really wait and do it all at once, but I’m just sayin’.
* OK, definition of terms
Test system :
8 core Nehalem Mac Pro with the ATI 4870 card and 12GB RAM running OS X 10.5.7, running Color 1.5
Test clip: Red 4K 16:9 Redcode 36 from Build 20, 3 minutes, 14 seconds, 9 frames long, took about 53 minutes to render with Lift/gamma/gain adjustments made, rendering out to ProRes4444 (Apple’s new high quality codec, here used for full range RGB 4:4:4) for a 1920×1080 file, Color set to 12 bit pixel format (as opposed to 8/10/16/32 bit other options – I just left it where I’d last used it)
Also interesting to note that CPU utilization was only about 250% (of a possible 1600%) – so clearly there is room for substantial optimization – doing the dumbest possible, most unlikely it’ll work this way napkin math, that seems to offer a theoretical improvement potential of about sixfold , which would get us to about 9 frames a second rendering (again, probably math doesn’t work this way, I’m just napkin sketching here) which would be, theoretically about 1/3 realtime in that theoretical scenario. Disclaimered enough?
That’s all for today.
Oh, other tidbit I’ll expand on later – preliminary testing on Red Rocket with their latest shipping build 661, looks like ProRes renders about twice as fast as DNxHD, and 720p renders out about twice as fast as 1080p. Hmm.
UPDATE Charles in the comments points out that the “color” portion of color is done on GPU, which doesn’t show up on CPU activity. AFAIK, it works something like this:
-source R3D is read in, debayered at full 4K res on CPU, based on settings in Red tab in Primary In color room
-scaled to 1080p (somewhere in here) on CPU, MAYBE on GPU
-coloring adjustments (like my lift/gamma/gain) done in Color are executed on the GPU – the RGB image and instructions are sent over the bus to the GPU, changes made, and the results sent back across the system bus
-CPU then compresses to codec of choice to disc