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!

Šabović Adis;1654943 said:
Is this normally saturated, oversaturated, undersaturated?

wuiddh.jpg



qsl94i.jpg



In RCXP beta 42:
- REDWideGamutRGB
- Log3G12
- Kelvin 5600
- Tint 0
- ISO 800...

...everything default.

"Full CTB" added, and graded for brightness in NLE...by eye-ballin. :biggrin:

Second shoot with A.D.D.
Click to expand...

Did you notice that some of the diamond lights have flipped colors between daytime (first image) and nighttime (second image)? That's because the lights are made of dichroic glass, so glass that is red-transmitting in daytime is cyan-reflecting at night, teal-transmitting is magenta-reflecting, violet-transmitting is green-reflecting, and yellow-transmitting is blue-reflecting. The cobalt-blue lights are not dichroic, and thus appear nearly black at night, thought they have an oxide layer that appears to be yellow-reflecting. I would offer that the daylight-lit lights are slightly more saturated in real-life and the nighttime-lit lights are pretty fairly represented.

Nice work!
 
Michael Tiemann said:
Did you notice that some of the diamond lights have flipped colors between daytime (first image) and nighttime (second image)? That's because the lights are made of dichroic glass, so glass that is red-transmitting in daytime is cyan-reflecting at night, teal-transmitting is magenta-reflecting, violet-transmitting is green-reflecting, and yellow-transmitting is blue-reflecting. The cobalt-blue lights are not dichroic, and thus appear nearly black at night, thought they have an oxide layer that appears to be yellow-reflecting. I would offer that the daylight-lit lights are slightly more saturated in real-life and the nighttime-lit lights are pretty fairly represented.
Click to expand...


Oh, there's a window? :rofl:
I thought that was some light-show thing going on...only noticed the window in that next room.



Michael Tiemann said:
Nice work!
Click to expand...

Thanks man, nice photograph too! :thumbsup:
 
Graeme Nattress said:
Yes Mike - RWG is quite similar to CameraRGB, but it's standardized so that it is one colour space rather than an almost infinite array of spaces that differed upon the nuances of the camera, sensor and how the raw development was set up. RWG gives plenty of the benefit of CameraRGB and some new abilities, and as all the cameras get normalized into it, workflow can be greatly simplified.

Graeme
Click to expand...
As I said in another thread I LOVE THIS! You guys are just totally amazing on the weapon's color theory, my brain just popped when I saw saw this new color space on the screen. I btw am always in 10 bit color space on my monitors and normally on a ezio 318 in it's rec 2020 mode. In a VFX pipeline I think this will be perfect.

I am normally in nukex reading to linear, or from redcinex to openexr 16bit. I can't put my finger on why I love this so much. If you could give some hints to those that could use this for vfx pipeline (i.e. using this as a standard for the prevfx DI), especially things to watch out for from moving from dragoncolor2/linear to RWG/linear or RWG/redlogfilm.
 
PatrickFaith said:
If you could give some hints to those that could use this for vfx pipeline (i.e. using this as a standard for the prevfx DI), especially things to watch out for from moving from dragoncolor2/linear to RWG/linear or RWG/redlogfilm.
Click to expand...

Absolutely. That's part of the plan! I just dropped you an email on this very subject....

Graeme
 
Graeme Nattress said:
Absolutely. That's part of the plan! I just dropped you an email on this very subject....

Graeme
Click to expand...

Assimilate Scratch just dropped an update with RWG and LOG3G10 and 12, will there be any documentation from RED about these new settings?
 
Saying RWG is a bit like cameraRGB frightens me a little... With a very early on red1 shoot we got slightly burnt as the colours where more than a little crazy..

Sorry for my lay colour brain but is the potential route.. Process in RGW... grade .... then bring in a output gamut specifc LUT to bring things in line? What confuses me is what do I set my monitor to for the grade 709? P3?...

Sorry probably need to think about this a bit...

Thanks
 
Michael Lindsay said:
Saying RWG is a bit like cameraRGB frightens me a little... With a very early on red1 shoot we got slightly burnt as the colours where more than a little crazy..

Sorry for my lay colour brain but is the potential route.. Process in RGW... grade .... then bring in a output gamut specifc LUT to bring things in line? What confuses me is what do I set my monitor to for the grade 709? P3?...

Sorry probably need to think about this a bit...

Thanks
Click to expand...

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
 
Graeme Nattress said:
[...]

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.
Click to expand...

I'm guessing we'll see an update to the RED LUT kit, mapping RWG to various normalized display spaces. Exciting times!
 
Exciting indeed!

Graeme
 
Don't worry. I'm not going to force anyone to do the math if they don't want to. By putting the RWG and Log3G10 into the SDK and RC-X we're starting the process, but it's by no means the end.

Graeme
 
Graeme Nattress said:
Don't worry. I'm not going to force anyone to do the math if they don't want to. By putting the RWG and Log3G10 into the SDK and RC-X we're starting the process, but it's by no means the end.

Graeme
Click to expand...

Graeme, just to be layman-clear, this is a RED specific color space and has nothing to do with being a stand-alone exhibition color space... right?
 
This is a camera specific colour space, and not a display space. To display an image in RWG you'd transform to a display space. RWG is great for camera data, and great for working in, but no, you can't display it as it does have (necessarily) un-real primaries.

Graeme
 
Thanks Graeme... Very clear and I look forward to trying this (when I get the relevant display transforms)...


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 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...
And by all cameras, are you referring to ALL cameras in the RED lineup, including the Red One?
 
So in my test suite I keep R3D footage all the way back to the original Red One. The Red One still has unique look of its own, and yes, it works with RedWideGamutRGB. I have some nice shots of my kids on R1, and they're looking even more lovely through using REDWideGamutRGB as the processing starting point.

Graeme
 
Graeme Nattress said:
So in my test suite I keep R3D footage all the way back to the original Red One. The Red One still has unique look of its own, and yes, it works with RedWideGamutRGB. I have some nice shots of my kids on R1, and they're looking even more lovely through using REDWideGamutRGB as the processing starting point.

Graeme
Click to expand...
Very cool! I will start testing this with older footage. Amazing how the old R1 still manages to stay relevant in 2016.
 
You must log in or register to reply here.
Back
Top