Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

MX Bit depth?

Matthew Scott

Matthew Scott

Well-known member
Joined
Nov 18, 2008
Messages
1,313
Reaction score
0
Points
0
Location
Melbourne, Australia
Hey guys,

I had asked this about a year ago, and it only caused drama. In the end, there was no 100% guarantee or word from RED's mouth that the MX sensor records a video file with 16-bits of information. I don't actually care if it's 14-bit, 12-bit or 16-bit. But, when I run workshops and speak in front of crowds of people at NAB or IBC (and this November at InterBee), I really need to know the facts, otherwise, I look like an idiot. The two things that recently reminded me to seek clarification on this was 1). Jim specifically mentioned that the new Dragon sensor records to 16-bits, as if it were a new thing, and 2). Resolve shows different bit-depth "file attributes" for RED footage, sometimes 12-bit, but most of the time, 10-bit. When importing other RAW formats, resolve shows 14-bit and 16-bit, but never with RED 6:1.

My questions are:

1). Does the MX sensor record video files that have 16-bit's of information?
2). Does changing the compression ratio of the MX sensor change the bit depth that is recorded (which it states loosely on the website, EPIC and Scarlet are different, and the word "processing" doesn't specifically indicate what is actually recorded), and if so, what ratios record what bit depth?

And just so no-body jumps in with something like "If it's good enough for films like Prometheus, then it should be good enough for you!" or some crap like that, it's not that I really care. Anything at 12-bit or higher is good enough for me. I just need to confirm the actual specs for when I'm lecturing.

Thanks!

Matt
 
I seem to recall the MX sensor is 16bit, but your recorded bit depth varies with the amount of compression and what/how you're recording the information. The red one at 9:1 was always 12bit and the Epic at 8:1 has always been 16bit (so far as I know), obviously if you transcode the Raw files to prores 422 then it's going to drop to an 8 or 10 bit depth file.
 
Not sure if you've seen this thread, but they talk about it a little:
http://www.reduser.net/forum/showthread.php?73953-EPIC-12-and-16-bit-RAW

Jarred Land said:
It's rather complicated, but all that is important is that in camera it is indeed 16 bit, and RCX pro is 16 bit+ . Rob ( if he is listening ) can explain the "+" part .
Click to expand...

and further on:

Rob Lohman said:
Joseph is correct. There is no way to specify a number of bits per pixel with compression systems like this, that notion makes no sense anyway. One pixel may need more bits than another. You WANT the bits to go where they are needed, not be wasted where they're not (which is what uncompressed and lossless compressions do).

Don't think of it as changing bit depth, think of it as deciding how many bits total you want to use to represent a frame.

Just to clarify: I'm simplifying things greatly here, you can't make sweeping statements like "compression ratio changes bit depth", that's too simplified :) I appreciate you want to understand as much as you can, but compression is a complex topic you can spend years or decades of your life on :)
Click to expand...
 
Matt,

for what it's worth:

it was mentioned in the past that for Epic & Scarlet, the internal A/D converter works @ 14-bit (maybe 16) and the RAW files are 12-bit... for R1 MX it was 12-bit A/D and 12-bit files...

it's hard to verify what bit-depth the .r3d files are in... probably better to be conservative on these numbers... ;-)


- M
 
Hey sorry to bring this back up, but I'm looking to know for sure the actual, legit, factual bit depth of R3d's captured with an Epic/Scarlet/MX? Mostly for two reasons:

1). The Dragon sensor was talked about by Jim as recording 16-bit r3d's as if it where a new thing
2). DaVinci Resolve recognizes R3D's as 10-bit, where as CDNG's from a 5D mark II are 16-bit

Other posts have Jarrad stating that all that is important is internally, the camera (Epic MX) is indeed 16-bit, but to me that's not really answering the question. I mean, the 5D mark II internally is 14-bit, yet the h264 files it records are 8-bit. So it's important when I teach RED post production, and share knowledge with people, that I'm sharing the correct knowledge.

What is the actual bit-depth of an R3D recorded by the MX sensor?

I've never been happier with a camera and don't really care what the actual bit-depth is, but it's important to know, for sure, especially when teaching. Maybe if it's not as simple as giving it a number (although that confuses me when Jim said that Dragon records 16-bit files) maybe something like "The RED MX sensor records anywhere from 12-bit to 16-bit files, depending on scene content, compression settings, etc"?
 
I think the older RED One had 12-bit ADCs. People were unsure about the RED Epic M-X. I think the Dragon probably has 16-bit ADCs with the extra dynamic range it can capture.

As for the bit depth in actual .R3D files, that indeed may be variable.
 
IF Resolve is saying R3Ds are 10bit, then Resolve is wrong. R3Ds for the original RED One were 12bit. R3Ds for the more modern cameras are 16bit+ (the + above is explained in your quote from Rob). Internal processing occurs at higher bit depths to ensure we don't get any truncation issues. Similarly in the R3D decode higher precisions are used to ensure we get the best out of the data.

As you point out, it's somewhat irrelevant. We just make sure that bit depth isn't the limiting factor in the images we record.

Graeme
 
Graeme Nattress said:
IF Resolve is saying R3Ds are 10bit, then Resolve is wrong.
Click to expand...

I have not used Resolve, but Scratch lets the user select 8, 10, 12, and 16-bit from the SDK. Its possible Resolve is grabbing 10-bit from the SDK and not 16-bit. Again, never used it, so I don't know.
 
I only know how to access 16bit from the SDK. I think you can access other bit depths, so as to optimize for display or writing a DPX or whatever. I see no value reason why a top end grading app would grab less bits than the best offered. That'd be daft.

Graeme
 
Don't have it in front of me, but accessing less than or other than 16bit via the SDK would be an undocumented feature, AFAIK… Seems silly to do so and I have been under the assumption that these other apps are doing their own bit depth and color space interpretations.

FWIW, last time I checked, Resolve was reporting 16bit DPX as being 10bit also.

Going back on this old thread, seems there's some goofy info. The sensors themselves acquire and transmit analog signals. The Analog to Digital Conversion (ADC) in the RED One is capable of 12bit precision and the RED One records 12bit R3Ds as a container file. The R3D container for EPIC and Scarlet is 16bit and seems it is still 16bit after the move to Dragon. I don't think the ADC precision or bit depth has ever been disclosed for the DSMC system with MX or Dragon implementations.
 
One MX = 12 bit

Epic MX = 14

Dragon = 16

This has been verified by some very smart people in Toronto using various math techniques. This is the number of tonal gradations those cameras record to R3D files - what happens internally first or how Red SDK math works I have no idea.

There is a setting in Resolve to determine the derived bit depth of Red footage as seen by the software. It does make a difference.

12 bit is very, very hard to break - I have never seen banding in any image shot on One MX no matter how crazy the grade. 16 bit is insane. That said, the more you are stretching dynamic range around from a very wide initial capture (Dragon) the more bits you are happy to have.
 
Last edited:
Graeme Nattress said:
IF Resolve is saying R3Ds are 10bit, then Resolve is wrong. R3Ds for the original RED One were 12bit. R3Ds for the more modern cameras are 16bit+ (the + above is explained in your quote from Rob). Internal processing occurs at higher bit depths to ensure we don't get any truncation issues. Similarly in the R3D decode higher precisions are used to ensure we get the best out of the data.

As you point out, it's somewhat irrelevant. We just make sure that bit depth isn't the limiting factor in the images we record.

Graeme
Click to expand...

Thanks Graeme! Legend :)
 
Jeff Kilgroe said:
Don't have it in front of me, but accessing less than or other than 16bit via the SDK would be an undocumented feature, AFAIK… Seems silly to do so and I have been under the assumption that these other apps are doing their own bit depth and color space interpretations.
Click to expand...

I agree it would be silly for a grading app to decode at lower bit depth but FWIW the SDK does indeed allow for 8,10,12 and 16 bit decodes for faster decodes / processing in non color critical applications...

PixelType_16Bit_RGB_Planar // Planar RGB decoding in 16-bits per pixel
PixelType_16Bit_RGB_Interleaved // Interleaved RGB decoding in 16-bits per pixel
PixelType_8Bit_BGRA_Interleaved // Interleaved BGRA decoding in 8 bits per pixel, alpha channel
PixelType_10Bit_DPX_MethodB // Interleaved RGB 10-bit DPX Method B
PixelType_12Bit_BGR_Interleaved // Interleaved BGR 12-bit (2 pixels packed in 9 bytes)
PixelType_8Bit_BGR_Interleaved // Interleaved BGR 8-bit
 
Mike Nagel said:
Matt,

for what it's worth:

it was mentioned in the past that for Epic & Scarlet, the internal A/D converter works @ 14-bit (maybe 16) and the RAW files are 12-bit... for R1 MX it was 12-bit A/D and 12-bit files...

it's hard to verify what bit-depth the .r3d files are in... probably better to be conservative on these numbers... ;-)


- M
Click to expand...

One MX was more than 12 bit internally.

Also the bit depth of Resolve R3D decode is user-selectable, as it is in Scratch.
 
You must log in or register to reply here.
Back
Top