Red raw data space

[Michael Chenery]

I am trying to understand the best way to work with Red raw data. I am a product expert for the cineSpace CMS and have had a number of questions from customers asking what is the correct colour space to view raw data from Red One camera.

Here is an example ...
----------------------------------------------
We have two acquisition formats shot side-by-side. 10-bit DPX film scans from Technicolor (TDI) and raw data from a Red One camera. We are color correcting in Assimilate’s Scratch system.

Profiling the Cine-tal monitor at the DCI 1.0 went fine. Outputting a LUT from cineCube Visual went fine. Importing the .xml LUT into Scratch was fine. Correction film scans was fine.

When we switched to the Red data the colors within the image were not reacting as expected. We re-output a new LUT from cineCube with a custom LUT (Gamma2.2 to log) profile selected. Looks better. Do you have any gems of advice concerning the Red raw data?
----------------------------------------------

To get an accurate emulation of the print film we need to convert the raw data into log space. To do this cineSpace uses a pre-transform. To create this pre-transform correctly we need to know the characteristics of the raw data space particularly the tonal curve (gamma).

Does the raw data from the Red One camera have a native gamma response? or does it use a specified curve like Rec.709?

I don't seem to ba able to track this sort of data down easily. And was hoping someone here might know.

Also what is the recommended way of dealing with this sort of thing where material from a number of sources (film neg, Red One, etc) needs to be 'conformed' so that it can be graded together.

Any help would be most appreciated.
Thanks,
Mike

[Cüneyt Kaya]

you can have a look to the redlog LUT available in the download package of rednode
http://www.red.com/support
or ask lucas from assimilate

[Graeme Nattress]

The linearity of the native RAW data is totally linear. Black is, however, raised to preserve the noise floor in it's entirety , to 50 on the 0-4095 12bit scale.

Graeme

[shannyla]

Also what is the recommended way of dealing with this sort of thing where material from a number of sources (film neg, Red One, etc) needs to be 'conformed' so that it can be graded together.


Hi Michael, we did our first Red film the other week and we tried two approaches. The first was to export dpx files from Redcine using the PD685 profile that Redcine provides, which gave us standard printing density DPX files that we then used in Nucoda with a standard Cinespace 2383 viewing lut.

That worked just fine and obviously would work just fine in a mixed neg/Red workflow. What I can't answer as I haven't looked is if Scratch offers you those options when working directly with the .r3d files. I assume that a choice of color space has to be made somewhere in Scratch and I assume that those are the same options that Redcine offers, REC709, PD685, PD940 (?), Redlog and some other less useful options.

The other route we tried was to export the dpxs using the redlog profile from redcine. This appears to map white and black to the 0 and 1023 code values, with a mild log curve which we simply graded out in a videocentric style, no lut used. That also worked fine if we were aiming for a video finish and gave us a nice range to grade with.

Because of the software used to convert from raw and the fact that only Scratch actually accesses the native file directly, it seems to me that the native response of the camera is somewhat abstracted from the post process. By that I mean that none of the the softwares I've looked at offer any way of using the 12-bit linear image in a meaningful way.

Mail me offlist on my National Film and TV School email if you want any more details. I'm sure it's on your files somewhere.

Doug Shannon
Senior Systems Engineer
NFTS

[Deanan]

PDLog 685 is convenient but you end up with a very restricted range (this is because of the way the tangents on the standard cineon log2lin conversion go and how it doesn't relate well to digital sensor info).

REDlog is a much better choice although you will have full range data that will need to be brought up/down to be in the right visual range.