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 :)

RedWideGamutRGB: discuss!

Graeme Nattress said:
So the main problem with CameraRGB is that although it appears as, it is not a specific colour space. However, it has the benefit that it never induces colour clipping, and that benefit is necessary not least for the issue you have here.

What I did was to take all the different CameraRGB from all the different cameras and settings and normalized them into a new colour space we call RedWideGamutRGB. RWG is a properly defined colour space, and thus can be used in a full pipeline without worry that it'll go bonkers because all the colours have gone through the calibration process to produce their values in RWG space.

The process will indeed be as you describe, so let me expand upon that a bit....

1) Process to Log3G10, REDWideGamutRGB (why - because it encompassess the DR and colours the camera produces without clipping them).
2) grade in this neutral wide gamut log space
3) apply appropriate viewing transform

For 3) you will use an appropriate viewing transform while grading, so if you're on a standard dynamic range Rec709 monitor, you'll use a transform for that. If you're on a P3 projector, there'll be a transform suitable, and if you're on one of the HDR displays you'll probably go to Rec2020 and SMPTE 2084. In any case, there will be an appropriate transform for you to use.

Say you grade on a normal SDR monitor in REC709. Now perhaps you want to see how it looks in HDR. You'l just have to swap out for an HDR transform, plug in your HDR monitor and all should be good and your grading decisions will carry through to the new viewing environment because they took place in the neutral wide gamut space.

Graeme
Click to expand...

Graeme,

What are the XYZ values of the RWG color space ?

Thanks.

- M
 
Derek Carlson said:
Total noob question, but is Log3G10 a LUT?
Click to expand...

It's a wide dynamic range log curve. Just as in the past we'd use RedLogFilm for a flat log image to grade from, we're now using Log3G10 because it stores a greater dynamic range. RLF followed the Cineon math, and although was fine at lower ISOs, at higher ISOs it would clip. Moving to a wider log curve solves that issue.

Graeme
 
Graeme Nattress said:
It's a wide dynamic range log curve. Just as in the past we'd use RedLogFilm for a flat log image to grade from, we're now using Log3G10 because it stores a greater dynamic range. RLF followed the Cineon math, and although was fine at lower ISOs, at higher ISOs it would clip. Moving to a wider log curve solves that issue.

Graeme
Click to expand...

Does this mean Log3G10 will be an available option in future camera firmware?
 
REDWideGamut and Log3G10 are coming to future camera firmware.

Graeme
 
Graeme Nattress said:
REDWideGamut and Log3G10 are coming to future camera firmware.

Graeme
Click to expand...

So, recommended would be to grade with RWG and Log3G10 even for regular Dragon 6K? I tried it and found the saturation to be very low, even after applying curves and pushed the contrasts. Is there something I'm missing (based on the earlier images which showed much greater colors than with Dragoncolor2 and Redgamma3)?

There's a lot of math back and fourth but in basic terms it's just about changing the regular DC2/RLF to RWG/Log3G10? as the starting point when grading? Do we know if Resolve features this yet?
 
Christoffer Glans said:
So, recommended would be to grade with RWG and Log3G10 even for regular Dragon 6K? I tried it and found the saturation to be very low, even after applying curves and pushed the contrasts. Is there something I'm missing (based on the earlier images which showed much greater colors than with Dragoncolor2 and Redgamma3)?

There's a lot of math back and fourth but in basic terms it's just about changing the regular DC2/RLF to RWG/Log3G10? as the starting point when grading? Do we know if Resolve features this yet?
Click to expand...
You still need to transform it back into the space you are working in, that's why you are seeing the issue with Saturation. This is meant for getting the most range without clipping while grading and then running it through proper Rec709, P3, etc for viewing/distribution
 
Graeme Nattress said:
The process will indeed be as you describe, so let me expand upon that a bit....

1) Process to Log3G10, REDWideGamutRGB (why - because it encompassess the DR and colours the camera produces without clipping them).
2) grade in this neutral wide gamut log space
3) apply appropriate viewing transform
Click to expand...

Maybe we can call this the Red Color Encoding System or RCES for short. ;) Since it is log, maybe RCEScc.

But seriously, RWG and Log3G10 is a wonderful starting point for HDR.
 
So with greater dynamic range, how many stops of latitude are we getting? Is it pushing past that 16.5+ stops? Thanks for the info Graeme.
 
Steve Sherrick said:
You still need to transform it back into the space you are working in, that's why you are seeing the issue with Saturation. This is meant for getting the most range without clipping while grading and then running it through proper Rec709, P3, etc for viewing/distribution
Click to expand...

You mean an output LUT? But from what? There has to be a starting point in conversion to say rec709, right?

Is this even possible in current versions of Resolve? And is it possible in Redcine?
 
Christoffer Glans said:
You mean an output LUT? But from what? There has to be a starting point in conversion to say rec709, right?

Is this even possible in current versions of Resolve? And is it possible in Redcine?
Click to expand...
Not available in Resolve yet, but I believe the SDK has been made available.

It is available in Redcine-X 42 Beta.

I would call the RWG and Log3G10 starting points for your grading. You need a 3x3 Matrix transform for your colorimetry as I understand it.
 
A number of posters here seem to be a bit confused, so I would suggest re-reading Graeme's description, posted back on page 3 of this thread:

1) Process to Log3G10, REDWideGamutRGB (why - because it encompassess the DR and colours the camera produces without clipping them).
2) grade in this neutral wide gamut log space
3) apply appropriate viewing transform
Click to expand...

The intent is for this to be a working color space, not a viewing color space. Much like Filmlight's Truelight color spaces, Resolve's Resolve Color Management, and to a slightly lesser degree, ACES, the intent is to provide a neutral, very wide gamut working color space that will encompass all values you might encounter or create, and still allow for a familiar "feel" from the grading controls (primarily log grading controls, i.e. exposure/offset, contrast, and contrast pivot, as well as shadow, midtone, and highlight controls). This is then followed by an output transform. In Baselight, this would be the viewing or render color space. In Resolve, it would be the output color space. In ACES, it would be the RRT/ODT (mostly the ODT). But the idea is that you aren't limited by the inherent limitations of all display color spaces while you grade. You apply a transform to view your grade result properly on whatever display you happen to be using.

I think a lot of people - particularly those using Resolve - have a problem with this approach because they like to create grading networks in which they do some things prior to a "normalizing" saturation matrix and gamma transform, and some things after. Using a working color space that is intended to be transformed at the end of the pipeline for display purposes largely precludes that type of grading approach. It has a LOT of advantages for those who are open enough to embrace "proper" color pipelines, but it does have limitations for those who aren't.

Graeme, I hope I've expressed this sensibly....... :001_unsure:
 
Graeme Nattress said:
So the main problem with CameraRGB is that although it appears as, it is not a specific colour space. However, it has the benefit that it never induces colour clipping, and that benefit is necessary not least for the issue you have here.

What I did was to take all the different CameraRGB from all the different cameras and settings and normalized them into a new colour space we call RedWideGamutRGB. RWG is a properly defined colour space, and thus can be used in a full pipeline without worry that it'll go bonkers because all the colours have gone through the calibration process to produce their values in RWG space.

The process will indeed be as you describe, so let me expand upon that a bit....

1) Process to Log3G10, REDWideGamutRGB (why - because it encompassess the DR and colours the camera produces without clipping them).
2) grade in this neutral wide gamut log space
3) apply appropriate viewing transform

For 3) you will use an appropriate viewing transform while grading, so if you're on a standard dynamic range Rec709 monitor, you'll use a transform for that. If you're on a P3 projector, there'll be a transform suitable, and if you're on one of the HDR displays you'll probably go to Rec2020 and SMPTE 2084. In any case, there will be an appropriate transform for you to use.

Say you grade on a normal SDR monitor in REC709. Now perhaps you want to see how it looks in HDR. You'l just have to swap out for an HDR transform, plug in your HDR monitor and all should be good and your grading decisions will carry through to the new viewing environment because they took place in the neutral wide gamut space.

Graeme
Click to expand...

I there a link or site for newbies to step 3? How would one go about this?
 
M Most said:
A number of posters here seem to be a bit confused, so I would suggest re-reading Graeme's description, posted back on page 3 of this thread:



The intent is for this to be a working color space, not a viewing color space. Much like Filmlight's Truelight color spaces, Resolve's Resolve Color Management, and to a slightly lesser degree, ACES, the intent is to provide a neutral, very wide gamut working color space that will encompass all values you might encounter or create, and still allow for a familiar "feel" from the grading controls (primarily log grading controls, i.e. exposure/offset, contrast, and contrast pivot, as well as shadow, midtone, and highlight controls). This is then followed by an output transform. In Baselight, this would be the viewing or render color space. In Resolve, it would be the output color space. In ACES, it would be the RRT/ODT (mostly the ODT). But the idea is that you aren't limited by the inherent limitations of all display color spaces while you grade. You apply a transform to view your grade result properly on whatever display you happen to be using.

I think a lot of people - particularly those using Resolve - have a problem with this approach because they like to create grading networks in which they do some things prior to a "normalizing" saturation matrix and gamma transform, and some things after. Using a working color space that is intended to be transformed at the end of the pipeline for display purposes largely precludes that type of grading approach. It has a LOT of advantages for those who are open enough to embrace "proper" color pipelines, but it does have limitations for those who aren't.

Graeme, I hope I've expressed this sensibly....... :001_unsure:
Click to expand...

Yes, that's pretty much it.

There's immense benefit from putting all grading between the primary log development and a view transform at the end, for, as you say a "proper" colour pipeline.

Graeme
 
Derek Carlson said:
So with greater dynamic range, how many stops of latitude are we getting? Is it pushing past that 16.5+ stops? Thanks for the info Graeme.
Click to expand...

The log encoding doesn't increase or decrease camera dynamic range, but ensure none is lost. Back with the Red One over a reasonable ISO range (remember we do ISO in software which preserves dynamic range, shifting the distribution of stops above and below mid grey) the old Cineon curve worked fine. But now the cameras have more DR to begin with and lower noise making them suitable over a wider ISO range, and the Cineon curve "ran out", or would clip the brightest parts of the dynamic range under certain development settings (like higher ISOs).

So the benefit here is not an icrease in DR, but that the curve doesn't place a practical limit on DR.

Graeme
 
You must log in or register to reply here.
Back
Top