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

RedLogFilm vs Log3G12

Mike Krumlauf

Well-known member
Joined
Mar 1, 2008
Messages
395
Reaction score
23
Points
18
Age
35
Location
Denver, CO
Website
www.youtube.com
Just wondering which gamma curve takes the most use out of the MX Chip in the Scarlet and provides the widest dynamic range and highlight protection? Is Log3G12 built for newer sensors or can I actually benefit from it on the MX Sensor?
 
Mike,


The IPP2 RedWideGamut/ LOG3G10 Color Space and Gamma was designed to optimize the images from the RED Sensors in both Old and New Red Cameras
 
Mike,


The IPP2 RedWideGamut/ LOG3G10 Color Space and Gamma was designed to optimize the images from the RED Sensors in both Old and New Red Cameras

Awesome, thanks! I figured, just wanted to make sure. :)
 
Yeah, just to confirm, along with RWG/Log3G10, IPP2 had debayer tweaks for sharper/cleaner images and it has a bit of highlight reconstruction (to eeek out a bit more roll-off detail). Nothing magical mind you, but hey, it's free!

So yeah, it's better all around. The only time I'd use RLF is if you have an established workflow that does a lot of what IPP2 does manually/by hand/eye...
 
Yeah, just to confirm, along with RWG/Log3G10, IPP2 had debayer tweaks for sharper/cleaner images and it has a bit of highlight reconstruction (to eeek out a bit more roll-off detail). Nothing magical mind you, but hey, it's free!

So yeah, it's better all around. The only time I'd use RLF is if you have an established workflow that does a lot of what IPP2 does manually/by hand/eye...

Great additional info Mike P!
 
Everyone covered everything already but I do want to add that Log3g10 is the one you want to use, not Log3g12. As I understand, that gamma curve allows more dynamic range (12 stops over mid grey, hence the name) at the cost of some precision. G10 (10 stops over mid grey) is more suitable for all current and past cameras.
 
Everyone covered everything already but I do want to add that Log3g10 is the one you want to use, not Log3g12. As I understand, that gamma curve allows more dynamic range (12 stops over mid grey, hence the name) at the cost of some precision. G10 (10 stops over mid grey) is more suitable for all current and past cameras.

Interesting. So, why have the LOG3G12 at all? Or is that something specific to working in a HDR workflow?
 
RLF is the Cineon curve. It can encode a float value up to about 13.5 beyond which point you'll clip. That's good for film and older cameras, but as dynamic range has increased, and higher ISO gains are usable, it runs out of room. HDR SMPTE2084 needs to encode a wide brightness range up to 10,000nits, and thus we need a log curve with a wider range. ACES has CC / CCT which can encode a float value over 100, significantly greater than Cineon. Initial HDR implementation on Red was done with Log3G12 which puts 12 stops above mid grey, but it was a bit wider range than necessary, hence Log3G10 which encodes float values to 184.32 - enough for full HDR, and high ISO gains on modern low noise sensors.

So for "normal" ISO, pretty much all log curves are sufficient. However, as IPP2 is based on Log3G10, it makes sense to use that curve along with RWG and access the wide range of LUTs and transforms of that system.

Graeme
 
Well if I am not mistaken, I dont have the option to shoot 3G10 in my camera, just 3G12 appears. Could be wrong, but last I checked the only LOG gamma in the camera is the 12 one aside from RLF.
 
You might be mistaken.

Don't get me wrong; RED, for whatever (dumb?) reason, didn't put RWG internally to DSMC1 MX cameras, but I have mine set to RC4/Log3G10 (and then a wonky/homebrew RG4>RWG-to-MedCon/VerySoft Roll-Off LUT) to a Ninja V that has LUT support. Is it ghetto? Yes. Should MX cameras have been updated with both RWG and not just Log3G10? Definitely Yes. But do MX camera support a Log3G10 gamma? Also Yes.

That's not even the wild part. What's crazy is when you put a mag in the MX camera that has footage on it that was captured by a Dragon camera (DSMC1 Dragon has RWG support, along with DC1 and DC2, none of which are selectable in MX cameras). It reads/displays the footage with the recorded colourspace/gamma! I know, right?
 
Last edited:
Should MX cameras have been updated with both RWG and not just Log3G10? Definitely Yes.

Do DSMC1 cameras have the hardware to run IPP2 internally?
 
Do DSMC1 cameras have the hardware to run IPP2 internally?

Oh hellz naw. But they can do RWG/Log3G10 (and even convert to a normalized DC2/RG4 on your display independent of setting the captured r3d as RWG/Log3G10)... on Dragon.

And you can take those dragon captured files and put the mag in an MX camera and they’re displayed as was set on the Dragon... (with colourspaces that aren’t selectable on MX).

And you can select 3G10 as the gamma on MX cameras, but you *can’t* select RWG as the colourspace, so none of the standard RED-provided tone/roll-off LUTs work since the MX outputs only do RC4/3G10 (hence you have to roll-your-own LUT to do RC4-to-RWG-then-have-the-IPP2-LUTs-applied).

It’s such a bizarre ‘1-step-forward-2-steps-back’/‘give you everything except what you actually need’ type of thing, that I wondered if my firmware didn’t flash properly or an “advanced controls” thing like RCXp or something...
 
Last edited:
Upon looking at the menus, the gamma in the Scarlet X is indeed 3G"10" not 12. Phew... :)
 
RLF is the Cineon curve. It can encode a float value up to about 13.5 beyond which point you'll clip. That's good for film and older cameras, but as dynamic range has increased, and higher ISO gains are usable, it runs out of room. HDR SMPTE2084 needs to encode a wide brightness range up to 10,000nits, and thus we need a log curve with a wider range. ACES has CC / CCT which can encode a float value over 100, significantly greater than Cineon. Initial HDR implementation on Red was done with Log3G12 which puts 12 stops above mid grey, but it was a bit wider range than necessary, hence Log3G10 which encodes float values to 184.32 - enough for full HDR, and high ISO gains on modern low noise sensors.

So for "normal" ISO, pretty much all log curves are sufficient. However, as IPP2 is based on Log3G10, it makes sense to use that curve along with RWG and access the wide range of LUTs and transforms of that system.

Graeme


Cheers, Graeme!
 
So I guess my final question on the matter is, When using LOG3G10 in the Scarlet MX, what is the usable dynamic range of the sensor? Has it improved compared to the results one can get using RedLogFilm?
 
Not really, no. Like it's no better than shooting the r3d at DC4/RG4 and then changing it to RWG/Log3G10/IPP2 in post.

That said, if you're going to an off-board recorder and capturing a baked codec (like prores/dnx on a SD PIX, Atomos, or BM Video Assist), than it's better. Also an added advantage is that with Look Around enabled, you get the full 5k sensor read out (albeit at 1080p) via SDI or HDMI. Not only is that a bigger ~APSH/1.3x FOV, but the noise is less perceptible as well (since it's 5k>1080p instead of 4k>1080p).
 
You might be mistaken.

Don't get me wrong; RED, for whatever (dumb?) reason, didn't put RWG internally to DSMC1 MX cameras, but I have mine set to RC4/Log3G10 (and then a wonky/homebrew RG4>RWG-to-MedCon/VerySoft Roll-Off LUT) to a Ninja V that has LUT support. Is it ghetto? Yes. Should MX cameras have been updated with both RWG and not just Log3G10? Definitely Yes. But do MX camera support a Log3G10 gamma? Also Yes.

That's not even the wild part. What's crazy is when you put a mag in the MX camera that has footage on it that was captured by a Dragon camera (DSMC1 Dragon has RWG support, along with DC1 and DC2, none of which are selectable in MX cameras). It reads/displays the footage with the recorded colourspace/gamma! I know, right?

Oi! That's interesting! I haven't seen that before! I would be nice if RED was willing to implement IPP2 into the older cameras, not that it is a big issues anyway, but it would be nice. I know they have a brainfull keeping the new systems afloat, but it could be nice to treat that as a refresh. I would assume that there is a programmable work around for this?
 
Back
Top