RedColor3 Gamut

[Bruce Allen]

That is correct for sure. Cameras are not colorimetric devices, so don't have well defined primaries.

Yep yep yep! Need to test for that. And there isn't much good data on the web... like I said I'll have a go at fixing that next year. If the test doesn't cost me too much money, of course.

Anyway, here's my quick plot of the primaries of Sony's S-Gamut (which we agree doesn't necessarily represent the camera's actual primaries) against some other color spaces.

I stuck in the primaries of my DreamColor monitor plus the measured primaries of the only mass-market laser display TV I know of just for fun.

Not 100% sure I entered the numbers right for everything. Need to check. But it looks roughly right

BTW since UHDTV seems to encompass most displayable colors (and a large majority of the colors found in nature), I do wonder if mastering in UHDTV might not be a simpler alternative to ACES...

Bruce Allen
www.boacinema.com

 

[ericyoung]

ACES is supposed to encompass all forseeable future gamuts to allow it to handle translations between all colour spaces. So while mastering to UHDTV might be simpler at present, it does not accomplish the ultimate goal of ACES.

 

[Graeme Nattress]

ACES is supposed to encompass all forseeable future gamuts to allow it to handle translations between all colour spaces. So while mastering to UHDTV might be simpler at present, it does not accomplish the ultimate goal of ACES.

We've had XYZ for that purpose since forever though. And as I point out above, as long as you don't clamp, all colour spaces have the same wide gamut.... If you're mastering, you're making colour decisions based on whatever the best display is you have available, so although you may think you're storing very wide gamut data, chances is there's not much left, and what is left you've not seen, so when you get to that new, wider-gamut display, you won't know what it actually looks like until you try.

Graeme

 

[Gabriele Turchi]

graeme ,
so you saying that whatever color spcae we pick ( redspace , redcolor , redcolor 2 , redcolor 2 )all of them are suitable for whatever delivery media we are working for : like Rec 709 for broadcast or P3 for DCP release ?

thanks
g

 

[Graeme Nattress]

REDColor3 is the most suitable. As long as you don't clip, so say you're exporting REDLogFilm all the colours are still there.

Graeme

 

[Les Dittert]

The limitations of RED color ( or any electronic sensor color ) are derived from two things:
1) The spectral response of the CFA used, and
2) The limitations of the 3D lut ( cube dimensions, usable bit depth, interpolation quirks ).
If the LUT is working 'hard' in a color area that has little good data to go from, as in when the lut is very 'steep' and might be prone to shears you end up with troublesome things like posterization or noisy output color.

Graeme works hard to refine 2) to get pleasing results from the camera. Color is very hard. I was responsible for color at Dreamworks Animation for 4 years. Animation is even worse than live action, they pick colors that are hardley even seen in nature even

 

[Bruce Allen]

ACES is supposed to encompass all forseeable future gamuts to allow it to handle translations between all colour spaces. So while mastering to UHDTV might be simpler at present, it does not accomplish the ultimate goal of ACES.

OK but there is a law of diminishing returns because UHDTV:

1. Encompasses very close to the real gamut found in nature (Pointer colors)
2. Encompasses reasonably close to the max laser display gamut (depending on what nanometer lasers you pick) - and laser-level saturation is pretty close to human vision maximums, I think.
3. As Graeme said, you can always go over 1.0 for HDR

We've had XYZ for that purpose since forever though. And as I point out above, as long as you don't clamp, all colour spaces have the same wide gamut....

Totally agree! My only 2c is:

1. If using a very narrow color space (eg 709) to get an out-of-gamut dark saturated red you have to have values of R=150%, G= NEGATIVE 50%, B= NEGATIVE 50%. Negative numbers for additive light is just a weird hack and likely messes up stuff.
2. My guess is that XYZ is not a good space for compositing so ACES was invented to have color primaries that are in a more natural orientation and work well with normal color operations (eg you don't have to rewrite all your Nuke filters).

If you're mastering, you're making colour decisions based on whatever the best display is you have available, so although you may think you're storing very wide gamut data, chances is there's not much left, and what is left you've not seen, so when you get to that new, wider-gamut display, you won't know what it actually looks like until you try.

Yesyesyes!

The limitations of RED color ( or any electronic sensor color ) are derived from two things:
1) The spectral response of the CFA used, and
2) The limitations of the 3D lut ( cube dimensions, usable bit depth, interpolation quirks ).
If the LUT is working 'hard' in a color area that has little good data to go from, as in when the lut is very 'steep' and might be prone to shears you end up with troublesome things like posterization or noisy output color.

Graeme works hard to refine 2) to get pleasing results from the camera. Color is very hard. I was responsible for color at Dreamworks Animation for 4 years. Animation is even worse than live action, they pick colors that are hardley even seen in nature even

Yesyesyesyes!

And that's why I've been bugging RED about CFA filters every since they announced Dragon.

One thing is that bad CFAs that let through stuff they shouldn't... result in higher camera sensitivity.

So that's why I feel the need to put my vote in for CFA filtering quality every time the rabble voice their need for native ISO 12800

Yes to dynamic range, but with a great CFA, please.

I am not worried about part 2 (the Graeme algorithm part) at all...

Bruce Allen
www.boacinema.com

 

[Graeme Nattress]

Bruce, be aware that ACES has a -ve primary so doesn't eliminate the compositing issues you mention. XYZ should eliminate -ves though. In the end, there's never quite a perfect RGB space for things, but as long as you keep the math straight you should be able to losslessly use whatever space is appropriate....

Have you found what's wrong with the Sony diagram yet?

Graeme

 

[Andrey B]

Have you found what's wrong with the Sony diagram yet?

Let me guess. Is it a negative numbers along Y axis?
Oh and looks like S-Gamut curve have more range by X axis to the right than even the ACES range.
And looking to the bootom of the S-Gamut it is out of the range of the ACES range too.

Am I stupid here?

 

[Bruce Allen]

Bruce, be aware that ACES has a -ve primary so doesn't eliminate the compositing issues you mention. XYZ should eliminate -ves though. In the end, there's never quite a perfect RGB space for things, but as long as you keep the math straight you should be able to losslessly use whatever space is appropriate....

Totally agree that if you do the math right, you should be able to losslessly use whatever space is appropriate.

What I meant was not that the XYZ of the primaries need to be positive... but that real world colors should be represented by positive values without having to mix in negative values for other numbers.

If I have VERY DARK, RICH BLUE... you do not want to represent it as BLUE 200%, RED -100%, GREEN -100%. Which is what I have to do if using 709. Right?

You want wide primaries so VERY DARK, RICH BLUE = BLUE 50%, RED 0%, GREEN 0%.

And then INSANELY BRIGHT, INSANELY RICH BLUE is BLUE 300%, RED 0%, GREEN 0%.

XYZ would work... except that so much of image processing algorithms are written for R, G, B primaries. So it is a non-starter.

That leaves me with ACES or UHDTV space as possibilities.

Or, if I wanted to be weird, I could use S-GAMUT or ProPhoto...

P3 is pointless because it's little more than 709... so why go to all the effort for such a minor change?

Have you found what's wrong with the Sony diagram yet?

Yes! I think they got the DCI green primary wrong, haha... stupid because actually it makes a better case for why you'd want to shoot F65 - eg show that those colors the F65 might be capturing are useful, projectable colors. Although my 2c is that I'd rather have good subtle colors rather than bright stuff since invariably I'll be manipulating the brights a lot anyway. But hey, I wouldn't complain if we got both!

Here's my attempt. Drew it by hand so might not match up 100%...

Here's my overlay of the two. I really need to take out some lines and do one of those animated .gifs instead... this is insanely confusing.

Bruce Allen
www.boacinema.com

 

[Graeme Nattress]

From the chart I was looking at, that was similar to the one you've been using above, what they had plotted as ITU-709 wasn't. I don't know what it is, but it's a lot smaller than 709. What they had labeled as DCI was in fact REC709.

Indeed, XYZ is not designed for general image processing work, but it's the space to use for transferring around between various RGB spaces. Yes, we generally don't want to do processing on -ve numbers either. What it comes down to is that there's not one "always appropriate" colour space for all image processing operations. I think we have to resign ourselves to the fact that we do need to move between spaces as appropriate.

Graeme

 

[Mike P.]

Where does RLF fit in on that chart?

Pardon my ignorance; (I'm going by Bruce's last chart) but I can't help but notice F65/35 with S-log were much greater than even the film print gamut (which seems to make sense as a film replacement.)

 

[Graeme Nattress]

RLF is not something that goes on such a chart.

But Mike, I'd be careful as what you're seeing there is badly plotted for the known colour spaces. If they can't get the standards right.... And as gamuts are 3D, 2D gamuts are also rather misleading. Just FYI....

Graeme

 

[Mike P.]

If RLF shouldn't be on that chart, why is F35/S-log on there (like why the distinction and how does S-log [which is gamma] offer a wider colour space)? Conversely, if Epic/Scarlet shoot footage that is much wider than rec709 (or film print) than what makes it so difficult getting it into the Rec709 colour space? I mean the light spectrum never changes so you'd have only one variable (e.g. Light * "LUT"/ColourSpace = Rec709, where Light and Rec709 should always be the same, no?)

... I think I should get out of this thread.

p.s. I apologize for my simplifications... Obviously it's more complicated, but couldn't a brute force method be used?

 

[Bruce Allen]

From the chart I was looking at, that was similar to the one you've been using above, what they had plotted as ITU-709 wasn't. I don't know what it is, but it's a lot smaller than 709. What they had labeled as DCI was in fact REC709.

Bwahaha, that's quite possible! Especially since they don't number their axes They did make a number of mistakes with the F5 launch too - I think their official brochure on the F5 was made by copying the F55 one and changing a few things. For one thing, it still has a screenshot of the F55's LCD, set to record 4K internally to XAVC!

Indeed, XYZ is not designed for general image processing work, but it's the space to use for transferring around between various RGB spaces. Yes, we generally don't want to do processing on -ve numbers either. What it comes down to is that there's not one "always appropriate" colour space for all image processing operations. I think we have to resign ourselves to the fact that we do need to move between spaces as appropriate.

Yes, sadly agree! And boy when ACES becomes standard, it sure is going to be quite confusing what with RDTs, ODTs, whatevertheheckDT!

I don't look forward to explaining all of that o every VFX freelancer either... they are not going to stand a chance! Or us supervisors will go mad trying to explain it to them.

Ah man, this all makes me want to crawl into a hole and hibernate for 10 years until everything just gets sorted out better Either that or raise my day rate.

Bruce Allen
www.boacinema.com

 

[Nick Shaw]

If RLF shouldn't be on that chart, why is F35/S-log on there

S-Log is not on there. S-Gamut is the colour space Sony uses paired with S-Log, in the same way RED pairs REDcolor3 with REDgamma3 or REDlogFilm.

 

[Mike P.]

S-Log is not on there. S-Gamut is the colour space Sony uses paired with S-Log, in the same way RED pairs REDcolor3 with REDgamma3 or REDlogFilm.

Derrrp... thanks. And thanks for confirming that I definitely should have bailed out of this thread.