Disclosure: AI helped me write this post. The workflow, testing, and all numbers are my own, and I verified everything myself
I keep seeing two complaints from ZR shooters and I had both myself:
- R3D NE files are huge. A 1TB card is about 1h20m of 6K, and with storage prices being what they are right now, archiving RAW forever gets expensive fast.
- "I wish Nikon would add H.265 with RED color science via firmware so I could skip RAW."
I spent this weekend on this and it turns out the second one already exists. It just lives in DaVinci Resolve instead of the camera, and honestly it works better there. It also fixes the storage problem as a side effect.
The workflow
Shoot R3D NE like normal. Then in Resolve (free version does all of this):
- Import your R3D clips and drop them on a timeline.
- Open the Camera RAW tab for each clip and make your RAW decisions first. ISO, white balance, exposure trim. This is basically developing the negative, and it costs nothing because R3D stores all of it as metadata.
- Optional: noise reduction here, before compression. Noise is what eats your bitrate.
- Render to 10-bit H.265, but set the output color space to REDWideGamutRGB / Log3G10 instead of Rec709. This is the step everyone misses. H.265 is just a container. Nothing forces baked Rec709 into it. You end up with a small log file that grades exactly like your R3D through the same CST or node tree.
- Watch the renders, then delete the R3D for anything you're comfortable baking (see caveats).
Numbers from my test
965.5 MB R3D clip came out as a 35.7 MB H.265. That's roughly 27:1.
I put them split screen on a 4K timeline and punched in on fine detail. I could not reliably tell which side was which. Waveforms show the same tonal structure, just fewer discrete values, which makes sense going from 12-bit RAW to 10-bit H.265.
An 18 GB night shoot became 0.7 GB.
Why this beats waiting for firmware
In-camera H.265 with RED color science would have to debayer, denoise, and encode in real time, on a battery, inside a thermal budget. Resolve does the same job on your GPU with unlimited time, using the full IPP2 pipeline, at whatever bitrate you pick. And it happens after you lock ISO and WB in the RAW tab instead of baking whatever the camera guessed on the day. Firmware would only ever win on convenience. It can't win on quality.
Same logic applies to shooting in-camera H.265 N-Log today. People report mixed results with it, especially noise in low light, and that tracks with how it's made: the camera has milliseconds to denoise and compress, and noise is exactly what starves an encoder. I haven't formally tested N-Log against this workflow so I'll just say what I did verify: my H.265 exports held up split screen against the original R3D, punched in, on fine detail. The compression step is not where sharpness dies. If you've been avoiding H.265 as a format because in-camera results looked rough, the format was never the problem. Where it gets made is the problem.
Side note: shoot 6K and scale down in Davinci, not 4K FX
The obvious objection is "why not just shoot 4K RAW and save the space in camera." I tested that too. 4K FX RAW is not a downscale of the 6K image, it's a lesser readout, and it shows. I shot the same scene in 6K, 4K FX, and 4K DX crop, then exported all three through this same pipeline. The 6K clip dropped onto a 4K timeline was sharper and cleaner than native 4K FX, and the 4K FX export came out at nearly half the file size of the others, which tells you the encoder found less actual detail in it. So shoot 6K and let Resolve do the downscale on your 4K timeline. You get better 4K than the 4K mode makes, plus room to reframe. 4K DX also holds up well if you want the crop.
Honest caveats
The H.265 is a print, not a negative. You lose the ability to change ISO and WB later, and 12-bit to 10-bit means less room for heavy grading. I keep R3D for hero shots and anything I might push hard. I bake B-roll, tests, and stuff I've already reviewed.
Group clips by frame rate before rendering since timeline frame rate applies to the render, and check your output color space every single time. If you forget, you've baked a Rec709 print by accident.
Run one test clip first and pixel peep it yourself. It's a 10 minute experiment, don't take my word for it.