13 Stops with 12 Bits?

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.