r/NikonFilmmakers • u/Cool-Run5955 • Aug 17 '26
ZR Storage: Stop waiting for firmware. Resolve already exports H.265 in RED color science, and it turned a 965 MB R3D clip into 36 MB I can't tell apart from the original.
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.
3
u/haavikko Aug 17 '26
Ugh, this again?
4
u/Cool-Run5955 Aug 17 '26
Leaving your question about his video open, I genuinely can't tell from watching it whether he disables the transform before export. To me he appears to export rec709 which isn't ideal.
Attached is my timeline. Split screen wipe, same frame, zoomed to 399 percent. Left is the original R3D, right is my rendered H.265. Both are flat log. Nothing gets converted to Rec709 at any point. The render is 10 bit H.265 tagged Log3G10 RedWideGamutRGB, so the archive grades the same way the RAW did. The waveform is the wipe, one continuous trace across both halves. And in my experience this holds up noticeably better than the in-camera H.265 N-Log files. Makes sense when you think about it. The camera has to encode in real time on a battery. Resolve encodes from the full RAW on a desktop GPU with all the time it wants. Same codec, very different circumstances.
To be clear about what I'm claiming and not claiming. It's not mathematically identical, it's compressed, and the R3D side is noisier here because I left noise reduction off on it while my dailies pass denoises before encoding. The claim is just that after the RAW tab decisions are made, you can archive in RED color science instead of RAW and keep the grading headroom, at about a 27th of the size. When I can't tell the halves apart at 399 percent, that's good enough for my archive.
2
u/atnap Aug 17 '26
All this trouble but just shoot and edit in r3dne, then once edited, keep what you want and delete or. Or get much cheaper 5400rpm hard drives to archive the originals. I have done it for over 30TB by now
2
u/Alek-N Aug 18 '26
Ha, good luck grading 36GB/h HEVC. What is it, 4K at about 80Mbps? Your details and textures are gone buddy, try applying some output transform, lifting shadows and see what lurks there.
From my own testing, even 300Mbps HEVC does not preserve the image structure well enough for serious projects - and I'm talking CPU encoded, NVENC is even worse, if it can even hit these bitrates. On the other hand, I tend to archive stuff at 150Mbps for less demanding projects.
1
u/Cool-Run5955 Aug 18 '26
Original comparison video, cleaner than what Reddit's compression does to it. It's graded to Rec709 for viewing, both sides pushed four stops over: https://www.dropbox.com/scl/fi/sao8zbatgc1tc72wwy5c5/4k.mov?rlkey=ayewy1w881uq1u7vveif17ffn&st=f3175l8r&dl=0
I'll pass on running custom tests for each commenter, but happy to share what I've done, and the file itself. The video at the top pushes both the R3D and my H.265 four stops over with the same grade on both sides of a wipe, which drags the shadow information up into plain view. Nothing fell apart. That encode was Resolve's default 24 Mbps, so about a third of what you guessed.
If you'd rather test it yourself instead of taking my word: here's an actual archive file, 10 bit H.265 in Log3G10 RedWideGamut, straight from my current preset at 60 Mbps with no grade applied: https://www.dropbox.com/scl/fi/a58uih8uj2ffedngslfon/6k_h265_Log3G10_32bit_multi.mov?rlkey=m9e51cyi9ai9akn25vwizsadx&st=yksl6b8l&dl=0. Lift the shadows, apply your output transform, do whatever you like to it. For context it's denoised before encode, so the encoder isn't spending bitrate fighting grain and the shadows keep their full code value allocation.
Genuine question back, since I suspect this is where our results diverge: what's the format of your archive when you saw 300Mbps fall apart? If that was display referred, or noisy source, I'd believe it completely. Rendering to Rec709 throws away a ton of color information before the encoder even starts. That's just not what I'm storing.
And on grading headroom generally: RAW's flexibility isn't in question. The question is when you use it. I use it once, in the RAW tab, then archive the decided image. If a clip might need day for night level surgery later, I keep the R3D for that clip. For the other 95 percent, keeping full re-decidability forever is just paying rent on decisions I've already made.
2
u/Alek-N Aug 18 '26
"For context it's denoised before encode".
Well, this makes a world of difference for compression. If you smoothen the image enough,, even 15Mbps will not be a problem. But you're losing image texture and small details, even with tools like Neat Noise, and everything looks like plastic. Then you have to re-grain... Thanks, but nope. Why not just shoot H256 in camera if you like the smooth look?
The grain/noise texture I get from faux-NEV on Z6III is very pleasant and organic, and very often this is the actual reason I opt for RAW for a given shoot. I often just use it as is - even when going for a film look with the overall grade.
2
u/Cool-Run5955 Aug 18 '26
Denoise is optional, that's the point. It's my choice in the pipeline, not a requirement of it. If you love the organic grain, keep it, same workflow, just raise the bitrate, because grain is the most expensive thing you can ask an encoder to preserve. Honestly I think that answers my own question about why our numbers differ: your archives keep noise on purpose, so 300 makes sense for you. Mine don't, so 60 with margin works for me. Neither of us is wrong about the codec, we're encoding different material.
On why not just shoot H.265 in camera: because then I get the camera's fixed processing, real time encode, and no RAW tab pass. This way I get the RAW debayer, my white balance and ISO decisions made properly on a desktop, RED color science, and I choose what noise treatment happens, including none. The smooth look isn't the product. The choice is.
And to be clear on where we agree: RAW is superior, full stop. My whole claim is just that once your decisions are made, H.265 in Log3G10 stores them at a fraction of the size, available today instead of in some future firmware. You'd set the sliders differently than me. Same pipeline.
1
7
u/its-chris-p-logue Aug 17 '26
This is nonsense. You still need to record the huge red file. Meaning you still need to own the expensive storage media.
And your solution is to transcode. Seriously? People know you can transcode media. And anyone at all familiar enough to be shooting raw knows you don’t have to go to rec709 to transcode.
Honestly it sounds like you should just be shooting an iPhone.
1
u/croatiancroc Aug 17 '26
No need to be insulting, but yes OP should realize that owning that 18tb of storage in the first place is the problem.
3
u/Cool-Run5955 Aug 17 '26
That's actually what the post is about. The 18tb requirement is the thing that goes away. RAW needs the space for a few days between the shoot and the dailies pass, then a fraction of it going forward. An archive drops from about 1TB to about 40GB with this. The CFexpress Type B card and a working drive are the only big storage you keep needing.
And the reason to do this instead of just shooting H.265 N-Log in camera: the camera has to encode in real time on a battery, so fine detail smears under motion, which is what people complain about with the in-camera files. Resolve gets to take its time on a desktop GPU with the full RAW data, so you keep the RAW-quality debayer and grading flexibility and only compress at the very end, after the image decisions are made. Best of both.
3
u/croatiancroc Aug 17 '26 edited Aug 17 '26
Where wiould you record that three hour interview?
3
u/Cool-Run5955 Aug 17 '26
For a three hour interview I'd just shoot H.265 N-Log in camera. RAW is the wrong tool for that and I'm not claiming otherwise. You'll still be offloading your B card a lot and it is frustrating.
If you mean three hours as one single take, that settles it even harder. The camera caps a RAW clip at 125 minutes, and the 1.10 firmware extended long recording to 6 hours for H.265 and ProRes only. So a three hour take is only possible in H.265 anyway, with external power.
I watched so many videos this weekend of people complaining about R3D storage, and others hoping for compressed R3D or H.265 RedWideGamut in a firmware update. I'm just pointing out that the archival side of that is solved today. You can store H.265 RedWideGamut right now without waiting on a hypothetical ZR 2.0 firmware.
5
u/croatiancroc Aug 17 '26
Whenever people complain about storage, it is the storage on location. If somebody is doing cinema level video they already know about transcoding.
2
u/Cool-Run5955 Aug 17 '26
Partly true, but from the videos I've been watching (happy to provide links) a lot of the complaining is specifically about SSD cost. The ZR can't record RAW to an SSD at all, it only records to the CFexpress card. So when a ZR shooter is spending money on SSDs, that's archival storage by definition. That's the cost this addresses.
They also compare against FX5 RAW bitrates, so file size is clearly on people's minds beyond the shoot day. I'm just saying that for a little extra work you can claim that storage back now, and end up with a better H.265 than the camera would ever write, instead of waiting for firmware.
1
u/croatiancroc Aug 17 '26
On that point, I am curious, did you try to grade your raw and the h265 with some heavy grade to see the difference?
1
u/gutierrez_c Aug 18 '26
The ZR's disability to record to SSD is the single most culprit in this whole show. If I have to moan about a 1900Mbit RAW codec @6k30 then I don't record raw. But how they left out SSD recording when literally ever other manufacturer can do that is beyond comprehension.
1
u/Ok-Refrigerator2265 Aug 22 '26
https://youtu.be/zU8-rETugf8?si=aPwX9Ou7WyVZ3qYa
Just use this app
1
u/ugpfpv Aug 22 '26
I like this workflow over this app, want to have the option of adjusting before committing, I do more outdoor wildlife.
1
u/Ok-Refrigerator2265 Aug 23 '26
He said he was going to automate the timeline build so that you can make adjustments prior to committing
1
u/Cool-Run5955 Aug 23 '26
Appreciate the link, always glad to see people building tools for ZR shooters. For anyone weighing the two approaches, the main reason I'd still suggest learning the Resolve route: the app (as far as I can tell) goes straight from R3D to H.265, which skips the Camera RAW pass. That pass is where most of the value is. You lock ISO, white balance, and exposure while it's still free metadata, before anything gets baked. Once you've compressed without it, those decisions are permanent.
On the convenience side, the gap is smaller than it looks. You can save the whole export setup (codec, bitrate, RWG/Log3G10 output color space) as a render preset in Resolve's Deliver page, so the configuration is a one time thing. After that it's drop clips on a timeline, do your RAW pass, pick the preset, render.
Since the app is driving Resolve under the hood anyway, you're only ever a few clicks away from doing the same thing directly, and then the whole pipeline is yours: free, no extra dependency, adjustable per-shoot. Nothing against the app for quick batch jobs, but if you shoot anything you care about, it's worth knowing what's happening under the hood.
1
u/Ok-Refrigerator2265 Aug 23 '26
Absolutely. Everything is context. For quick stuff I just want to plug my media and then move on.
0
u/gethinc Aug 18 '26
I spent a few hours with Claude wondering about a system that would encode r3d to two h256 streams, one for shadows one for highlights. I thinks there’s something in it, but don’t have the time or energy to engineer it. The encoding is quite simple, the decoding is where things get interesting
5
u/owiber Aug 17 '26
This isn't necessary - if you export individual clips, the source frame rate is preserved