RED Color - A look at REDWideGamutRGB/Log3G10

[Anton Shavlik]

Going off of what Graeme said, cineon log keeps track of numbers less than 13.5, and puts middle grey as the number 0.18. 0.18*2^6.2 is ~13.5, so at most you can have 6.2 stops above grey before cineon will clip to white.

3G10 can have values as high as 184.32, and puts grey at a value of 1/3.

1/3*2^9.1 is 184, so it can encode 9.1 stops above grey, which I guess has been rounded up to 10. Hence 3G10

If I got any of this wrong please chime in, I'm curious how it all works and am trying to follow Graeme's explanation.

edit: Graeme said it's 'linear float'. Linear means that if the sensor sees a light that's twice as bright, it records a number that's twice as big. Float means that every number has the same amount of significant digits, so (for example) if there are 5 significant digits, middle grey is .33333 (5 3's), and white is 184.32 (5 digits total). Near middle grey you'd have accuracy to 5 decimal places, but near white it's only to two, so some accuracy is theoretically lost for numbers closer to clippling in exchange for more usable dynamic range.

I think that coincidentally every stop more in highlight retention capability means one (binary) decimal place less accuracy. So 3g10 should be 4x more precise than 3g12. I hope all that is correct and helps explain what Graeme is talking about.

 

[Hrvoje Simic]

Why would one choose 3G10 over 3G12? Wouldn't you want that extra two stops of highlight latitude?

Because:
a) camera is not capable of 12 stops over mid grey (neither is it for 10 stops also, just as any cinema camera isn't), it is just a gamma allowing it so the signal doesn't get cut off by interpretation and a theoretical value;
b) you gain nothing while having to dig data out of more gamma "squeezed" signal to get a decent image, with a higher risk of image degradation.

 

[Stacey Spears]

Why would one choose 3G10 over 3G12? Wouldn't you want that extra two stops of highlight latitude?

c) Log3G10 is newer and replaces Log3G12 after further R&D.

 

[Patrick Tresch]

Log3G10 also takes less space and log3G12 is overkill because you don't have more than 10stop over mid gray on RED cameras. This is what I understand from Graeme.

Pat

 

[Hrvoje Simic]

Log3G10 also takes less space and log3G12 is overkill because you don't have more than 10stop over mid gray on RED cameras. This is what I understand from Graeme.

Pat

You don't have 10 stops over mid grey on any cinema camera. Not even close.

 

[Elsie N]

You don't have 10 stops over mid grey on any cinema camera. Not even close.

It's always been my understanding you could move "mid" grey up or down the stops the camera can see.

 

[Elsie N]

Going off of what Graeme said, cineon log keeps track of numbers less than 13.5, and puts middle grey as the number 0.18. 0.18*2^6.2 is ~13.5, so at most you can have 6.2 stops above grey before cineon will clip to white.

3G10 can have values as high as 184.32, and puts grey at a value of 1/3.

1/3*2^9.1 is 184, so it can encode 9.1 stops above grey, which I guess has been rounded up to 10. Hence 3G10

If I got any of this wrong please chime in, I'm curious how it all works and am trying to follow Graeme's explanation.

edit: Graeme said it's 'linear float'. Linear means that if the sensor sees a light that's twice as bright, it records a number that's twice as big. Float means that every number has the same amount of significant digits, so (for example) if there are 5 significant digits, middle grey is .33333 (5 3's), and white is 184.32 (5 digits total). Near middle grey you'd have accuracy to 5 decimal places, but near white it's only to two, so some accuracy is theoretically lost for numbers closer to clippling in exchange for more usable dynamic range.

I think that coincidentally every stop more in highlight retention capability means one (binary) decimal place less accuracy. So 3g10 should be 4x more precise than 3g12. I hope all that is correct and helps explain what Graeme is talking about.

I'm going to commit to this as my touchstone-for-understanding unless someone can successfully dispute it.

 

[Graeme Nattress]

Anton, that's close but not quite right....

Cineon encodes linear values up to about 13.5, giving it about 6.2 stops above mid grey headroom. The calculation is:

log2(13.5/0.18)=> 6.2288

For Log3G10 mid grey in linear light is 0.18 as always (which gets encodes as 1/3). Log3G10 can encode up to 184.32, so the math for stops above mid grey is:

log2(184.32/0.18)=> 10 (or exactly 10 stops). Your mistake was to use the encoded value of mid grey rather than the linear light value of mid grey in your calculation.

Graeme

 

[Graeme Nattress]

You don't have 10 stops over mid grey on any cinema camera. Not even close.

I have some shots here that exercise that 10 stop above mid grey range! Remember this is not a sensor data encoding curve (which would only have to worry about un-gained sensor data) but a curve for grading and thus it has to enclose camera data over a range of ISO from ~100 to ~12800 and thus it needs much more headroom than a camera encoding curve.

Graeme

 

[Michael Tiemann]

I have some shots here that exercise that 10 stop above mid grey range! Remember this is not a sensor data encoding curve (which would only have to worry about un-gained sensor data) but a curve for grading and thus it has to enclose camera data over a range of ISO from ~100 to ~12800 and thus it needs much more headroom than a camera encoding curve.

Graeme

I was actually just about to write the exact same thing! True.

 

[Graeme Nattress]

It's always been my understanding you could move "mid" grey up or down the stops the camera can see.

Mid grey in linear light is always at 0.18.

However, what is flexible is how the sensor data gets mapped so that scene mid grey lands at 0.18 in the floating point representation. This is ISO dependent.

Say we have 16 bit sensor data (with no black offset, for sake of argument and simpler math) and thus 18% is code value 11,796. Our stops above mid grey in this mapping are:
log2(65535/11,796)=> 2.474 (which is really quite low.....)

Ok. Say we now boost the ISO a stop (i.e. gain up a factor of 2). Now code value 5,898 (11,796/2=> 5,898) is being mapped to mid grey, and we have:

log2(65535/5,898)=> 3.474 stops above mid grey. So boosting the ISO gain one stop gives one stop extra highlight headroom. This is what we mean about moving mid grey up and down. We're moving what code value in the raw data represents mid grey.

Graeme

 

[Graeme Nattress]

1/3, meaning 33% IRE, I'm guessing?

IRE is an analogue voltage measurement so not very suited to describing digital video technology, but unfortunately it's still used by people.

I'm talking linear light values, so think of floating point numbers (as you'd see encoded in an EXR for instance). So 1/3 just means 0.3333333..... or 33.3333... %

The log encoding maps a full range of floating point values up to 184.32 into the 0.0 to 1.0 range. To say mid grey maps to 1/3 just means the log curve takes an input of 0.18 and produces an output of 1/3

Graeme

 

[Sabovic Adis]

I took some shots with frame averaging on, so I could go up to max ISO and thus stress the full 10,000 nit SMPTE2084 range without noise being too strong.

Graeme

You squeezed all 20 stops to 10 bit? Or to 16? No banding issues at 10 bit? :biggrin:

 

[Hrvoje Simic]

I have some shots here that exercise that 10 stop above mid grey range! Remember this is not a sensor data encoding curve (which would only have to worry about un-gained sensor data) but a curve for grading and thus it has to enclose camera data over a range of ISO from ~100 to ~12800 and thus it needs much more headroom than a camera encoding curve.

Graeme

I was referring to realistic camera capture range and in this context typically shot material, not counting in extreme scenarios and boosted values through drastic ISO rating. I understand this gives more headroom in highs for those scenarios but at the cost of lower values. Just want to avoid unrealistic expectations with DR and pushing material "just because". The tendency of underexposure has already brought a bunch of "ugh" situations in post for me and I'm sure others as well plus a bunch of "blame it on the camera" reasoning online.

 

[Graeme Nattress]

Well it's certainly realistic for stills shooting, and something I do not just to test out things, but for actual stills for my use. You're right about exposure though - you've always got to expose well for the intended application.

Graeme

 

[Joel Arvidsson]

Is there any timeframe on when the sdk is ready? Im hoping to se this in next creative cloud update.

 

[Jonathan Liebesman]

Hey Guys

Wanted to throw in my two cents since I’ve learned a ton from you guys over the years.

My taste is mainly in lower-contrast smoother images which is usually dominated by Alexa footage. The reason I’m writing this is because with the new work Graeme has done with REDWIDEGAMUT, I believe red can finally begin to own this space. (NOTE: I think the "punchy" look of Red footage on Netflix and various films totally rock too, this is just my taste preference)

What I love most about Graeme’s new work is that is smoothes out a lot of the clipping that happens in high contrast areas which are often dominated by Chromatic Abberations (light sources, highlights that clip). I love CA’s, but the way they are handled is important because IMO, when they are handled smoothly (in lumninance and color), there is a perception of "greater" dynamic range or what most producers would call "film look".

Below is a crude example of what I’m talking about… one image is dragon color 2 the other is red wideG. Both are redlogfilm and haven't been graded. They're crops from a 6k weapon Dragon at 250ASA with a Nikon 85mm lens.





At the end of the day the final graded images I end up with often have "only" 10 or so stops of dynamic range, its the “filmic” smoothness within those stops within the image i’m after. I really believe Graeme has achieved that for Red. Both Dragon and Helium (and all earlier footage) will really benefit. Now, I think the RED sensors will begin to show what they can really achieve in the Arri dominated arena because out of the box they are a great starting point for those after that smoothness who want real 4K+.

Jonathan Liebesman

ps. how do you make your username your real name?

 

[Graeme Nattress]

So the wide gamut colour space is doing its job for you Jonathan. Because it's sensor-wide, you don't get clipping that can exaggerate CA.

The benefit of using RWG as the starting space means that you don't prematurely clip colours and thus you can do better raw development or grading on top of them. Of course, the colour space is not a monitor space and is under-saturated, but if you selectively bring up that saturation in grade (or grade through an output LUT and massage the RWG image ahead of it) you can preserve whatever look you want in those hightlights and how the CA is handled.

Punchy / flat is really just a preference. For instance ACES (which takes it's look from film models) is quite a bit punchier than a default Red look, and I'm sure we're all sick of the other end of the spectrum where people pipe out log footage as if it's the finished grade!

Graeme

 

[Jonathan Liebesman]

Agreed. I think it's an incredible new starting point for a grade. Thanks so much, Graeme.

 

[Hrvoje Simic]

1.10.2016.

Heureka.

Thank you Graeme.