Blackmagic Forum

Everything I have read including the spec sheet on B&H says it is 12 bit, except one source says 16. That source is DaVinci Resolve Studio itself. What's the truth (for 12K BRAW)? No speculating, please. Let's have a solid, definitive answer.

I'm pretty sure the definitive answer is: 16-Bit Linear and 12-Bit Log.

Perhaps someone from Blackmagic will give you an official statement, but I've got a feeling this has been answered in the past to be what I wrote above.

This was discussed in this thread:

"16 bit linear (Sony) is basically the same as 12 bit log (Blackmagic)."

Blackmagic Dynamic Range vs The Rest

https://www.reddit.com/r/bmpcc/comments ... _the_rest/

The image data is stored in BRAW as 12bit log. Resolve can decode that to 16 bit linear.

For what it’s worth, ARRIRAW is also 12bit log.

12bit "non-linear" encoded which is different to our "Film" gamma log curves.

As Jamie says ARRIRAW is apparently 12bit log and the new ALEXA35 with LogC4 has moved to 13bit for ARRIRAW to store the extra dynamic range without changing distribution of stops over code values.

CaptainHook wrote:12bit "non-linear" encoded which is different to our "Film" gamma log curves.

As Jamie says ARRIRAW is apparently 12bit log and the new ALEXA35 with LogC4 has moved to 13bit for ARRIRAW to store the extra dynamic range without changing distribution of stops over code values.

Wait?! What?! That’s the first I saw about the Alexa 35 with LogC4 going to 13 Bit. Interesting…

Guess I didn’t pay attention to that detail in their press release.

But thank you for clarifying this Hook!


Sent from my iPhone using Tapatalk

Yes, thank you all, but somebody break down CaptainHook's explanation for me..do I have this right..BRAW is 12 bit non-linear encoded, not the same as BMD film log though. In Resolve is decoded into 16 bit linear, or I guess anything else, film, extended video etc. Internally then, is fundamentally 16 bit. How is this done? Half float real number. I have a feeling I am way off.

I think it's worthy of re-reading the Resolve manual because it's pretty specific that Resolve is working internally at 32 bits and always preserving all the data with very few use cases of clipping, one being use of applied input luts as I recall, where data has already been constrained before the 32b internal processing takes place.

Hopefully Captain Hook will clarify first why Resolve reports 12K sourced BRAW as 16 bit, and later answer your question Jamie about what sounds like truncating bits when rendering proxies. I don't think that should happen whether in YRGB color managed or standard display referenced YRGB. I think Hook has said with regards to the latter that non-color managed is working in WG/Intermediate by default or you can choose it in Custom color managed color processing mode, but that as long as your workspace can contain the full data space of your camera there will be no clipping, and that WG/Intermediate is very large, as in larger than ACES.

I should explain why I wrote that as far as I know, BRAW decodes to 16 bit linear.

First, from ARRI and other sources it has been my understanding that 12bit log and 16 bit linear, while not 100% identical, when 12 bit log is transformed to 16 bit linear the result is functionally equivilent to if the source had been 16 bit linear. In other words, 12bit log is a very efficient form of virtually lossless compression when compared with 16 bit linear.

The proxy issue from BRAW source clips in projects set to Resolve Color Management may be a clue to how Resolve handles BRAW clips internally. Whenever a project is set to Resolve Color Management, any proxy files made from BRAW source clips will have the highlights clipped unless they are rendered in 16 bit float EXR (which of course totally defeats the purpose of even making a proxy). The fact that Blackmagic still hasn't fixed this basic issue with BRAW proxies in color managed projects might be because internally Resolve always decodes BRAW clips to 16 bit floating point linear before moving it to the chosen working gamma and gamut, which would also explain why it identifies them as 16 bit.

I should be clear that the clipping of highlights in proxies from BRAW source clips does not happen with proxies made in an unmanaged YRGB project. In that case, the proxies will be created based on the option set in project level for BRAW decode and the proxies files made in that mode will appear correctly. It's only an issue in color managed projects where proxy files from BRAW source media appear to be clipped.

Hook, can you provide some clarity here about what is going on?

Jamie LeJeune wrote:I should be clear that the clipping of highlights in proxies from BRAW source clips does not happen with proxies made in an unmanaged YRGB project.

Are you sure? It's been a long-standing "feature" that optimized media, rendered in anything but 16-bit float, ProRes 4444, ProRes 4444 XQ, or DNxHR 444, will clip (and I'm sure about these other codecs, either; tests weren't encouraging). The 18 manual is still warning about this one:

Preventing Clipping: You should use 16-bit float, ProRes 4444, ProRes 4444 XQ, or DNxHR 444 if
you plan on grading using optimized media. This is particularly true for HDR grading.


And again:

— Preventing Clipping: Be aware that the format you choose will determine whether out-of bounds
image data is preserved when the signal is optimized. If you find that image data
(typically super-white levels) are clipped after optimization, you should switch to 16-bit float,
ProRes 4444, or ProRes 4444 XQ; in particular, any of these three codecs are appropriate
optimized formats for HDR grading.

Those are separate issues regarding data levels and *optimized* media. I am writing here about *proxy* media, which is totally different from optimized media. It would defeat the purpose of creating proxy media if it had to be rendered in linear to work.

This highlight clipping in proxy media only happens to BRAW source clips in color managed projects, and it occurs even if rendered to ProRes4444XQ.
It does not happen to proxies made from other raw formats such as R3D and Canon raw in color managed projects regardless of the proxy codec chosen, nor does it happen to proxies made from BRAW source clips in an unmanaged project.

It's a simple issue to recreate. I highly recommend testing it to see for yourself.

Am not sure why it would be any different for proxies -- there can't be a separate conversion process? -- but if you've tested it....

16bit lin stored as 12 bit LOG.

JB

John Brawley wrote:16bit lin stored as 12 bit LOG.

JB

Thank you JB. That answered my question. The others were right too, Jamie TimButt2 and of course Hook.

Jamie LeJeune wrote:I should explain why I wrote that as far as I know, BRAW decodes to 16 bit linear.

First, from ARRI and other sources it has been my understanding that 12bit log and 16 bit linear, while not 100% identical, when 12 bit log is transformed to 16 bit linear the result is functionally equivilent to if the source had been 16 bit linear. In other words, 12bit log is a very efficient form of virtually lossless compression when compared with 16 bit linear.

The proxy issue from BRAW source clips in projects set to Resolve Color Management may be a clue to how Resolve handles BRAW clips internally. Whenever a project is set to Resolve Color Management, any proxy files made from BRAW source clips will have the highlights clipped unless they are rendered in 16 bit float EXR (which of course totally defeats the purpose of even making a proxy). The fact that Blackmagic still hasn't fixed this basic issue with BRAW proxies in color managed projects might be because internally Resolve always decodes BRAW clips to 16 bit floating point linear before moving it to the chosen working gamma and gamut, which would also explain why it identifies them as 16 bit.

I should be clear that the clipping of highlights in proxies from BRAW source clips does not happen with proxies made in an unmanaged YRGB project. In that case, the proxies will be created based on the option set in project level for BRAW decode and the proxies files made in that mode will appear correctly. It's only an issue in color managed projects where proxy files from BRAW source media appear to be clipped.

Jamie, I think you're right. I was going to speculate that the behavioral difference between the other raws and braw in color managed mode might boil down to clipping caused by scene referred gamma in braw versus display referenced gamma in the others, i.e. metadata, a distinction that disappears in non color managed mode where everything becomes display referenced. Which if true, would seem to make it incumbent to use non color managed mode for generating proxies. That's as far as I feel comfortable speculating on but behind it are several behavioral observations, you have a raw palette in the color tab with duplicate controls in the raw palette of the project tab. In color managed mode they are always grayed out in the color tab while not necessarily grayed out in the project tab but, the controls in the project tab still don't work in color managed mode even if they are not grayed out, while they can work in the non color managed mode as with the color tab. And as you know, Resolve doesn't need to be told by you that a file clip is braw, it already knows this behind the scene, but not necessarily so with non-native raws not inherently identifiable so it opens the possibility of each type being treated differently when mixed on a timeline, but would not seem to explain why only the rendered proxy clipped if it otherwise looked correct on the timeline viewer. Bottom line here, is my question has been answered, feel free to take over this topic as far as you want to find the answers.

Yes, the proxy issue is best dealt with in its own thread. I only mentioned it as the reason I’d noticed how internally Resolve appears to decode BRAW to linear before transforming it to the working color space in color managed projects.

EDIT #1 — if decoding BRAW to linear wasn’t a necessary step, the proxy problem should have been fixed when I flagged it last year. But they haven’t fixed it which says perhaps it’s something inherent because it is absolutely bizarre to have BMD’s own codec be the only codec that doesn’t yield usable proxies in BMD’s own color management system in Resolve.
EDIT #2 — This has changed in the latest beta, it now seems to use a custom Gen4 gamma.

12bit log encoded integer data most probably gets expanded to 16bit linearized integer data , not half-floats, if there is a 16bit intermediate step in decoding at all (I doubt it, because if processing in decoder is not done on shorts it would be unnecessary extra step). Sensor data can’t go outside the range of normalized 0.0-1.0 so floats are not strictly necessary in this expansion step (can’t go over sensor clip level).

Braw decoder itself does internal processing on 32bit floats most probably and can output decoded data as 8bit unsigned, 16bit unsigned short or 32bit float buffer.

So as for original question, braw stores data as 12bit and this data originated as 16bit before encoding which in turn originated as x bits from sensor.

I did some testing of the latest beta and the proxy issue in RCM hasn't been fixed, but it no longer assumes linear. I posted that in the appropriate thread on the Resolve forum here: https://forum.blackmagicdesign.com/viewtopic.php?f=36&t=158626#p860631

CaptainHook wrote:the new ALEXA35 with LogC4 has moved to 13bit for ARRIRAW to store the extra dynamic range without changing distribution of stops over code values.

An interesting additional detail from this this interview with Harald Brandel from ARRI about the Alexa 35 is that the A/D conversion is to 18 bit linear, for the same reason of holding all the dynamic range.
https://podcasts.apple.com/us/podcast/colorist-meetup-dedicated-to-professional-colorists/id1536205711?i=1000567200794

Jamie LeJeune wrote:

CaptainHook wrote:the new ALEXA35 with LogC4 has moved to 13bit for ARRIRAW to store the extra dynamic range without changing distribution of stops over code values.

An interesting additional detail from this this interview with Harald Brandel from ARRI about the Alexa 35 is that the A/D conversion is to 18 bit linear, for the same reason of holding all the dynamic range.
https://podcasts.apple.com/us/podcast/colorist-meetup-dedicated-to-professional-colorists/id1536205711?i=1000567200794

Also covered by Harald in page 54 here where I got the 13bit info from:
https://www.fdtimes.com/pdfs/free/115FD ... 04-150.pdf

According to this quote from the article, 12 bit (4096) Arriraw is only capable of resolving 8 stops of DR.

What am I missing?

So, 18-bit from the sensor results in 13-bit after processing?

Yes. It’s 18-bit linear coming into the processing, and then either before the color processing, it gets encoded into 13-bit ARRIRAW, or after the LogC4 curve it gets encoded in 12-bit LogC4 for Apple ProRes.

ARRIRAW is also a Log-like exposure, which also allocates a fixed amount of digital numbers for each stop. We always had 512 numbers in each stop. So when you look at neutral gray and then one stop over, you have 512 intermediate steps, and if you add yet another stop, you have another 512 numbers.

Good Luck

13 bits fit 2^9 * 2^4 numbers == 16 stops at 512 discrete values per stop. Tracing backwards from this does tell that according to same logic 12 bits will only hold 2^3 stops. So I guess there is something important omitted from that description or it has that 512 part wrong.

Isn't it that 512 values is only used for most of the signal, but the lowest few stops are in the toe of the curve, each with fewer code values?
https://www.arri.com/resource/blob/31918/66f56e6abb6e5b6553929edf9aa7483e/2017-03-alexa-logc-curve-in-vfx-data.pdf

Kim Janson wrote:I am so confused, what is the remaining problem, to me the "13 bits fit 2^9 * 2^4 numbers == 16 stops at 512 discrete values per stop." is the answer.

The Alexa 35 records 17 stops.

Question by Howard was about previous 12bit storage which at 512 values per stop gives 8 stops.

Jamie LeJeune wrote:https://www.arri.com/resource/blob/31918/66f56e6abb6e5b6553929edf9aa7483e/2017-03-alexa-logc-curve-in-vfx-data.pdf

This makes more sense

In the linear part, the Log C curve has 73- 78 code values per stop in a 10-bit encoding.

Extrapolated to 12, bit Log-C would contain 292-312 code values per stop. Averaged at ~300 per stop it's about 13.5 stops which is close to reality. I still don't see where the 512 number comes from.

Good Luck

If you can, look at SMPTE RDD 30:2014 - "ARRIRAW Image File Structure and Interpretation Supporting Deferred Demosaicing to a Logarithmic Encoding"