Super useful info Jason. Just the other day I was shooting in the standard picture profile and noticed the files were smaller than I had come to expect from when I shoot in clog... Good to know those files aren't 10-bit! I do wish that were an option, but at least you have the extra info for when you really need it.
I shoot all my a-roll footage on an R5C in 1080p full frame in c.log 3, saved with 10-bit 4:2:0 HEVC. Though I intercut with footage from my R5 shot full frame, 1080p, 10-bit HEVC (c.log 3). Truthfully, at 1080p I don't find much of a difference between the two cameras, even though the R5C is down-sampling from 8K and the R5 is downsampling it's 1080p from line skipped 4K. That said, I shoot 1080p largely to save space, as I don't think anything in these videos really warrants stepping up to 4K.
Either that or raw, both will offer the best quality for video for stills applications. Raw having the advantage of not baking in color temp and curves adjustments, and ALL-I yielding smaller files.
This was super useful but it seems you missed HDR PQ and C-LOG options when going through the menu - isn't this important? Because it controls chroma subsampling IIRC
You are correct, HDR PQ and C-Log are important for the reason you stated - they control both chroma sub-sampling and bit depth for compressed formats (e.g. not raw). I do cover that though, at around 18:00 minutes in as part of the CODECs section. Though in retrospect, I could have called that out more specifically in the chapters list.
Is the sensor data converted to Lab (Luminance, Green - Magenta, Blue-Yellow) in the RAW files as with RAW still files? Is my understanding correct,that depth refers to the number of discrete digital tonal steps per channel the analog voltages are converted into; i.e., 8bit = 256, 10bit = 1024, 12bit = 4096 with higher bit depth doing a better job reproducing subtle gradations like sky tones without “banding“ especially when editing files with levels or curves adjustments? Is the difference between 10 and 12bit capture significant in practical terms? Will the average viewer notice a difference in the tonal gradations?
Raw files (both video and still) are kept in sensor's native RGGB Bayer pattern, they're not converted to lab or anything else (they're not even RGB in the sense that a TIFF or the like is). Re. bit depth, yes more or less. More bits means you can store more levels which means gradients can be smoother (along with more dynamic range). Though this isn't the only consideration, as bit rate also plays a factor in how much information is discarded in compression. Re. 10b vs. 12b capture in video, this is typically more complicated still, as video files (even raw video) aren't linear, and differences as you'd expect them in gradations are largely negated by dithering due to noise and the fact that that changes in every frame (think of it as temporal blending). Ultimately even 8-bit video can produce visually smooth looking gradients in many situations. 10b and 12b do better still, but their bigger advantages come in supporting larger dynamic ranges. Whether or not the average viewer would notice banding depends on what's done to the video after shooting and how much it was compressed in the first place. It's really a rather complicated problem, as it's not just the bits per pixel that matter but the bit rate as a whole (bit's per second). You could have perfectly fine gradients in 8b video with a sufficiently high bit rate and blocky messes in 12-bit video compressed with too low of a bit rate.
Thanks for all the information on the video. Quick question, For me to film 8k or 4k 10bit 4:2:2 I will have to switch over to Clog. Seems like my PC (Windows 11) doesn't handle well when editing Clogs with Davinci Resolve 18 as it stutter. Would there be a workaround to handle R5 10bit 4:2:2 better like a plugin? I read somewhere that hardware decoding doesn't support it at the moment. Thanks!
For 10-bit 4:2:2 you have to be in either Clog or HDR PQ. The playback problems are because the video is high bitrate 4:2:2 chroma HEVC, which requires an Intel 12th gen or newer CPU or Arc GPU for HW decode (as best as I can tell, NVidia doesn't support 4:2:2 even though they support 4:4:4, and I have no idea what AMD supports). Even then, in 8K you're likely to still run into playback problems from the bitrate. I go about that problem 2 ways. For previewing and what not, I'll make 1080p or 4K 8- or 10-bit 4:2:0 HEVC proxy files with a lut applied (which solves Window's color issues). I use FFMPEG and a custom script I wrote for that. You could also use Blackmagic/Resolve's proxy generator lite, but that can't add a lut. In Resolve itself, I just right click on the videos and generate a proxy file in either DNxHR or AVC for your edits, and tell resolve to use the originals when rendering the final output.
