Support for DCI-P3 (SMPTE-431-2) Color/Gamma Space

[JonathanF]

I really wish someone from RED would jump in and provide some insight.

Given RED's silence on this matter so far, it makes me concerned that the camera may not be 'wide gamut' in the first place. I hope I'm wrong.

Any one know any hard-core color scientists with the right tools who could accurately profile a camera, assuming we did have RAW data?

What I'm curious is if Red is using the pre-build 16 behavior, storing the Bayer data as YCrCbY in the Red file. I suspect that YCrCbY is closest to the latent image if my understanding of what's happening is correct, but I'm a little confused about how the new color science is getting back to a pure blue channel to do those little tricks they do to reduce noise.


J

 

[JonathanF]

Just out of curiosity, does anyone have an IT8 target that they could shoot a few frames of, and the corresponding IT8/CGATS file?

I might have the transparency one. I'll have to dig around. If I do have the transparency one I could put it on a tarnsparency copier and shoot it.

I'd happily pass it around to Mike, Chris and yourself for evaluation.

J

 

[M Most]

...if I take a rec709 output image from an r3d and display it on a DCI spec projector, the colors should be oversaturated. I know this will happen because we are shifting the displayed primaries from one known (documented) gamut to another wider gamut, and the white point will be subtley different also.
But if I display it on a broadcast monitor, it should look correct... just like any other "rec709 based" cameras output.
On this train of thought, RED could perhaps

Gamut is not the only determining factor in terms of what you'll see on a display. In the case of Rec709 vs. P3, one of the primary determining factors is that Rec709 is described as having a specific gamma that is somewhere around 2.3 or so (but not exactly, the lower end of the curve is a bit different), and P3 is presumed to be at a gamma of 2.6. The shifted white point will make P3 material look a bit too pink/red on a Rec709 display, but the primary visible difference will be that of the gamma.

 

[David Mullen ASC]

What I'm curious is if Red is storing the Bayer data as YCrCbY or RGB in the R3D file. I have my preference, but I would be willing to hear arguments either way. I suspect that the YCrCbY would be closest to the latent image if my understanding of what's happening is correct.


J

Err, Jonathan, by definition, a RAW Bayer file is a monochrome image -- it's not "storing RGB", you have to create RGB, i.e. normal color, using a process that interprets and interpolates the mosaic pattern stored in the RAW image.

The "color accuracy" of that final color image would be dependent on a number of factors, from the RGB filtering of the photosites to the debayering algorithm and the final storage format, etc. Plus crosstalk would limit the purity and saturation of some colors.

There may even be some tradeoffs in sensor design between sensitivity versus color purity and accuracy, though that's just a layman's perspective on my part. I know that in the old Technicolor dye transfer printing process, one could reduce saturation in the print by switching from heavier narrow cut filters used in separating RGB to lighter broad cut filters where each color was "polluted" by some of the other two colors.

 

[Chris Swinbanks]

Chris,

I'm on my third glass of Ribero del Duero right now so take this with a healthy dose... I want a little more headroom than that in my grading suite....

Hope it was good!
Agree thats the best requirement, give me everything you've got!
As Nick points out, no debayer option at the moment in redline to exr, maybe if that could be included as a format, then thats the simplest way to get want you want...
output exr, no matrix, gamma 1. That should make it as flat and "raw" as you can get, however I expect the dynamic range will still be mapped 0-1 in the exr.
Use a film emulation cube to display via a DCI-P3 spec proj/display (currently widest gamut display as a "standard" in post), and apply your creative grade.

I think that is reasonable for a confined post path within a single facility.
Its when you have to rely on multiple facilities being involved that the "process" again has the potential to break down.

Seems there's 2 different concepts developing here..
1) How do I get "everything" to work with.. accurately emulated/converted for a film path
2) I'm not going to film, I want digital projection (DCI-P3), so can we have that as a bake-out option.

??
c

:beer:

 

[JonathanF]

Err, Jonathan, by definition, a RAW Bayer file is a monochrome image -- it's not "storing RGB", you have to create RGB, i.e. normal color, using a process that interprets and interpolates the mosaic pattern stored in the RAW image.

The "color accuracy" of that final color image would be dependent on a number of factors, from the RGB filtering of the photosites to the debayering algorithm and the final storage format, etc. Plus crosstalk would limit the purity and saturation of some colors.

There may even be some tradeoffs in sensor design between sensitivity versus color purity and accuracy, though that's just a layman's perspective on my part. I know that in the old Technicolor dye transfer printing process, one could reduce saturation in the print by switching from heavier narrow cut filters used in separating RGB to lighter broad cut filters where each color was "polluted" by some of the other two colors.

David,

From back in the pre-build 16 days they were storing YCbCrY which was a four channel file with the two green photosites (Y) each in a channel and the Cb and Cr in the other two. How they derive Cr and Cb I don't know.

It was essentially a grayscale image but that's how the data was formatted back then (from what I recall).

I'm just curious if that is still the case given the gaussian tricks they are playing on the blue channel to reduce the appearance of noise.

Are you going to be there Saturday am? If so I have a couple questions I'd love to ask you before then.

J

 

[M Most]

From back in the pre-build 16 days they were storing YCbCrY which was a four channel file with the two green photosites (Y) each in a channel and the Cb and Cr in the other two. How they derive Cr and Cb I don't know.

It was essentially a grayscale image but that's how the data was formatted back then from what I recall.

I'm just curious if that is still the case given the gaussian tricks they are playing on the blue channel to reduce the appearance of noise.

Most likely it is that or something similar. For any kind of compression scheme (including wavelet) to work, it has to be looking at a coherent image, so that it can take into account similarities and redundancies in values. By storing each component separately, you get a somewhat continuous tone image for each (rather than the mosaic of the original "coherent" Bayer pattern), so each one can be compressed effectively, restored reasonably accurately in a decompression step, and then used to do the debayer reconstruction based on the original location of each pixel.

 

[David Mullen ASC]

But is it accurate to call that "YCbCrY"? I thought that was video signal terminology.

 

[JonathanF]

But is it accurate to call that "YCbCrY"? I thought that was video signal terminology.

I believe so. Y being green and Cb being composite blue (green blue) and Cr being composite red (red green).

The video formulats for YCbCr are well documented on wikipedia, I don't know of any handy reference for YCbCrY, but I suspect the way Cb and Cr are being calculated are unique to red.

Again, we'd love to get some 'official' comments on some of this discussion.

J

 

[Kyle Mallory]

I might have the transparency one. I'll have to dig around. If I do have the transparency one I could put it on a tarnsparency copier and shoot it.

I'd happily pass it around to Mike, Chris and yourself for evaluation.

J

Forget I ever asked.. As I looked into it more, I concluded that IT8's don't cover a broad enough gamut to determine the full gamut of a device; that IT8 targets are designed for the least common denominator, and are primarily developed to cover the gamut of film stock (which may cover Rec709, but probably would not cover wide-gamut devices).

 

[Kyle Mallory]

Err, Jonathan, by definition, a RAW Bayer file is a monochrome image -- it's not "storing RGB", you have to create RGB, i.e. normal color, using a process that interprets and interpolates the mosaic pattern stored in the RAW image.

The "color accuracy" of that final color image would be dependent on a number of factors, from the RGB filtering of the photosites to the debayering algorithm and the final storage format, etc. Plus crosstalk would limit the purity and saturation of some colors.

There may even be some tradeoffs in sensor design between sensitivity versus color purity and accuracy, though that's just a layman's perspective on my part. I know that in the old Technicolor dye transfer printing process, one could reduce saturation in the print by switching from heavier narrow cut filters used in separating RGB to lighter broad cut filters where each color was "polluted" by some of the other two colors.

This is the argument I come to that pushes me back toward my previous train of thought that a profile should be build from a baseline demosaic and transform. Because ultimately, the resulting color densities ARE NOT a direct correlation to the sensitivity of a given photosite or RGBG bayer cell, but a composite of weighted sums of the surrounding photosites/cells, which could vary from pixel to pixel depending on the nature of the algorithm used, such as the gaussian magic that Color Science does to the blue channel.

 

[Kyle Mallory]

I think that is reasonable for a confined post path within a single facility.
Its when you have to rely on multiple facilities being involved that the "process" again has the potential to break down.

Seems there's 2 different concepts developing here..
1) How do I get "everything" to work with.. accurately emulated/converted for a film path
2) I'm not going to film, I want digital projection (DCI-P3), so can we have that as a bake-out option.

There is a third concept (which I think was the original point of the thread), and which plays to both of those points:

3) How do get what I have to work with "everything", accurately emulated/converted for any and all paths, whether film, HDTV or DCI-P3.

The idea being to profile the "true capabilities" of the device, first to determine whether it is "wide-gamut" enough to cover all of these color spaces, and second to get data in a format, as pure as possible (ie, with the fewest initial transforms) which can cover all of those color spaces. Of those spaces, it seems DCI-P3 has the broadest gamut, so I think that was Jonathan's initial target/request (for RED to provide DCI-P3 as a color/gamma space in the SDK)

And this ultimately has me coming back to the idea of (and maybe this is the same thing) just getting true XYZ color values out from the SDK, and use our own color/gamma transforms on that.


Ps. You guys are all making me sad that I'm not in LA this weekend... sounds like its going to be a lot of fun!

 

[Chris Swinbanks]

... accurately emulated/converted for any and all paths, whether film, HDTV or DCI-P3.

.... Of those spaces, it seems DCI-P3 has the broadest gamut, so I think that was Jonathan's initial target/request (for RED to provide DCI-P3 as a color/gamma space in the SDK)!

Hey Kyle, just want to clarify that film is still a wider gamut than DCI-P3 (see diagrams in GK's book) in which film appears to almost overlap all the P3 gamut, and P3 is a minimum spec chromaticity & white-point for TI-chip projectors, ie, the lowest common denominator, as a base "standard" that we can rely on for 2k+ digital projection.

Yep, looking forward to any info forthcoming from that meeting... hope they aren't all under NDA's!!

 

[Kyle Mallory]

Chris,

Thanks for the clarification. Unfortunately, the web seems extremely void of detailed information about the P3 space. Unfortunate, but I guess expected, since its relatively new. In this case though, perhaps the IT8 charts can still be used to profile the RED sensor, at least to the extent of knowing where the camera falls outside of a[ny particular] film gamut, and subsequently the P3 gamut.

 

[JonathanF]

Bump...

Any news on progress on this? We had some positive casual discussion on this at the ASC Red Day and I'm curious if there's any official word.

J

 

[Mark L. Pederson]

And this ultimately has me coming back to the idea of (and maybe this is the same thing) just getting true XYZ color values out from the SDK, and use our own color/gamma transforms on that.

That would be ideal. Considering that sooner or later some projectors and displays will get a wee bit wider than P3.

True XYZ color values out via the SDK makes a TON of sense.

 

[Gunleik Groven]

That would be ideal. Considering that sooner or later some projectors and displays will get a wee bit wider than P3.

True XYZ color values out via the SDK makes a TON of sense.

And again:
I agree

That would make a ton of sense

 

[JonathanF]

\The idea being to profile the "true capabilities" of the device, first to determine whether it is "wide-gamut" enough to cover all of these color spaces, and second to get data in a format, as pure as possible (ie, with the fewest initial transforms) which can cover all of those color spaces. Of those spaces, it seems DCI-P3 has the broadest gamut, so I think that was Jonathan's initial target/request (for RED to provide DCI-P3 as a color/gamma space in the SDK)

And this ultimately has me coming back to the idea of (and maybe this is the same thing) just getting true XYZ color values out from the SDK, and use our own color/gamma transforms on that.

I think this is a bit more difficult for Red, but in the end this would be WAY worth the effort. For that reason I'm totally on board with this scheme.

Good call Mal.

J

 

[Mikael Lubtchansky]

REDLine : no matrix option gone

REDLine : no matrix option gone

Am I not right in thinking that in Red Alert if you turn the matrix and curve check boxes off, set "Output LUT" to linear then render as 16 bit TIFFs, you are essentially getting sensor RAW data (albeit de-Bayered) and could then characterise it yourself. REDline also has the -noMatrix option.

It would be really useful if it were possible to turn off the matrix in camera, and output from the HD-SDI just with a REDlog LUT (to fit 12 bits into 10). Then you could use something like a Truelight On Set system.

FYI in the latest REDLINE (build 246 the) -nomatrix option is gone (it was still there in latest B194 but was no longer working).

RED highly recommends 'baking' the colorbalance into the debayering process and it seems to be a needed thing now to use the new color science and/or MX footage. Too bad we cannot get that 'raw conversion' option anymore to send the footage as DPX without any specific color or matrixing option applied during the conversion...

Mikael