Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

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

only trouble is there's a problem pinning that stuff to the sensor, keeping it steady, then moving it to the next frame... at least in a Red... ;-P



actually... maybe if I just use my hybr.e.d camera...

Hybred.jpg



...OK, so Jonathon (or someone) removed his post about tech-data for 5207.... this kinda loses its punch.....

Sorry Chris,

I was asking Mike and Kyle if something like this kind of standard information we get from Kodak might make life easier:I absolutely understand the need to profile things accurately. After your experience on numerous projects at AL (especially doing VFX post) I assume your opinions on the subject are similar. Chime in if my assumptions are wrong.

;)

J
 

Where did you get those mickey mouse ears for your camera? I want to send those out with my next rental!

I can't answer Jonathan's question. Looking of the data sheet, I'm sure it would be meaningful for someone, but I personally wouldn't know what to do with it at this point. Having said that, I'm confident that if that information was available for the R1, and I gave it a few days/weeks to sink in, I could find a way to relate it, and make it meaningful.

Specifically, I would hope that the LOG EXPOSURE curve wouldn't be a curve at all (rather a linear line), since we are talking CMOS sensors, but I think whatever this graph ultimately ended up representing for the R1 would be useful information.

While the MTF would be interesting to see, we aren't talking about an alterable value of photosensitive chemical densities. Ie, we know the densities of Red, Green, and Blue photosites ( 1:2:1 / 4 ).

Spectural Sensitivity could help in building a proper determination of the camera's native white-point. How, I'm not entirely sure.

So, would this information be useful? Of course. Could I use it immediately? Probably not (though I'm sure others could). But that shouldn't prevent it from being available.
 
Not wrong Jonathon... it was getting late and after reading up wedges through the day, still working through the vagaries of Filmlight's Truelight Profiles and commands (this is tough stuff) and seeing your post, I just had a silly idea about bringing it all together...
Feeling much better now.. just had my morning coffee and about to start all over again (as per above!)
I think Mike's earlier post summed it all up, there's just some technical data about the camera/sensor/colour conversion that hasn't been released which could help those smart enough (probably not me) put a definitive value on the capabilities of the sensor (in gammut terms) to define transforms better.
I managed to dig out the gamma curves fairly early in the piece, but the "color space" is still the mystery bag... and that means it remains a creative process to get the image to an end point, as opposed to what we're used to doing in certain areas of post which is to ensure technical neutrality of any conversion.

So, I think your comparison to Kodak's data sheet is not off-the-mark... maybe it's something that RED can't provide... I don't know.. I'm sure there's a few colour-scientists out there that know enough about CMOS sensors that they could make some very definite evaluations about this stuff.
 
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.

Glad to see somebody else has been enjoying the bit of light reading that is the FilmLight technical documents! Hard going but very informative stuff.
 
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.
You're right Nick.. just had a quick play with that... I only ever used RedAlert very briefly, and mainly use RedCine as a conversion tool (or redline commands for large project(s)). It looks like RedCine doesn't have a way to disable the matrixing during debayer... will check RedCine-X out later.
This is diverting me from my main game at the moment... but food for thought when I get some time...
cheers
Chris
 
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

I might be wrong about this (Graeme, feel free to clarify this) but the "no matrix" option in Red Alert only turns off the additional settings from the metadata, it doesn't defeat the matrix that is applied as part of the Debayer operation.
 
Would be good to get that clarified, Mike... but I think Nick is correct from what I can tell.

I"m looking at a Macbeth chart r3d in Red Alert. Visually, if the matrix and curves are not checked (ie, turned off), and I select a gamma curve that allows me to see the image reasonably well (redspace or rec709), then I can switch the Color Space through Redspace, Camera RGB and rec709 and there is no change to the image.
So switch to linear light (g1.0), the image is much darker as expected, and there is no change regardless of which color space I select, unless I also select matrix...

....and hovering over the matrix button, a pop-up just verified "Enable / Disable Matrix (White Balance and Colour Correction)" NB. their spelling for "colour", not mine!
 
I"m looking at a Macbeth chart r3d in Red Alert. Visually, if the matrix and curves are not checked (ie, turned off), and I select a gamma curve that allows me to see the image reasonably well (redspace or rec709), then I can switch the Color Space through Redspace, Camera RGB and rec709 and there is no change to the image.
So switch to linear light (g1.0), the image is much darker as expected, and there is no change regardless of which color space I select, unless I also select matrix...

All of the parameters you mentioned are post-applied effects. That's not what I'm talking about. I've been told by a number of parties that a color matrix is applied as part of the debayer process itself, and thus "embedded" in the data that is then passed to those post applied parameters. That's what I'm talking about.

....and hovering over the matrix button, a pop-up just verified "Enable / Disable Matrix (White Balance and Colour Correction)" NB. their spelling for "colour", not mine!

Well, Red Alert WAS written by a Canadian....
 
I've been told by a number of parties that a color matrix is applied as part of the debayer process itself, and thus "embedded" in the data that is then passed to those post applied parameters. That's what I'm talking about.
OK, thanks Mike... further back under the hood, then.. and deep into Graeme's "colour-science" no doubt...
 
Mike,

What is the value in having the pre-transform color? (I'm genuinely curious) Are you concerned that this transform is limiting the resulting color gamut? I've been going over this whole P3/XYZ/Rec.709/etc in my head, and I'm finding it a bit confusing and contradictory.

If the resulting color gamut after the initial transform is within the limits of the chosen color space, does it matter if the transform is occurring? Admittedly, it limits our ability profile the sensor itself, but does that matter? All that really matters is that we understand the primaries and whitepoint of a baseline image from the camera, right?

Like everyone else, I'm trying to make sense of this too... It's just so damn confusing sometimes.
 
If the resulting color gamut after the initial transform is within the limits of the chosen color space, does it matter if the transform is occurring? Admittedly, it limits our ability profile the sensor itself, but does that matter? All that really matters is that we understand the primaries and whitepoint of a baseline image from the camera, right?

Not if one wants to develop a post path that is based on scene referred values. And not if one wants to develop a path that is truly optimized for a film targeted DI path. And right now, there are groups that want to do both.
 
Not if one wants to develop a post path that is based on scene referred values. And not if one wants to develop a path that is truly optimized for a film targeted DI path. And right now, there are groups that want to do both.

In fact Mike, this is the most common situation in post. Part of why this is all so very frustrating.
 
If the resulting color gamut after the initial transform is within the limits of the chosen color space, does it matter if the transform is occurring?


As part of running this over in my head again... I recall from a Sony supported presentation about the F35 that they showed a CIE diagram presenting the "wide-colour" gamut of the F35 sensor.
Easy enough to find a copy of it in the brochure (but I won't reproduce it here).

They way I see the point of this thread, is that if someone wants the camera to be able to have a DCI-P3 color gamut option at the flic of a switch or menu, then the sensor's output gamut (debayered/matrixed) must cover the area shown by the DCDM (purple) line in the plot as shown in the brochure.... and then the underlying color-science can map the primaries and white as required to fit. If it does that, then I don't think I need to know any more specifically to fit it into my general workflow for film output, I have other tools for that.

What we don't know at the moment is if it meets the criteria for the above....
eg 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 implement a DCI-P3 colour option without giving any further info as long as we knew that the images created and debayered would be correctly displayed on a DCI projector, because Graeme has done the science and says it does!
We all trust Graeme, don't we...!



oh damn... is getting late again... my head hurts... bloody colour science

;-P
 
They way I see the point of this thread, is that if someone wants the camera to be able to have a DCI-P3 color gamut option at the flic of a switch or menu, then the sensor's output gamut (debayered/matrixed) must cover the area shown by the DCDM (purple) line in the plot as shown in the brochure.... and then the underlying color-science can map the primaries and white as required to fit. If it does that, then I don't think I need to know any more specifically to fit it into my general workflow for film output, I have other tools for that.

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.

What I would really like, assuming the sensor is wider gamut than DCI (which we aren't going to know until we get to profile it), is to have the ability to grade on linearized raw where I'll get the greatest headroom to shove my footage around, then I can apply the transform into my output colorspace after I have graded my footage.

Any transform into viewing gamuts is going to pinch your data.

I can apply a linear to DCI monitoring lut while I'm grading to see what I'm going to get after that final transform.

The problem with outputting to DCI (or rec709) on the SDK end before grading is that you're stuck in that smaller, more limited gamut when you go to grade the film. This is NOT where you want to be if you need maximum room for creative color correction/control/grading.

Does that make sense or am I ranting nonsensically like other drunks we know and love?

J
 
Any transform into viewing gamuts is going to pinch your data.

I can apply a linear to DCI monitoring lut while I'm grading to see what I'm going to get after that final transform.

The problem with outputting to DCI (or rec709) on the SDK end before grading is that you're stuck in that smaller, more limited gamut when you go to grade the film. This is NOT where you want to be if you need maximum room for creative color correction/control/grading.

Does that make sense or am I ranting nonsensically like other drunks we know and love?

J

Well, I'd say this is the whole point, isn't it.

And thus, I wholly support this idea!
 
I might be wrong about this (Graeme, feel free to clarify this) but the "no matrix" option in Red Alert only turns off the additional settings from the metadata, it doesn't defeat the matrix that is applied as part of the Debayer operation.

I too may be wrong, but I seem to remember doing some testing with two versions of Red Alert when the New Colo(u)r Science first came out and finding that the result from old and new CS was identical when the matrix was off. This might be taken as empirical evidence that the matrices used in de-Bayering are only spatial, and do not affect the gamut.

However even if this is correct, things are still not easy. Although -noMatrix is available in Red Alert and REDline, I do not believe it is available through the SDK. So we would be limited to rendering without a matrix to either DPX (but that is 10 bit only in Red Alert so not suitable for linear) or TIFF (which carries no meta-data). Maybe you could decode as both, then combine the meta-data from the DPXs and the image from the TIFFs into EXRs, but that's hardly an ideal workflow!

Then we come to the HD-SDI output from the camera. Being 4:2:2 Y'CbCr it is less than ideal for carrying RAW image data to be processed through an external LUT. Even if view RAW gives the equivalent of -noMatrix and gamma=2.2 (anybody tested if that is the case) if you could invert the output LUT to give linear sensor RAW data it would probably be horribly quantised with a clipped gamut due to the RGB>Y'CbCr transform.

Anyway food for thought.
 
On this train of thought, RED could perhaps implement a DCI-P3 colour option without giving any further info as long as we knew that the images created and debayered would be correctly displayed on a DCI projector, because Graeme has done the science and says it does!
We all trust Graeme, don't we...!



oh damn... is getting late again... my head hurts... bloody colour science

;-P

GREAT idea. Maybe this will be possible with FLUT.
 
Not if one wants to develop a post path that is based on scene referred values. And not if one wants to develop a path that is truly optimized for a film targeted DI path. And right now, there are groups that want to do both.

I guess it ultimately depends on WHAT that transform is. I think I'm following Chris's logic. If a 'baseline' output of the camera (regardless of transforms) can be profiled within the color gamut of film, then you should ultimately have a path that is suitable for film, so long as those transforms are consistent across all footage ran through that path.

Of course, this is all based on building a profile for a given "export" from the camera, whether that export is the raw sensor data, or after a baseline transform to neutralize the white point and color primaries, all that should matter is that 1) it remains consistent, and 2) the resulting gamut encompasses the target gamut without a loss of precision.

I think I might have argued against my own defense just then, since those "hidden transforms" can ultimately hide the true gamut of the sensor, making it appear to be wide gamut, when in fact it may not be. 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?
 
Back
Top