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

Raw monitoring tells a different story?

JR Monteiro

Well-known member
Joined
Feb 24, 2012
Messages
87
Reaction score
0
Points
0
IMG_0078.JPG
IMG_0075.JPG
I have become extremely conscious of the noise in the picture of my Epic MX in even slightly underexposed areas of the frame. Clean blacks on an Epic seem to be an oxymoron. Cap the lens and find out for yourself. That being said however I noticed a strange anomaly on the touch screen monitor display. Maybe someone can explain it to me. (images attached) when I switch to RAW display the noise bar on the left side of the histogram drops way down and the purple area of the "Exposure Check" display vanish to almost nothing Even though I haven't changed any of the camera settings such as shutter angle, F stop or ISO. What gives? The camera records RAW no matter what I am looking at on my LCD display so do I trust the "Noise Bar" and "Exposure Check" levels when RAW monitoring is enabled or do I trust them when Normal Look is enabled? You can see from the screen display that I am not making this up. There should be no more noise in the image regardless what look I put on the image displayed on my monitor.
 
Last edited:
I was under the impression that the goalpost (left side noise bar) should *not* change when the metadata settings are played with (ISO, FLUT, Brightness, gamma, etc.)

Also your pictures didn't attach.
 
I was under the impression that the goalpost (left side noise bar) should *not* change when the metadata settings are played with (ISO, FLUT, Brightness, gamma, etc.)

Also your pictures didn't attach.

That was my understanding as well...The histogram and 'exposure check' are affected by metadata, but not goalposts and stoplights.
 
Your pictures are up and, yes, that is odd... I'm gonna go check mine (Scarlet-X running 5.2.41).

EDIT: Mine does the same. It's not as much as I was guessing by your description, but it definitely goes down in raw view and it shouldn't.
 
Last edited:
I'm on the latest version, not the one that came out yesterday and mine does this as well.
 
Your histo goes off of what color space you are in. So for rc3/rg4 your histo will work off of that lut. Where as when you switch to RAW you are basically monitoring what RLF looks like on a histo. I would imagine that if you were in rc3/rlf your histo would look very similar
 
I am one build back from the most recent.
 
Your histo goes off of what color space you are in. So for rc3/rg4 your histo will work off of that lut. Where as when you switch to RAW you are basically monitoring what RLF looks like on a histo. I would imagine that if you were in rc3/rlf your histo would look very similar

We're not talking about the histogram; we're talking about the (raw) goal posts (specifically the shadow one), which are based off the raw/sensor data (*not* the metadata). They shouldn't be changing.

In JR's pics, it goes from about half-way, down to about a quarter, which is odd. Also he's using raw exposure check (just purple for noise floor, green for 18%, and red for clipped highlight) , not video exposure, so it should also not change, yet there is a lot more purple in the RG4 image.
 
they do change though based on rlf or rg as far as ive always noticed. The stop lights though always monitor off raw. but i think the left side always changes depending on which gamma space you are in.
 
So let me try to explain what is going on and try to ease the confusion. First, let me tell you how the exposure overlay works.... We have a threshold for clipping and one for shadow and they're in linear light code values, referencing right back to the raw data. We calculate where those code values end up in the monitoring space and then tell that monitor to colour that range of code values purple or red.

Now lets look at what's happening in the log view and the red gamma view. In log the code values that represent shadows are raised and expanded. In the red gamma view the code values that represent shadows are curved towards black adding a pleasing contrast to the image. That means for the same threshold, we have vastly more precision to paint the image with the highlight colour in log than we do in a gamma mode, and it's all down to the fundamental difference between a visually pleasing gamma encoded image and a very flat log image.

Graeme
 
Yeah, but the gamma applied is non-destructive, whereas the log(raw?) image noise is "hardcoded" in there. So really doesn't that mean it's needlessly saying "noise floor" much earlier than necessary on the RG4 image? Also, I'm confused as to how that's a raw clip, if it changes... Like if the threshold is established using linear light code values, that shouldn't change regardless of the metadata gamma curve selected and displayed on the monitor (regardless of the added precision) since it is established/read *prior to* the curve being applied...

In other words, that explains the purple, but how does that factor into goalpost... OR are you saying that the "raw" view is actually linear+log = close to raw, but not exactly raw?

If that's the case, can we get goal posts (and stoplights) that are actually based off the linear light/sensor data and nothing else?
 
The noise floor indicator is basically saying - "be careful" or "be watchful" rather than anything absolute. It's for guidance. There's no absolute on the shadow end unlike at clip where it's all or nothing. The threshold doesn't change, but our ability to display it accurately does. We must display onto an already developed image, which means we loose precision depending on how that image is developed. Remember in camera it's a live real-time system. In software you're right that gamma curves don't effect the raw data and it's just metadata, but even in software when you make an image with a set of raw development settings, that image is made just like the image is made in the camera's processing that makes an image from the raw data. Once that image is made in camera, it's like there is no raw data alongside it, just the image flowing through the pipe towards the display. We can add overlays, but there's no concurrent raw data existing alongside the image. That's why precision effects the purple.

I'll have to ask Matt on the goalposts.

Graeme
 
Thanks Graeme!

Yeah, that makes a little more sense -- I always just assumed the display pipeline (gamma corrected, colour science applied, debayering) was kind of just an overlay on top of an "always referenceable and concurrently readable" raw data stream (which was set in stone). That said, "Debayered Raw Stream" is kind of an oxymoron.
 
I am sorry but this is getting a little too complicated for me and I am sure others who just want to know how to get an optimal exposure with as little noise as possible. If the exposure guides give me a different reading in Raw than they do in Red Gamma which one do I go by?
 
You have to look at both the redlogfilm and redgammas. The red gamma curves are pretty much in the ballpark of what final delevery typically is. The display tools give a great visual reference on what to expect with the highs and lows. I switch to RAW view to confirm what the sensor is capturing (Well close enough anyway) to know what I can dig in post if have to. It's too easy to do quick checks on all the tools to not use them.
 
The difference is negligible. That said, using the RG exposure check will be cleanest (since it seems to have a tendency to over-exaggerate noise because it is less accurate than the log/"raw" exposure check).

...AND also do what Bob suggests (I map the various views to my Sidehandle's A-through-D buttons and usually scroll between them at the top of a set-up, just to make sure there isn't anything unexpected).
 
Back
Top