LUT metadata development

[Blair S. Paulsen]

First of all, I have great confidence in the Red Team. They have created a terrific architecture where image data and metadata travel together but the image data remains intact throughout - lovin' it.

This thread is an attempt to see what LUT implementation people prefer and to query whether or not the metadata headers can carry more than one type of LUT. Jim Houston and some ASC guys are working on a spec. Iradias (sp?) obviously has a popular methodology, etc.

IP issues may limit options and I have no knowledge of how far RED's dev is on this but if its not too late...

Discuss.

 

[Trevor Meier]

Does build 15 address this in any way?

 

[Lucas Wilson]

First of all, I have great confidence in the Red Team. They have created a terrific architecture where image data and metadata travel together but the image data remains intact throughout - lovin' it.

This thread is an attempt to see what LUT implementation people prefer and to query whether or not the metadata headers can carry more than one type of LUT. Jim Houston and some ASC guys are working on a spec. Iradias (sp?) obviously has a popular methodology, etc.

IP issues may limit options and I have no knowledge of how far RED's dev is on this but if its not too late...

Discuss.

Hi Blair,

ASSIMILATE - and most post-production vendors - were part of Jim Houston's group that is dealing with cross-vendor LUT implementation. And certainly the ASC CDL is also a good way to go.

Problem is - what is possible in RAW on the RED ONE goes beyond what a 3D LUT and an ASC CDL are capable of translating. ; )

Lucas
-----
ASSIMILATE, inc.
LA, CA, USA

 

[Graeme Nattress]

IMHO, a 3D LUT is not the "right" tool for RAW conversions, and CDL is an inadequate tool for practically anything, including RAW conversion. Converting RAW data to "nice" RGB images is a specialized application, and is often reasonably camera dependent on the specifics of how it is achieved.

Graeme

 

[Blair S. Paulsen]

Is the ASC wasting their time?

Is the ASC wasting their time?

Based on the feedback from Luki and Graeme the ASC CDL is inadequate for the task. Does this mean that when working with DPs there is no hope of a "universal" language for color? Perhaps its as likely as one tongue for the whole planet.

In my print days we had Pantone colors which included "process" color values that assigned a number between 0 and 255 for Cyan, Magenta, Yellow and Black. There was the relatively standard SWOP space but also various "transforms" for other presses, paper stocks, etc. So I wonder...

Could there be some absolute values mated with transforms (LUTs) that would offer some functional version of a universal translator? Or is the science of color perception / wavelengths of light so complex as to resist common definitions?

 

[Graeme Nattress]

The issue here is that we're talking RAW workflow, and "developing" a RAW image is NOT the same as colouring an existing "nice" image - the toolset, methodology and mindset are very different.

The other problem with a colouring standard, is that it will necessarily have to be lowest common denominator to have any degree of cross-app compatibility, as eachapp has it's own unique way of doing the more advanced processes, often secret and proprietary. For just a simple instance, there are MANY ways of altering the saturation of an image, all of which look and act differently.

Graeme

 

[Evin Grant]

Hmmm, so I guess the Red One just has to overwhelmingly dominate the market so there is no problem with cross compatibility because there will be no crossover

 

[Dj Joofa]

Does this mean that when working with DPs there is no hope of a "universal" language for color?

Accurate color reproduction is not an easy task. With the current processing done on digital data by cameras (RAW/HD does not matter), it is not easy to have the following true *all* of the times:

(1) accurate reproduction of luminance detail
(2) color fidelity near saturated primary colors

 

[Trevor Meier]

Once the camera look files are implemented, these can be set up by DPs for the looks they want. That look follows the R3D wherever it goes, and essentially applies the RED One specific image creation (debayer etc.) Then a display processor (Truelight et al) can be used to translate e.g. for a film stock look and handle the accuracy of the image between systems (on-set Rec709 monitor, editorial computer monitor, DI suite projector etc.)

Am I right in assuming that DPs will be able to build a variety of looks and select them per shot on the camera? Will this functionality also follow through in the R3D metadata e.g. applying a new look in RedCine and that 'sticks' with the file?

 

[Blair S. Paulsen]

LUTs are the tip of the iceberg

LUTs are the tip of the iceberg

Trevor, the LUT protocols themselves are the gist of my thread. The ability to piggyback tons of metadata, including multiple LUTs, onto the RAW image data without baking anything in has always been one of the brilliant bits of the RED plan for world domination.

I am hoping that we finally get to see more of the actual implementation of the metadata topology at NAB 2008. There is such a huge upside for multiple departments both on set and through post. Obviously LUTs are a big deal but IMHO the deep integration of the metadata piece into the pipeline will create a whole new ecosystem that will dramatically improve efficiencies in the collaborative art we practice.

 

[Dj Joofa]

Will this functionality also follow through in the R3D metadata e.g. applying a new look in RedCine and that 'sticks' with the file?

It appears that R3D files have an atom-based structure (much like the Quicktime files and MPEG-4 containers), so it should not be difficult to stick in atoms of any type, even those unknown to Red One, in there.