RED and 3D LUTs on Set

Hi Lucas,

I do have some questions regarding your recommendation:

"Lucas Wilson" wrote:

>> 2) SCRATCH can load REDCINE color settings.

This would load the R3D-File WITH the metadata from the camera (for. Ex.REDSpace etc.) PLUS a creative look out of REDCINE.
>> 3) Save those looks as a 3D LUT.

That would be a 3D LUT with Gamma, Colorspace and creative grade all in one, right?

>> 6) ... Use whatever camera metadata is desired, but view the output through whatever is the appropriate >>LUT.

Here's the point I'd like to ask you to explain it in more detail :
In my opinion it makes a BIG difference on the CineTAL Monitor what camera metadata is used, because the 3D LUT includes now already Gamma, Colorspace AND creative look and that will be ADDED to the camera-metada.
So far I know, to feed the CineTAL Monitor you need the REDs HD-SDI Outputs which NEVER are without Gamma correction / colorspace correction.
Shouldn’t it be a 3D LUT that is BASED on let's say REDSpace Gamma/Colorspace but having only the CHANGE from this setting stored/applied?

Cheers

+++ Florian Rettich +++
+++ Vision Control / D.I.T / D.F.T / Buttonpresser +++
+++ Munich, Germany +++
+++ http://www.digitalfilmservice.de +++

Florian Rettich wrote :

>> So far I know, to feed the CineTAL Monitor you need the REDs HD-SDI Outputs which NEVER are >>without Gamma correction / colorspace correction.

What Florian said.

Until there is either a way of getting a file result that's the same as the "live" HD-SDI feed (or HDMI, take your pick), post solutions are either going to require a good deal of hardware (you already mentioned Cinetal and Scratch - combined, that's a pretty hefty rental for a small production, although not so much for a studio picture - not to mention the requirement for Scratch at the back end as well) or be inaccurate. I believe David Mullen ran into exactly this problem recently (the disparity between what was seen on the live feed and the files that were converted using those same camera metadata settings).

I have absolutely nothing against Scratch - I'm a very satisfied user – but this is not really a generic solution. And anything that's going to Quicktime files has some built in issues already.

Mike Most
Chief Technologist
Cineworks Digital Studios
Miami, Fl.

>> Shouldn’t it be a 3D LUT that is BASED on let's say REDSpace Gamma/Colorspace but having only the >>CHANGE from this setting stored/applied?

I have to admit that I've never used Scratch, but can Scratch separate out the calibration portion of the 3D LUT from the creative portion?

For instance, think of the 3D LUT as a concatenation of a series of layers:

1) Base Layer - Calibration (Gamma, color-space matrix, white-balance)
2) Creative Layer - input from the DP that adds a creative "look" to the calibrated footage.
Once inside of Scratch, import the footage, and set the proper calibration settings so that the footage is at a common-denominator "base-level" appearance. For instance, this might be a Redspace or REC709 "neutral" setting or "default" setting.

On top of that neutral base-layer add the creative "look". Once this creative "look" has been finalized, turn *off* all the settings associated with the base layer (i.e., no gamma correction, no white-balance, no matrix settings).

After this step is complete, you should now be capable of exporting a 3D LUT that is not concatenated with the gamma settings from the RED file. The footage, when you execute this last step of disabling the calibration, will look very odd inside of Scratch, but the actual 3D LUT exported will now be ready for a proper "base-layer" neutral input, and not concatenate that "base-layer" into the 3D LUT itself, which creates the odd "doubling" effect that would occur if the monitoring output from the RED camera is already gamma-corrected, white-balanced, and has a color-space transform.

Or is there something inside of Scratch that would prevent separating out the so-called "base" calibration settings from the "creative look" settings (i.e., the controls the exact same so you can't "layer" or "stack" them up because to create the "creative" look you are actually adjusting the same sliders/settings used for creating the "base" calibration)?

Thanks,

Jason Rodriguez
Post Production Artist
Virginia Beach, VA

Hi Florian,

Answers below...

[lucas] 2) SCRATCH can load REDCINE color settings.
[florian] This would load the R3D-File WITH the metadata from the camera
(for. Ex. REDSpace etc.) PLUS a creative look out of REDCINE.
[lucas] Correct. But you do have the option of turning off any of those settings. For instance, you can turn off the metadata, and just apply the REDCINE look. Or, turn on/off Rec709 curves, add camera metadata + look. etc., etc.
-------------------------------
[lucas] 3) Save those looks as a 3D LUT.
[florian] That would be a 3D LUT with Gamma, Colorspace and creative grade all in one, right?
[lucas] Correct. Also keep in mind my answer to the 1st question - these can all be combined, or separated out. For instance, a Rec709 curve will be added as a part of the signal from the RED ONE to the Cinetal display.
So, you would not want to save that as part of the LUT coming from SCRATCH! Otherwise, the monitor will look double-LUTted (Rec 709 in HD-SDI signal + Rec 709 baked in as part of the LUT.)
Of course, this is subject to the limitations of a 3D LUT. Any kind of windowing, vignetting, or anything else that does not affect the full raster image would be discarded. Although why anyone would want to do windowing in look creation is beyond me.
---------------------------------
[lucas] 6) ... Use whatever camera metadata is desired, but view the output through whatever is the appropriate LUT.
[florian] Here's the point I'd like to ask you to explain it in more detail: In my opinion it makes a BIG difference on the CineTAL Monitor what camera metadata is used, because the 3D LUT includes now already Gamma, Colorspace AND creative look and that will be ADDED to the camera-metada. So far I know, to feed the CineTAL Monitor you need the REDs HD-SDI Outputs which NEVER are without Gamma correction / colorspace correction. Shouldn’t it be a 3D LUT that is BASED on let's say REDSpace Gamma/Colorspace but having only the CHANGE from this setting stored/applied?
[lucas] Yes. But I think (?) I addressed that in the answer above. You would need to take into account what is being "baked" into the HD-SDI signal from the RED ONE to the Cinetal, and remove that from the LUT creation in SCRATCH, which is pretty straightforward.

Lucas Wilson
ASSIMILATE, inc.
LA, CA, USA

Lucas Wilson wrote :

>>For instance, you can turn off the metadata, and just apply the REDCINE look. Or, turn on/off Rec709 >>curves, add camera metadata + look.

I think I get it, but there's the additional complication of making sure of the rendering pipeline when you're setting up the correction in Scratch. If you're going to use the Rec709 gamma curve on the live feed, when you're doing your work in Scratch you must make sure that the Rec709 curve is added before any other parameters - i.e., before the Matrix manipulations. Where that gamma curve is applied - or, perhaps more significantly, where the color manipulations are applied - is going to affect the end result. Same with all of the other settings. Concatenations of all of these parameters - color matrix, gamma, and any "look" alterations - must occur in the same processing order or the results will be different.

There's still a lot room for error here. It's not yet for the faint of heart.

Mike Most
Chief Technologist
Cineworks Digital Studios
Miami, Fl.

[mike most] There's still a lot room for error here. It's not yet for the faint of heart.
[lucas] I completely agree. But for the DP, it's pretty straightforward. It leaves most of the heavy lifting to post... where it should be for this particular scenario.

Don't get me wrong - there are still issues with this workflow. The main one is that linking up the individual LUTs to shots in dailies is a manual process based on notes taken by the DIT, Slate notes, camera reports, etc. For the simple stuff, like "Daylight Exterior," it's obvious. But for more in-depth looks on set, it requires more organization.

It's not perfect, but my main point was that there is a good way to maintain a coherent color pipeline for R3D from acquisition to DI. I've seen it work in "real life" now a few times, and people are pretty happy with the results.

Lucas Wilson
ASSIMILATE, inc.
LA, CA, USA

Mike Most wrote:

>>There's still a lot room for error here. It's not yet for the faint of heart.

Agreed. And if you are monitoring Rec709 on set, and then using that as a basis for later color work in SCRATCH or whatever in order to match your on-set look management, you are building your whole pipeline around a subset of what the RED One can actually capture, as Rec709 is usually not indicative of everything that the camera has to offer, i.e. it is usually clipped in both gamut and dynamic range.

As Mike points out, as soon as you switch from Rec709 to something else, the LUTs you used on set are meaningless. The panalog-esque no-touchy mode I would like to see RED standardize on would be a better choice than Rec709 for this kind of workflow.

I suspect that many "surprise, your dailies look weird" experiences with RED have their root in this issue. A well-intending DP used an on-set look management system based on the RED One's live output, and a well-intending transfer house made DPXs from the R3Ds using their own unique "best practices" settings that try to maintain all the data and look nothing like Rec709. Sit down in the grading suite and slap the LUT on as a starting point and you've got a DP scratching his silver beard in dismay

.
Stu Maschwitz
http://prolost.com

>>You would need to take into account what is being "baked" into the HD-SDI signal from the RED ONE to >>the Cinetal, and remove that from the LUT creation in SCRATCH, which is pretty straightforward.

Also keep in mind that the "reference" image being used to create the "creative-look" LUT has to coincide with the metadata settings on the camera's HD-SDI output.

In other words if the RED HD-SDI output will have RED-space settings applied as the "default" calibration to the signal, then the "creative look" 3D LUT needs to be created with the same reference calibration as a context. On the other-hand if it's REC709, then the 3D LUT will have to be created with a REC709 input in order to maintain WYSIWYG between the DI suite and the on-set camera monitor.

Swapping the two scenarios, where one creates a 3D LUT on top of a RED-space or REC709, etc. reference image, and then injecting that into an image stream on-set with a camera that is outputting a different base-line reference image will not create the same results as one would have seen in the DI suite. So there's actually quite a number of things that have to be kept track of and maintained in order to keep the color-pipeline consistent from set-to-post.

The top two things I feel you have to be aware of are:

1) Uncoupling any pre-calibration from the "creative look" in order to avoid "double-application" of a calibration base-line in the 3D LUT (i.e., passing a pre-calibrated image into a 3D LUT that already has a calibration setting baked-in)
2) Certifying the image being passed into the "creative look" 3D LUT on-set has the same color calibration settings as the original reference image used to create the "creative" 3D LUT in the DI suite.

And these two items go for every setting. With a couple "creative looks" this can be managed, but if the number of "looks" increases too much, this can get very complicated, especially if settings are changing in-camera.

Thanks,

Jason Rodriguez
Post Production Artist
Virginia Beach, VA

The pb here is it's a 3 step process baked in the LUT:

-What happens to transform a Linear RGB signal to what you monitor onset (and we skip the debayer, which has its importance)
-the creative input (yeah baby, more red, more sat)
-the emulation of the final target on the display if we are talking about something that would go to film

Using a CDL workflow you can separate the creative input but still need a way to carry the preprocess info and emulation target as metadata and independently. If you work with just LUTs, you can't. It caught a couple of productions I know where people would jump with LUTs more or less documented that could simply not be used; had to do reverse engineer of the display used onset and then find a way to replicate the look with the online DI system.

Even with Rec709 everywhere it's not that easy, and most of the time you want P3 for DI at the end and have to deal with colours from outer space along the post path (the editor's plasma, the blown 3D guy LCD, etc.).

Cedric Lejeune
www.workflowers.net
pipelines&workflows
La Madeleine, France

CML has just published the "Little RED Book"

This book is an edited collection of conversation's during 2009 about ways to use the RED one and how to get around any problems you may encounter.

Impress others with your knowledge!

Be the envy of your friends!

Buy it today!

Available as an A5 book or a PDF if you just can't wait!