Welcome to our community

Be a part of something great, join today!

  • 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!

I there a link or site for newbies to step 3? How would one go about this?

Don't worry there - I'm not going to leave you with an instruction for that which says "and now you're on your own". Putting RWG and Log3G10 into the SDK and RedCine-X is just the first stage.

Graeme
 
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?

So yes, RWG/Log3G10 is a grading starting point, and as M Most writes above, you'll need a display transform at the end of the grading pipe to make this work best. This initial release of RWG/Log3G10 is just the first phase.

Graeme
 
Šabović Adis;1655372 said:
What's the gamma exponent of Log3G10 relative to Linear? Is it 0.1? :biggrin:

Log3G10 is a log encoding, and although the Cineon log spec had a coeficient named "gamma", Log3G10 does not, and doesn't follow Cineon math, so I don't really know how to answer that question. Log3G10 is a wide dynamic range log encoding, similar in use / concept to ACEScc/ACESproxy, not quite as wide range as that gets a bit wasteful.

Graeme
 
So yes, RWG/Log3G10 is a grading starting point, and as M Most writes above, you'll need a display transform at the end of the grading pipe to make this work best. This initial release of RWG/Log3G10 is just the first phase.

Graeme

Just to be clear about this.. say If I was going to output a rec709 deliverable in Resolve. I'd have the RWG/Log3G10 setting set in the metadata, and would need to add a LUT into the the last node. But it'll have be a specific RWG/Log310 to rec709 LUT no? If So, are transform LUTs available to download?
 
Just to be clear about this.. say If I was going to output a rec709 deliverable in Resolve. I'd have the RWG/Log3G10 setting set in the metadata, and would need to add a LUT into the the last node. But it'll have be a specific RWG/Log310 to rec709 LUT no? If So, are transform LUTs available to download?

Roger, that's right, and that's also the aspect that is being worked on at the moment. As I mentioned, getting the RWG/Log3G10 out is the first phase that the rest is based upon.

Graeme
 
Roger, that's right, and that's also the aspect that is being worked on at the moment. As I mentioned, getting the RWG/Log3G10 out is the first phase that the rest is based upon.

Graeme

Any clue on when those transform LUTs will be available? Also, is this all being built off what you guys developed for the Panavision DXL? This is good stuff. Thanks.

Derek
 
Just to be clear about this.. say If I was going to output a rec709 deliverable in Resolve. I'd have the RWG/Log3G10 setting set in the metadata, and would need to add a LUT into the the last node. But it'll have be a specific RWG/Log310 to rec709 LUT no? If So, are transform LUTs available to download?

If working in Resolve I would use RWG/Log3G10 color space as a setting also. As for the output LUT, I've worked with output LUTs in the main settings of Resolve, but that created a bit of a problem when exporting to VFX work since when re-importing it, the output LUT would apply on top of that. So maybe using an actual node as output LUT is better.

Graeme, are you in contact with Blackmagic on implementing this color space and R3D settings in a coming update to Resolve? Can't do much real grading work without it :)
 
That's why we're getting this base component - the colour space and log curve out first into the SDK, because that gives time for 3rd parties (some of which have already done so) to implement for their users.

Graeme
 
Log3G10 is a log encoding, and although the Cineon log spec had a coeficient named "gamma", Log3G10 does not, and doesn't follow Cineon math, so I don't really know how to answer that question. Log3G10 is a wide dynamic range log encoding, similar in use / concept to ACEScc/ACESproxy, not quite as wide range as that gets a bit wasteful.

Graeme

Fair enough. :thumbsup:

I asked because encoding (or, in this case, transcoding) gamma of 0.45 means "video", 0.1 means "log" and 1 means "linear"...to me, that is. :biggrin:
 
If working in Resolve I would use RWG/Log3G10 color space as a setting also. As for the output LUT, I've worked with output LUTs in the main settings of Resolve, but that created a bit of a problem when exporting to VFX work since when re-importing it, the output LUT would apply on top of that. So maybe using an actual node as output LUT is better.

Yeah, I always preferred using the output LUT in the last node. it gives you the option to change output LUTs between scenes. Most of the time, when I send something to VFX, I'd just disable the grade, and they'd get a LOG image. It always comes back perfect.

Actually, even when I just work in RG4. I set the metadata to RLF, and in the last node, I'd use a RG4 lut. I'd do my grades before RG4 is applied.

Now keep in mind, I only ever finish in rec709/bt1886. Anything going to Digital cinema would be based off a full range rec 709 source.
 
Šabović Adis;1655681 said:
Fair enough. :thumbsup:

I asked because encoding (or, in this case, transcoding) gamma of 0.45 means "video", 0.1 means "log" and 1 means "linear"...to me, that is. :biggrin:

On a power law curve, 1.0 is indeed linear to light, and a typical gamma curve is ~0.45 to ~!0.41 (or ~0.38 for DCI). I don't think we can put log curves (of any kind really) under the same kind of math description. For log curves I always look to two pieces of information:

1) what does mid grey (18% in scene linear) map to? For Log3G10 that's 1/3 (and hence the 3 in the name)
2) what is the maxium encoded scene linear value before the log curve goes past 1.0 (and hence would get clipped when going out to an integer file format). I call this value the "extent" of the curve, and I measure it in stops above mid-grey. For Log3G10 the value is 10 stops above mid grey, (and hence the 10 in the name). For reference the "extent" of cineon is ~6.2.

Graeme
 
On a power law curve, 1.0 is indeed linear to light, and a typical gamma curve is ~0.45 to ~!0.41 (or ~0.38 for DCI). I don't think we can put log curves (of any kind really) under the same kind of math description. For log curves I always look to two pieces of information:

1) what does mid grey (18% in scene linear) map to? For Log3G10 that's 1/3 (and hence the 3 in the name)
2) what is the maxium encoded scene linear value before the log curve goes past 1.0 (and hence would get clipped when going out to an integer file format). I call this value the "extent" of the curve, and I measure it in stops above mid-grey. For Log3G10 the value is 10 stops above mid grey, (and hence the 10 in the name). For reference the "extent" of cineon is ~6.2.

Graeme

Thanks, Graeme, very useful info! :thumbsup:
 
On a power law curve, 1.0 is indeed linear to light, and a typical gamma curve is ~0.45 to ~!0.41 (or ~0.38 for DCI). I don't think we can put log curves (of any kind really) under the same kind of math description. For log curves I always look to two pieces of information:

1) what does mid grey (18% in scene linear) map to? For Log3G10 that's 1/3 (and hence the 3 in the name)
2) what is the maxium encoded scene linear value before the log curve goes past 1.0 (and hence would get clipped when going out to an integer file format). I call this value the "extent" of the curve, and I measure it in stops above mid-grey. For Log3G10 the value is 10 stops above mid grey, (and hence the 10 in the name). For reference the "extent" of cineon is ~6.2.

Graeme

Thank you Graeme.

So it's safe to say Log3G12 is 12 stops above mid gray?

Curious about the differences between Log3G10 and Log3G12. I'm toying around in my hotel room with them and finding merits to both.
 
Yes Phil. So Log3G12 has an extent of 12 stops above mid grey, so can encode 2 stops more dynamic range than Log3G10. Of course, nothing is free and those extra stops come at the cost of precision and ease-of-grading. All wide DR log curves are a bit more tricky to grade than a narrower dynamic range curve, but I felt that Log3G12 was just a bit too wide to be useful. To get a full-range HDR representation out (over SMPTE2084) you need 9.1 stops above mid grey, so although Log3G9 would work, it would just miss being able to exercise a full SMPTE2084 file, and thus I went with Log3G10.

Graeme
 
Log3G10 is a log encoding, and although the Cineon log spec had a coeficient named "gamma", Log3G10 does not, and doesn't follow Cineon math, so I don't really know how to answer that question. Log3G10 is a wide dynamic range log encoding, similar in use / concept to ACEScc/ACESproxy, not quite as wide range as that gets a bit wasteful.

Graeme


So why go RGW instead of ACES? Any advantages?
 
With ACES, AP1 is not wide enough and will cause gamut clamping issues. Also, ACES has to be designed to work with all cameras and film, whereas RED image processing systems can be designed to get the best out of a single family of cameras. And of course, nothing about RWG precludes its use in an ACES pipeline and indeed, should make interchange even easier still.

Graeme
 
Very useful and helpful information here, thank you very much Graeme.

I was going to start a little thread to get input about shooting and grading for HDR and SDR and to get a few more infos about all the color-spaces and gamma-curves, but it looks like i found what i was looking for.

Playing around with Log3G10 and REDWGRGB now and so far i like the results very much, unscientific opinion of course. But even with older footage, that i found a little problematic in the past, i was able to get nice results real quick.

And it plays cool with LUTs too.

Feels a bit like a hidden gem currently. :)
 
One of the goals is grading for both SDR and HDR Maik. In tests here I'm finding the results to be very successful.

Graeme
 
Hooray! This is exactly why I tracked down Graeme at NAB. Sorry for talking your ear off at the show Graeme. :) I can't wait to try it out!
 
Hooray! This is exactly tracked down Graeme for at NAB. Sorry for talking your ear off at the show Graeme. :) I can't wait to try it out!
That's what trade shows are for! Give it a go and tell us how you get on.

Graeme
 
Back
Top