Benefits of Encoding/Acquiring 10bit uncompressed footage?

[Tgor82]

Will I be able to attain extra detail if I use a camera that can output 10bit uncompressed images VS using a camera that only outputs 8bit??

I just want to know if Ill be able to get more dynamic range out of the image when doing comp work in Nuke. I want to have more Details in the shadows and brights.

C300 looks pretty good but can only outputs 8bit, the other option is the Sony F3 which does output 10bit.

Any insight would be appreciated.

Thanks!

[radders]

10 bit would definitely give you more range in the highlights and shadows. If you have a DSLR you can try comparing a still shot as a JPG and then in RAW. Try changing the exposure and you'll see the extra detail the RAW gives you.

It isn't that straight forward though. When you start looking at the higher end video cameras most of them shoot in different colour spaces, designed to retain higher dynamic ranges, even in 8bit files. I think the C300 can record the image with a log curve applied which, when inverted, will give you extra highlight details. You will need to compare these, and consider your colour management workflows, when comparing cameras.

[Tgor82]

Thanks Conrad. Can you recommend a workflow? Im coming from an Artist background and want to learn more about properly capturing 10 bit uncompressed footage. Im certain I will be using the F3, as I believe it is the only camera that outputs 10 bit 4:4:4 images, that is within my price range for rental. Also is there a way to avoid proRes and Use the Avid DNX 10bit codecs? Im trying to avoid Quicktimes crappy color management and will hopefully be editing in premiere and comping in Nuke... I guess I just need the proper acquisition hardware, which I dont know a whole lot about.

[radders]

I don't actually know much about cameras. I never shot the stuff I work with. Most of what I know about shooting has come from listening to the RC podcast from fxguide.com

With any camera this is the general workflow that I think most high-end projects:

Shoot in as higher quality you can.
Create QuickTimes of all footage in whatever format you are going to edit in (ProRes, Avid DNX etc). This is not the format that you are going to deliver the project in or do the VFX on.
Create backups of the original raw files.
Edit with the QuickTimes.
Once you have picture lock go back to the original footage and re-transcode the shots used in the edit from the raw files into something like DPX or EXR for final grading or VFX.
Conform edit, do VFX, grade.
Export from these high res files to delivery format.

Of course this involves a lot of data management and quite a few steps. For quicker turnaround and a less complicated workflow you can use just create the QuickTimes from the camera and work with them throughout the process. I haven't worked with QuickTimes for a long time so I don't know the best format or the best workflow for colour management. I would imagine you would want quite a flat, low contrast QuickTime until the grading step, after the VFX.

[scrimski]

Create QuickTimes of all footage in whatever format you are going to edit in (ProRes, Avid DNX etc).

If you are going to edit on Avid MC, don't transcode as it will be a waste of time. Avid is going to transcode anyway when importing(unless you use AMA files).

Conform edit, do VFX, grade.

VFX, grade, conform edit.

[radders]

VFX, grade, conform edit.

By conform I meant "take edit and get full res files from original source for shots used". I suppose conform isn't quite the right term but what would you call that process?

I'm used to the DI process being the grade and the conform in the same step so when I said grade I should have said DI.

[scrimski]

Conforming in my understanding is re-ingesting processed footage and replace the previous version in the edit.
You're right with the DI part, most projects I'm involved I'm the one (as the editor) who brings everything back together in one piece, so I was talking about the low-budget route.

[Tgor82]

Thanks for all the helpful Info guys. Ive worked on a lot of low/no budget projects where the footage I had to work with was pretty bad. I have a Chance to influence the decision on the camera and the codecs used for the footage. I just wanted to get the most pristine images I could to work with in Nuke.

[zoostory]

Hey, just chiming in a little late, but here's some info that may be of help:

8 vs 10 bit. This actually isn't a measure of the size of your gamut. That is, the higher the bit rate does not necessarily mean a larger container for carrying whites and blacks (16 and 32 bit float being another topic). Think of it more like the resolution, or steppy-ness of your footage. 8-bit has three chanels that can each record a number from 0 to 255. 10-bit has 3 channels that record from 0 to 1023. So when a pixel on your cameras chip records, say, a red color of a wall, the codec recording the footage has to assign that a number, it could be 233,20,15 (R,G,B) or something like that in 8-bit, or 1022,256.33 in 10-bit. So 10-bit gives you smaller incremental "steps" to choose from. 8-bit, on the other hand, is going to have to make some fairly averaged assumptions about your color and either step up or down and find a good place for it.

The result visually is typically that 8-bit footage gets more banding in gradients - like a magic hour sky for example. Because you only have 256 steps, as your blending through all those colors, you literally hit steps where numbers have to change in large chunks, and that's where you see a banding line.

10-bit lessens this problem. Then of course, you can even go up from there, usually on the post side, with 16-bit, and 16 or 32 bit float. All even more precise, but very data intensive, so rarely used on the production side.

---
As for 444 vs 422. This has to do with your X and Y grid of pixels in an image. The first number represents the resolution of your luma vs the second two numbers, which are your chroma. So for every 4 pixels of luma, you have 4 pixels of both channels of Chroma in 444. in 422 you have half as many pixels of chroma than luma. The reason this exists is data compression. The human eye sees black and white much better than color, so smart scientists figured out that they can save bandwidth by lessening color info in an image. Of course, compositing programs and computers are not the human eye, so for them, every drop of resolution is important. Results can be steppy keys, bad edges with 422. Though 422 is way better than 4:1:1 or 4:2:0 which you'll find on a 5D or GoPro or the like. Most TV shows still finish 422, it's a cost consideration, the data is literally smaller, saving money on storage and transcode/transfer times. But as a VFX Super, I often push for 444 footage for heavy green screen sequences and such.

----

Colorspace is really where you will see your whites and blacks preserved. Regardless of the bit-depth, different manufacturers have created different logarithmic based algorithms (all based off of the filmic log to lin concept, a way to store films mass gamut in digital files) to store what your camera shoots in it's smaller container intelligently, allowing you to reverse the algorithm later on in post, where you have a larger container (remember, 16 or 32 bit), preserving lots of highlights and darks and such. Of course, even your average computer monitor is only 8-bit, so your viewing device becomes a bottle neck, you have to rack exposure to even see those extra details when you are working.

You can absolutely compress 8-but footage in a log format. The 5D has the Technicolor Cinestyle curve, that does a good job. Of course, it's not as good as 10-bit, because you still have less numbers to deal with, so data is less specific, theres a bigger margin of error in your recording of colors. But it is better for VFX to shoot in a log space, regardless of bit-depth. You'll just preserve more detail and get rid of any half-baked camera "look" (usually designed for the consumer to get an immediately gratifying image). Save the "look" process for color correction.

Anyway, I hope this helps.

Stephan