Media 100 16-235 vs Computer 0-255
So we have been editing M100 in 16-235 for a long, long time and other systems such as FCP run in 0-255. Having to create a full contrast DVD means the slow output from M100 to a QT codec of choice incorporating the Computer 0-255 level setting.
Why is Media 100 using 16-235, while others use 0-255. Or vice versa. Why can there not be one setting? Many people are being caught out by this issue as it is not widely known or understood.
[David Issko] "Why can there not be one setting? Many people are being caught out by this issue as it is not widely known or understood. "
Oh, the mysteries of QuickTime and ColorSpaces. This whole 0-255 and 16-235 is only one part of the huge amount of QuickTime problems, including Aspect ratio problems, gamma shifts, setup problems, limited dynamic range,…
Here ia a short explanation:
Most video material these days is stored in YCbCr files. Most of our video codecs are in this format, including all the Media 100 codecs, ProRes, Uncompressed,… In the early days of video editing, some systems worked in RGB, though, which seemed to be the natural way for Computers, since most image manipulation on Computers was done in RGB in the early days.
Still, QuickTime is a very RGB-centric tool, and most of the processing in e.g. AfterEffects is done in RGB. Now the native YCrCb files (which is the video space also used e.g. for SDI signal transmission and for recording on DigiBeta decks) have to be converted into RGB if they are passed around in QuickTime applications. Inside Media 100, the whole conversion is handled by Media 100 (in case the image needs to be processed) and therefore shows no problem. In most other applications (excluding e.g. Apple Color) the conversion from YCrCb to RGB is done by the QuickTime architecture, which handles a RGB signal to the applications.
Now there are 2 standards on how a YCrCb signal gets converted into RGB, or to be more exact on where white and black levels get mapped to. As you probably know, a YCrCb signal can have parts that are below black and above white. You can see a signal going over 100% Luminance on your Waveform monitor, and you can see it go below 0%. These signals are stored in YCrCb QuickTimes, and these above 100 and below 0 levels are preserved, since they are a part of the native YCrCb colorspace.
Now the question is what to do with these signals when converting to RGB. The "StudioRGB" conversion, implemented in Avid and Media 100 for example, defines that the 0% black gets mapped to RGGB16,16,16, while 100% white gets mapped to RGB255,255,255. The advantage is that even in AE you have access to your signals above 100% and below 0%, e.g. if you want to recover crushed whites or blacks in AE in a colorcorrection step. Plus, you have the benefit that if you process a file through AE, if you do no colorcorrection you will end up with your exact same image, with the below 0 and above 100 values.
Apple decided to take the opposite approach, which maps everything between 0% and 100% to RGB 0-255, or the full RGB spectrum. The benefit is that you have a little bit more detail in your RGB converted file. But if you have a signal that goes above 100% or below 0%, you cannot recover this in AE or other QuickTime apps, since the signal gets clipped immediately on YCrCb to RGB conversion. Plus, if you simply render a file through AE without applying any effect, you will also lose this data.
Changing this is really difficult without breaking many workflows. Ideally QuickTime would be reengineered in a 32bit float colorspace, I guess, with lossless conversions and access to all data. But still it would break many assumptions and workflows, so I am not really sure how to get out of this problem. It is somewhat similar to e.g. the field order issues we have, with some codecs being upper field first and some lower field first. This absolutely makes no sense, but you simply cannot change it overnight, since hell would break lose.
"Good" QuickTime tools (like e.g. BitVice, and partially AfterEffects) have the option to support both Colorspaces, giving you the choice for your source material. It would probably even be better if QuickTime "knew" about these different ranges and would compensate for that. On the other hand, each time QuickTime tries to compensate for some Gamma issues it ends in total chaos and in all kinds of broken workflows. There is a reason why most hi-end film-pipelines are dealing with Cineon or DPX files instead of with QuickTime…
Thanks for your 'short' explanation Floh. Always a bank of brilliant information. Being technically trained, I am up to speed with the technical aspects. Perhaps my question was partly 'tongue in cheek' and partly directed towards Media 100 themselves.
My very humble opinion is that Media 100 should perhaps bite its tongue and conform to Apple's 0-255 levels as the Hardware/software does rely on the Mac platform, especially that Quicktime does not support the 16-235 colourspace. Nonetheless, it may be that Media 100 is technically correct and its colurspace may very well be 'superior' to Apple's but it's the lowest common denominator that needs to be considered here.
What are your thoughts on that Wickham (and you of course Floh)?