13 Stops with 12 Bits?

For the BMCC to achieve 13 stops of dynamic range, the A/D converter would need to be at least 13 bits.

The BMCC outputs 12 bit RAW.

For both these specs to be accurate, some type of mapping would be necessary. Simply dropping the least significant bit would lower the DR to 12 stops.

The Arri Alexa claims 14 stops DR. In order to maintain that dynamic range with its 12 bit RAW output, Arri maps to a Log format.

So I'm wondering whether the BMCC RAW output is some form of log, like Arri, or is a simple linear translation?

Cheers.

are you sure that the sensor gives just 12 ?

maybe sensor has some headroom and something is mapped or dropped?

Also how half tones are "adjusted" seems different on bmc. I read or heard somewhere
that middle point is shifted in one way but i do not remember which way.

So my point is that there may be a lot going on that we do not know exactly ?

The camera's sensor is greater than 16 Bit.

A 16 bit LIN file is what is created and then converted to 12 bit LOG for stoarge in DNG.

When you go into Resolve, you'll notice the files *unpack* as 16 bit files.

jb

Fantastic. Mystery solved!

The camera's sensor is greater than 16 Bit.

A 16 bit LIN file is what is created and then converted to 12 bit LOG for stoarge in DNG.

When you go into Resolve, you'll notice the files *unpack* as 16 bit files.

jb

Sounds just like the Alexa. It seems Blackmagic did all the important things right.

Cheers.

The camera's sensor is greater than 16 Bit.

A 16 bit LIN file is what is created and then converted to 12 bit LOG for stoarge in DNG.

When you go into Resolve, you'll notice the files *unpack* as 16 bit files.

jb

Sounds just like the Alexa. It seems Blackmagic did all the important things right.

Cheers.

except releasing the camera itself...

anyway, I'll be waiting for it..

I just wondered, what about prores? Ok RAW could be the most amazing thing of the camera except amazing DR but sometimes if the project needs to be quick, it could make us to shoot @ prores. How about it? It is good as Alexa? Especially for DR.

What people seems to forget when they say 12-bit = 12 stop (in linear colorspace only), is that it is only for a single channel. When you combine channel, even more on a bayer design, you get a little more out of it.

One od the reason is that each channel will not clip at the same value on most light. So even if your red channel clipped, you may still have values in the others. With some algorithms, most raw converter will be able to recover (not perfecly) some highlight.

Same thing with the shadows...

Yep. 12-bits is precisely 12-stops in linear representation as they are the same (base 2) with each brighter stop having twice the information than the previous stop. In a linear space (14-bit Canon raw etc), the brightest stop has the same information as all the darker stops combined. 13 bits of range in the brightest stop. Granted, DSLRs don't reach 14 actual stops of range.

ARRI and BMCC both map >12 stops to logarithmic representations in both raw and ProRes (12-bit 444 on ARRI, 10-bit 422 on BMCC).

as far a i know alexa has 9 stops in prorez ?

as far a i know alexa has 9 stops in prorez ?

If it were 9 stops, DPs wouldn't be using it over ARRI raw. Again, it's packed into a logarithmic sample (ARRI LogC) so that all 13-14 stops are captured.

mostly prorez is used in conjunction "we have no money or time to have raw"

but if it has full range then great.

Talking about the Alexa!! I was just done watching this.. Interesting to watch

http://nofilmschool.com/2012/09/roger-d ... xa-at-ibc/

I got a question right to this topic (so that's why I don't start a new topic)
I'm a vfx guy, so excuse when my vocabulary isn't correct right away


As many here stated, the BMCC records a LOG-Image when using RAW or ProRes (I guess when using the Film-Mode, rather then Video that records REC709?). So, does anyone know which LOG this actually is?
Is it an own LOG, or Cineon, something like S-LOG? Alexa's LogC is a really mighty colorspace, which is the one that the BMCC uses, what is the correct curve?

Hope someone can settle this question.

I got a question right to this topic (so that's why I don't start a new topic)
I'm a vfx guy, so excuse when my vocabulary isn't correct right away


As many here stated, the BMCC records a LOG-Image when using RAW or ProRes (I guess when using the Film-Mode, rather then Video that records REC709?). So, does anyone know which LOG this actually is?
Is it an own LOG, or Cineon, something like S-LOG? Alexa's LogC is a really mighty colorspace, which is the one that the BMCC uses, what is the correct curve?

Hope someone can settle this question.

I too, am a VFX guy - lol

I'd like to know the answer to this question too.

From my own experimentations, I believe it is unique to the BMCC, which would make sense as the color-space surely has to be relative to the dynamic range of the sensor, right?

I found this by re-rendering a DNG sequence to DPX's, reading them into Nuke and setting the read node to RAW - which essentially applies a linear curve to the image, giving you the LOG image without any grading. If you then put a colorlookup node on this, and apply a REDLOG, CINEON or Alexacurve, it should look correct, but it doesn't for me

Maybe we should post this somewhere else so someone more technical will see it?

Yeah this question bothers me for some time. I didn't had time to get the footage into Nuke by now, but it would be quite interesting also simply to know which values I can reach in linear space before clipping.
In Cineon, it would be up tp 11, in Alexa LogC it's over 50. REC709 and friends are at funny 1. It would be really interesting where the BMCC sits; on this way artists can not set up a proper working-environment (sure, when I import the DPX and import and export it in the same way it looks the same either way, yet I'm really curious).

As the ProRes is already 10bit and it's obviously some kind of flat look, there could come some nice LOG-footage from it (just like Cineon-Files, which are of course not debayered, but still)

Yeah this question bothers me for some time. I didn't had time to get the footage into Nuke by now, but it would be quite interesting also simply to know which values I can reach in linear space before clipping.
In Cineon, it would be up tp 11, in Alexa LogC it's over 50. REC709 and friends are at funny 1. It would be really interesting where the BMCC sits; on this way artists can not set up a proper working-environment (sure, when I import the DPX and import and export it in the same way it looks the same either way, yet I'm really curious).

As the ProRes is already 10bit and it's obviously some kind of flat look, there could come some nice LOG-footage from it (just like Cineon-Files, which are of course not debayered, but still)

Sure, I know what you mean. What you can do is make your own lut and tell nuke to apply it by default. Its not too difficult. The problem I've got is that I had to bake some of the settings in After Effects before I exported the DPX's...that sounds quite destructive to me.

I would use resolve to dpx not AE.

If any changes needed one could re render from resolve again.

Plain and simple.

Yeah I could also apply the normal Cineon LUT. But I don't want to use any LUT that looks fine, I want the actual LUT as it is...

DPX was once made to hold "digital film", which is 10bit LOG Cineon for scanned film. So it shouldn't be too destructive (of course it is somewhat destructive for RAW, yet you can always apply VFX after grading, which is smart in some shots anyway).

Yeah I could also apply the normal Cineon LUT. But I don't want to use any LUT that looks fine, I want the actual LUT as it is...

DPX was once made to hold "digital film", which is 10bit LOG Cineon for scanned film. So it shouldn't be too destructive (of course it is somewhat destructive for RAW, yet you can always apply VFX after grading, which is smart in some shots anyway).

Actually it would be 'as it is' as it is made custom for the plate, but I know what you mean.

Yes, that's why I use DPXs. You're misunderstanding me a little though - when you import DNG's into AE the Adobe Raw program springs up and forces you to bake in certain gamma settings. As far as I know, those are baked into the DPX's when you render them out of AE - I hope I'm wrong.

Its a shame Nuke doesn't support DNG's natively. There are a few 3rd party plugins but I've found them to be a little flakey.

I've never worked with a pipeline where the vfx are done on top of the grade - sounds nice but it just isn't practical in a time sense for feature films, as they're constantly being recut right up until the deadline these days - which is why DI is done last.

I don't know how AE handles the files directly. I would too go the way through Resolve rather then AE.

Would be cool if Nuke supported DNG, but I guess working "RAW" in Nuke can bring in some problems (e.g. when you paint something, you don't copy pixels, you copy RAW data, which might be tricky to achieve). But I'm no dev. Maybe it wouldn't be too easy to implement this in a way you can work with - in the end Adobe runs nice with DPX, but horrible with DNG (which still is somehow their own format). I'd rather would want to get DPX where I can work flawlessly as ever. I mean, even the ARRIRAW stuff that comes into our house is handed me as DPX, so what

I think it depends on the feature and the effect; it's not that I don't work in a bigger production-house
We had to do an effect with a Flare-Gun and Flashs on top of a nearly white sky. It wastes only time and effort doing something about this that the client likes (even though it looks ridiculous), which you have to start at 0 again when the colorist decides to grade in a whole different direction.

I would use resolve to dpx not AE.

If any changes needed one could re render from resolve again.

Plain and simple.

Sorry Marcus missed your post somehow.

Yeah I guess that's going to have to be the way to go.

I think it depends on the feature and the effect; it's not that I don't work in a bigger production-house
We had to do an effect with a Flare-Gun and Flashs on top of a nearly white sky. It wastes only time and effort doing something about this that the client likes (even though it looks ridiculous), which you have to start at 0 again when the colorist decides to grade in a whole different direction.

Of course, every show is different. I can only speak from my experience. What show was this?

It's still in production and a german movie for cinema (doubt it will be released in other countries), so for now I may not talk about it :/

Usually we render out mattes for the grading-process, but this is tricky for inserted objects which have a behavior like light (you know the issue I guess)

Anyways. LUT? Which one

Have you seen this yet? Posted it over on the other forum.. it's the LUT that the BMCC writes to every of it's DNGs. At least all the Adobe software seems to process it, don't know if every DNG capable software will use it or some will just ignore it. It maps the 12bit RAW values in the DNG (x axis) to 16bit output values (y axis).



So as long as your DNG reading application will use that information you'll never see the "real" raw values written into the DNG. I guess it's the reverse curve for the 16 bit to 12 bit "compression"/decimation that's applied in camera before writing the DNGs.

Btw it's quite interesting how much processing/conversion steps are applied even to presumably "raw" data ..furthermore to the LUT there are the two color matrices in the DNG that contain the calibration on how the sensor data is mapped for tungsten and for daylight, and depending on the selected or recorded neutral point (=color temperature) the raw values are mapped to an interpolated point between these two matrices...

Hi there Sören,

I guess even though it's RAW it's nice that it tricks a bit to get the best out of the given bitdepth one should think 12bit is already enough, huh

Yet this is a LUT that is applied for the "compression", is this the correct LOG-LUT for that Cam? Maybe it will be tricky to "translate" that curve into Nuke :/

.furthermore to the LUT there are the two color matrices in the DNG that contain the calibration on how the sensor data is mapped for tungsten and for daylight, and depending on the selected or recorded neutral point (=color temperature) the raw values are mapped to an interpolated point between these two matrices...

So you are saying, that even if you record in raw, the temp setting in camera makes a difference?
That's interesting,

So you are saying, that even if you record in raw, the temp setting in camera makes a difference?

No, the color temperature is only a metadata value. Changing it in the software or in the camera is the same.

Instead of creating a LUT for every kelvin for a specific sensor, they just create one for Tungsten and one for Daylight and interpolate. As there is some discrepancies anyway between sensor/camera it is about almost as valid as creating a LUT that doesn't correspond exactly to your camera than just interpolating value.

Is is better to create you own Profile using calibration target using calibrated light in a controlled environment.

No, the color temperature is only a metadata value. Changing it in the software or in the camera is the same.

That's right, and neither is ideal.

The sensor has a fixed color temperature of around 5500K.

If you're shooting in tungsten light, the best way is the old fashioned way - 80A filters.

Cheers.

hm, that isn't really possible in many situations (outside in the night, for example) :/

So I downloaded a Clip in ProRes with the Film-Parameter, and got into Nuke. Doesn't look right as Cineon, but Alexav3LogC looks pretty good IMHO. Yet "good" may be far from "correct"

Yet it gives me values above 11 in the Red Channel, which is also clipped and therefore slightly rose in that clip (I guess it's the non-fixed firmware). Green+Blue are both below 11, Red is clipped above 11 - sounds a bit like Cineon, huh.

hm, that isn't really possible in many situations (outside in the night, for example) :/

So I downloaded a Clip in ProRes with the Film-Parameter, and got into Nuke. Doesn't look right as Cineon, but Alexav3LogC looks pretty good IMHO. Yet "good" may be far from "correct"

Yet it gives me values above 11 in the Red Channel, which is also clipped and therefore slightly rose in that clip (I guess it's the non-fixed firmware). Green+Blue are both below 11, Red is clipped above 11 - sounds a bit like Cineon, huh.

What I like to do is bring in the read node and set one read to RAW and stick a colorlookup node under it, and play around with the curves to get something that looks nice. Then in the other node I select preset lookups such as Cineon, Alexa etc to compare to.

I would expect the Prores lookup to be slightly different from the RAW due to the reduced amount of information stored in a compressed file.

But that difference shouldn't be a too big or even noticible.
e.g., when I get DPX made from ProRes and DPX made from ARRIRAW files, the footage of the Alexa looks quite identical when applied the right LUT. Maybe the ProRes clips sooner or has more artifacts (if any), yet the impact shouldn't be too big in this case.

But that difference shouldn't be a too big or even noticible.
e.g., when I get DPX made from ProRes and DPX made from ARRIRAW files, the footage of the Alexa looks quite identical when applied the right LUT. Maybe the ProRes clips sooner or has more artifacts (if any), yet the impact shouldn't be too big in this case.

It's very hard to test at the moment because you can import a Prores file to Nuke but not a DNG - and if you do using a 3rd party plugin they look totally different.

because it depends on the way you would handle the RAW.

That's why we work with DPX; funny enough it seems there are great workflows for the Alexa already, you know it's v3LogC and you are fine here; now you see my issue with the BMCC, why I want to know which LUT is to be used, which colorspace we are in.
Yet I have to be honest I have no idea how my company/clients handles the ARRIRAW we might get directly (I mean how they make the DPX), that is not my department.