Welcome to our community

Be a part of something great, join today!

Log in
  • 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

DCI P3, XYZ, X'Y'Z', L*a*b........ etc etc

DCI P3, XYZ, X'Y'Z', L*a*b........ etc etc

heh, heh... just stumbled over this thread while taking a break from some mind-bending Truelight colour-space and transform documents (for the umpteenth time trying to make sense out of it... getting there!).
Welcome to a whole new world of pain... gentlemen.
Glad Mike M is around to simplify explanations...

If you want the mind-bending stuff...
try the "technical notes" stuff here


oh, and for DCI setup explained, including transform formulas etc, a must-have is Glenn Kennel's Color & Mastering for Digital Cinema.
 
Last edited:
jonnycom said:
If your monitor or projector does not have a P3 preset just type these numbers in to change the white point to P3.

P3
W - .333, .334
R - .680, .320
G - .265, .690
B - .140, .070

John
Click to expand...
Minor correction, DCI spec for white is x=0.3140, y=0.3150
R, G are correct. B is x=0.150, y=0.060
Its all in the DCI specs at www.dcimovies.com
 
We have never been able to hit P3 based on our Minolta color gun using the numbers in the spec. I think it has something to do with the screens actually used in theaters. Every show we get on SR with P3 we use those numbers and they work better for us on our Christies.
 
Chris Swinbanks said:
If you want the mind-bending stuff...
try the "technical notes" stuff here

oh, and for DCI setup explained, including transform formulas etc, a must-have is Glenn Kennel's Color & Mastering for Digital Cinema.
Click to expand...

Chris,

Did a film in Canada and we're looking to license the filmlight stuff back and 2005, spent a lot of time with their docs. Ended up using one of your fellow Aus companies stuff (RSR). Their tech is now owned by Cinetal I think. We ended up with RSR's solution due to budget constraints but it was more than adequate.

I pre-ordered Glenn's book back in '06 and it's really an important read.

Both links contain good stuff. We've posted the DCI initiatives links a few pages ago. Good to have you in the discussion.

J
 
tina said:
x=0.314 and y=0.351 actually. By the way, here's an interesting article by David Richards on the how and why: http://www.movingimagetech.com/White Point-digital-ASC.pdf

Wolfgang Woehl
Click to expand...
You're correct.. i think the Barco D-cinema software has 4 dec. points.... I've seen reference's to both. DCI paper specifies 3 dec points.
The research in those papers is also referred to in Glenn's book.
Its one of those areas you need to understand, why the white point is chosen and how it is applied and what effect it has... ultimately it has great bearing on how your images look when emulated on different display systems.

I only started looking seriously into this stuff about 4-6 months ago, but have a long film scan/record b/g. I have no math background, but luckily have a very competent R&D head here who really knows his s*** (ex Kodak/Cineon) and helps sort that stuff out. But we also call on outside consultants and people like Truelight when we need to.
For example, we've bought display equipment only to find that the default colourspace values aren't actually correct in their implementation, and appear to have been misinterpreted (originally) by the manufacturer.

We got linear-light exr to DCI sorted, but it took time... now embedded in DCI to film...

There's a couple of threads running about conversions, and I'd really emphasise to anyone looking into this stuff to read as much as you can find, because the devil is in the little details, such as which colour space you're coming from and its white point, the original encoding gamma... rec709, sRGB, P3 etc...
I'm learning every day.

JonathanF, our guys did the same research in ~ 2004, after running in-house software for a few years, and went for Truelight across the facility. Everything gets calibrated through it.
There are few wizards out there, Richard Kirk is one of them.


Oh, and to the original point of this thread.. as a Red One camera user ( I run our companies camera too) I haven't really considered yet if P3 as an optional "colour space" is actually valid... off the top of my head DCI spec is g2.6 and P3 is a minimum-spec wide gamut colour space with a specific white point as discussed. The only "monitor" I have that can even use it are properly set-up Dreamcolors (close) or our Barco's.
 
Chris Swinbanks said:
Oh, and to the original point of this thread.. as a Red One camera user ( I run our companies camera too) I haven't really considered yet if P3 as an optional "colour space" is actually valid... off the top of my head DCI spec is g2.6 and P3 is a minimum-spec wide gamut colour space with a specific white point as discussed. The only "monitor" I have that can even use it are properly set-up Dreamcolors (close) or our Barco's.
Click to expand...

Chris,

That's exactly what we're using.

I'd have loved to see that earlier production invest in the Filmlight libraries. It was clearly a great option, but in the end it was a budget issue and it is supremely hard to get that kind of 6 figure commitment from management when they think they can throw a few thousand at grading and make any such issues go away.

Outside a relatively small circle of people this is a very poorly understood part of the puzzle.

The more I think about this the more I think the solution is to take linear out of the SDK and have Red supply DCI, sRGB and rec709 output/monitoring luts as part of the SDK in some common format like ITX.

This way all your color transforms are in linear float (probably on the GPU) where they should be.

What would your thoughts on that be?

J
 
JonathanF said:
Outside a relatively small circle of people this is a very poorly understood part of the puzzle.
Click to expand...
Falls into the category of "the more you know, the more you understand how little you know"...

JonathanF said:
The more I think about this the more I think the solution is to take linear out of the SDK and have Red supply DCI, sRGB and rec709 output/monitoring luts as part of the SDK in some common format like ITX.
This way all your color transforms are in linear float (probably on the GPU) where they should be.
What would your thoughts on that be?J
Click to expand...
My thoughts are probably only worth the proverbial 2c... I confess I don't know what ITX is, and Wikipedia only tells me its some sort of motherboard... :confused:

I'll work through some of my basic assumptions about the camera and debayering, feel free to blow them out of the water... but this is the basis of how we worked on "Knowing" for a film finish, could have just as easily been for a DCP...
The camera's chip will have a defined saturation point for each of R,G,B and my presumption #1 is that the the full colour-space is utilised debayering with Camera RGB. No idea where the white point is set to, but I assume that they are following SMPTE or other specs for white point based on the setting (eg rec709, sRGB etc), which you can then over-ride by doing a custom "white balance" as part of the debayer. I normally leave that default as captured, the "colourist" can play with it later.
RED's "camera colour space" debayering settings are probably the one key function I've not been able to find any defining notes (by RED) on, which is a great pity as it leaves a lot of guesswork about the process. If anyone has it please point me to it...
(Note: Just playing around with the settings in Redcine while typing this, I noticed an XYZ option which I hadn't seen before... OK if your direct to an XYZ capable projection system I guess)

#2. Being RAW data, you can debayer with any gamma you like using Custom... so gamma 1.0 leaves the data in some form of "linear-light" space, to which you can externally use a viewing lut (gamma or cube) to encode for your display and your intended finish. If its film you'll go through a film emulation cube (as per Knowing), or if its for DCP you'd use a gamma that looks appropriate for the 2.6 gamma in the DCI spec (maybe 2.2?).
Again, the colourist might vary that depending on the imagery, but you have to have a baseline somewhere.

So, my gut feeling is that we can already work to a format that is useable in a DCI-P3 viewing system, its just that we (I?) don't know what the camera's saturation point for R,G.B is in relation to the DCI-P3 specs. Does it even attain that saturation level (if compared in xyY values)?
If it does, then having a DCI setting that places white point at the spec values x=0.314, y=0.351 might have value, but how does that look on your standard rec709 monitoring system that you'd have on-set? As you suggested earlier you'd probably need a Dreamcolour setup for that particular environment (ie, dim-office unless you can get a black-out tent to view under).
Someone convince me there's a practical point to it...:wink:
 
Chris Swinbanks said:
Falls into the category of "the more you know, the more you understand how little you know"...

My thoughts are probably only worth the proverbial 2c... I confess I don't know what ITX is, and Wikipedia only tells me its some sort of motherboard... :confused:
Click to expand...

Hey Chris,

I couldn't agree with you more. The more I learn the more my head hurts and the more stupid I feel ;)

.itx is a lut format. I think was created by Iridas. Pretty commonly readable by many different apps.

Chris Swinbanks said:
#2. Being RAW data, you can debayer with any gamma you like using Custom... so gamma 1.0 leaves the data in some form of "linear-light" space, to which you can externally use a viewing lut (gamma or cube) to encode for your display and your intended finish.
Click to expand...

This is exactly the direction I'm leaning at the moment. I can't think of any advantages to doing anything other than this for the time being.

Chris Swinbanks said:
So, my gut feeling is that we can already work to a format that is useable in a DCI-P3 viewing system, its just that we (I?) don't know what the camera's saturation point for R,G.B is in relation to the DCI-P3 specs. Does it even attain that saturation level (if compared in xyY values)?
If it does, then having a DCI setting that places white point at the spec values x=0.314, y=0.351 might have value, but how does that look on your standard rec709 monitoring system that you'd have on-set? As you suggested earlier you'd probably need a Dreamcolour setup for that particular environment (ie, dim-office unless you can get a black-out tent to view under).
Click to expand...

I'd stick with rec709 on set or on location. I can't imagine any practical use to monitoring in DCI. Given the need to get down to a pretty low black point and the limits of the monitoring technology in all but the darkest environments, this seems impractical. Besides, I am of the opinion that on set monitoring can and often does go too far. DCI P3 on set monitoring capability would only give people more to fidget over and I don't see much gain there.

I remember the days of D1 video taps... monitoring in HD has been a luxury, albeit a distracting one.

Chris Swinbanks said:
Someone convince me there's a practical point to it...:wink:
Click to expand...

The conversation is a good one, because I'm having to seriously question why I really want this or if I really want it!

It could be very useful as a DIT who is responsible for making files for dailies that _may_ be projected in a DCI P3 projector could easily one light the footage on a Dreamcolor and then get quicktimes ripped out. This would require support for DCI P3 in the SDK so vendors like Yuri could include such support in tools like 3CP.

As I said in my earlier post, the more I consider this, the more I want to get linear-light out and do all the color transforms there while using a monitoring lut. Only after completion of the grade would we apply the final lut for output (which could under some conditions differ slightly from the monitoring lut anyway).

All that said, I see arguments in favor of making this an option for redline or whatever replaces it.

Cheers,

J
 
JonathanF said:
It could be very useful as a DIT who is responsible for making files for dailies that _may_ be projected in a DCI P3 projector could easily one light the footage on a Dreamcolor and then get quicktimes ripped out. This would require support for DCI P3 in the SDK so vendors like Yuri could include such support in tools like 3CP.

As I said in my earlier post, the more I consider this, the more I want to get linear-light out and do all the color transforms there while using a monitoring lut. Only after completion of the grade would we apply the final lut for output (which could under some conditions differ slightly from the monitoring lut anyway).

All that said, I see arguments in favor of making this an option for redline or whatever replaces it.

Cheers,

J
Click to expand...
Good rationale for use.
On Knowing we set-up a "baseline" for conversion using RedCine that, with an appropriate viewing lut, matched the end requirements of another vendor (DI house), and applied those settings as a default for Redline conversions of all data through a Mac farm. That way we could generate working linear-light exr files, rec709 qt's, etc, whatever we needed for each appropriate viewing environment (eg edit was in rec709) simply by pre-defining conversion factors for the end product. Fine for us with resources to throw at the problem.

For a DIT, having Redcine-X (and Redline) have a DCI-P3 colour space/gamma setting might take some guesswork out of the equation IF the end viewing environment is a TI-spec projector (or suitable monitor). But I think I'd want to minimise their screwing-around options to say just lowering or raising overall exposure to make a 1-light pleasing image for any reference material they generate.
Much like a DOP will set a basic-pack light at the lab for their film prints (at least any that still go to print!!) or telecine for transfers, as opposed to having "graded" or "color-timed" rushes.

I also think the value of this will depend on your workflow (or facilities workflow).... but that's just it with Red-stuff.. so many options on how to handle the footage.


.... oh, and if Red did implement it (DCI-P3 options), then I guess that would in effect define the camera as meeting those minimum colour specs... that would be nice to know!
 
Chris Swinbanks said:
Good rationale for use.
But I think I'd want to minimise their screwing-around options to say just lowering or raising overall exposure to make a 1-light pleasing image for any reference material they generate.

Much like a DOP will set a basic-pack light at the lab for their film prints (at least any that still go to print!!) or telecine for transfers, as opposed to having "graded" or "color-timed" rushes.
Click to expand...

Yes for dailies and rushes I'd limit this to the basic functionality provided by apps like 3CP. Others may disagree but I hardly think that this is where you want to be grading your film.
 
Chris Swinbanks said:
I also think the value of this will depend on your workflow (or facilities workflow).... but that's just it with Red-stuff.. so many options on how to handle the footage.


.... oh, and if Red did implement it (DCI-P3 options), then I guess that would in effect define the camera as meeting those minimum colour specs... that would be nice to know!
Click to expand...

And therein lies the real problem. Ideally, with an electronic camera that captures RAW data, you would like to have access to that RAW data so that it can be characterized. Once this is done, you would then apply a proper gamma curve and a color matrix to put it in whatever color space you happen to want to view it in. The problem with Red is that at least at the moment, you cannot generate a "pure" RGB image. Any image you generate using Red's tools (including the SDK, as implemented in most third party color correction solutions) already has a color matrix applied as part of the demosaic process. That matrix is not currently documented, nor can you alter it. So what you are actually getting is Red's idea of an "ideal" RGB image, including saturation. It has been reasonably clear that Red's intention for the images is an all electronic path for processing and display, and they have optimized all of their tools for this. Since P3 is really a display color space (i.e., it is output referred, not scene referred), one can currently view the images in a proper P3 monitoring path and grade them to look as they should on that display. This is, however, a step that usually happens towards the end of post production, as almost all editorial today is done on video based equipment, much of it in HD formats - which essentially dictates Rec709 as its viewing color space.

It would be nice if Red would be more forthcoming in terms of what it is doing in terms of color matrixing because that would allow those of us in post production to better tailor the images for specific display characteristics, particularly in terms of saturation. This is unlikely at the moment because that is essentially part of the debayer process that Red does not seem to want to divulge, and which has changed, sometimes significantly, on a fairly regular basis. These are subjects that will undoubtedly be brought up at the upcoming Red events (particularly the CML and ASC events). They are also one of the reasons something like the IIF proposal would be so helpful in terms of image prep for visual effects, as well as general image exchange.
 
M Most said:
And therein lies the real problem.....
Click to expand...
Thanks for the nice simple clarification, as usual Mike.
And thanks also for the comment about the "IIF proposal".. something I wasn't aware of, but will now start tracking through the various threads here, which I'm sure will lead me further.
cheers
Chris
 
Mike,

In hoping not to step on any toes, I had avoided bringing that up. Now that the cat is out of the bag I have to say that I am in agreement with you.

The industry has a long and proud tradition of working with, developing and supporting open standards. It would benefit a great number of people if this tradition was continued.

That said, with a prosumer price point I can accept their reasoning to some degree. There are enough customers that have enough knowledge to be dangerous. I sometimes feel I too fit that categorization.

There are few of us with 15+ years in the industry, who have been dealing with this stuff on a regular basis, that are willing to admit the limit of our knowledge.

I vote for a two tiered SDK and a new forum for very high level development folks who can interact with people like Deanan and Graeme coherently in an open environment, free from the prying eyes of the general public. I think it would be of benefit to all parties involved.
 
JonathanF said:
I vote for a two tiered SDK and a new forum for very high level development folks who can interact with people like Deanan and Graeme coherently in an open environment, free from the prying eyes of the general public. I think it would be of benefit to all parties involved.
Click to expand...

That's an interesting proposal, but I would say that since the SDK already has limited distribution, and every licensee of the SDK must be approved by Red, there is no need for a "two tiered" version, because by definition, everyone who is using it is already in the category of "high level development." The issue is how much information Red is comfortable divulging regarding its internal processing, and whether a happy medium can be found in which they can still protect what they consider to be proprietary, but make available enough useful information and file access to aid the developers in solving specific market issues.
 
I wish I had something worth contributing, but you guys have it all covered. Apparently, however, I need to read up more P3. I doubly agree with the need for more transparency in the limits of the SDK. Even something as simple as Jonathan's suggestion of a pair of SDK functions that "debayer without any transform" and a second "get transform for meta" (returning the composite transform for all currently specified meta-data) would be a great start. I'm not entirely sure this is possible, but it seems like a good start.
 
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.....
 
Last edited:
You must log in or register to reply here.
Back
Top