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

I miss the pre-20 false colour

I have long been an evangelist for false color. I think it is most helpful when it provides a color coded mapping of Ansel Adam's Zone System. Due to the vagaries of human vision it is problematic to assign 10 colors that can all be differentiated easily in less than ideal monitoring conditions. Anyone with reasonable color vision should be able to easily see the 3 primaries and 3 secondaries distinctly which gives us 6 "bands" to work with.

False color (V in the B30 Multi toggle) has gone through at least 3 iterations, each with advantages and disadvantages. I suggested an adaptation of the old system in detail months ago that ganged some of the zones to make it easier to read; Zone 1 purple, 2 blue, 3 & 4 gray, 5 green, 6 - 8 gray, 9 yellow, 10 orange, clipped red. I believe it should represent the RAW range regardless of the RGB path. Here's why:

We have the RGB histogram (with the RAW goalposts that I love) and the monitor image itself to judge the FLUT™™™ted RGB domain. Does that need to be duplicated in a reference overlay? IMHO false color exists as a tool to make it easier to visualize the actual densities on the "digital negative" you are creating. This allows you to judge ratios and quickly see which "Zone" particular scene values are in. I use it as an engineering check. Maybe its just me.

On a related note I have been working with the MX sensor for a couple months now and the lower noise floor has changed how I select my ideal exposure. FWIW I set my ISO to 640 or 800 depending on scene contrast (800 for higher contrast to protect the top end) and then spin the iris while watching the RGB histogram. In the past I would ETTR, shoving the bulk of the "hills" up the scale until the clipping risk became too high. Now, I am more interested in spreading out the hills so I have more discrete code values (while still watching that I don't go too high or too low;-) One critical caveat to this approach is to be sure that if someone besides you is "developing the digital negative", ie color grading, that they are aware of the intended levels of particular elements in the scene.

Cheers - #19
 
On Build 30 / FLUT™ you should NOT be judging exposure on the Video level.

So why include a false color for video mode? Why suggest a certain zone be for caucasian skin tone? And so on. I'm with Paul on this. The video false color is causing people to overexpose.

If you're only to judge exposure off the raw, you're going to have everyone start rating the camera at 320, which isn't necessarily correct to due to the lowered noise floor, as the raw lut shows up close to 320 on the MX Cameras.

On page 52 of the manual, it clearly shows what DP's have been getting used to showing yellow, orange and red. Pg. 51 has the ire layout. But that's not how it's working on the cameras. It shows yellow, and that it's it. Checking the raw, it's still blown out.

It should be changed back to how it was. Red (the color, not the company) signifies danger, warning, etc. It's why it's used on every stop sign and police/ambulance/fire engine lights. Culturally that's what we're used to, and that's what we've become accustomed to with previous builds. Any indication possible that we're clipping, should be enforced. If a DP that has the image punched in, not magnified, can't see the goal posts because they simply want a larger image, then quickly check false color, may miss this. And already, a lot have.

Thanks.
 
B30 and False Color

B30 and False Color

So why include a false color for video mode? Why suggest a certain zone be for caucasian skin tone?

Because if you are recording a back up copy to HDCAM, or DDR, or analyzing the video output on a waveform monitor, then the values of the RAW data as translated into the RGB video domain do matter.

Same as if you are doing a telecine transfer -
 
Build 30

Build 30

If you're only to judge exposure off the raw, you're going to have everyone start rating the camera at 320, which isn't necessarily correct to due to the lowered noise floor, as the raw lut shows up close to 320 on the MX Cameras.

I will respectfully disagree with you, more likely that it would be ISO 800 if they were to pick one value.

Its also clear that you can have your Build 30 camera track a standard light meter across a wide ISO range.
 
B 30 False Color

B 30 False Color

Red (the color, not the company) signifies danger, warning, etc. It's why it's used on every stop sign and police/ambulance/fire engine lights. Culturally that's what we're used to, and that's what we've become accustomed to with previous builds. Any indication possible that we're clipping, should be enforced. If a DP that has the image punched in, not magnified, can't see the goal posts because they simply want a larger image, then quickly check false color, may miss this. And already, a lot have.

I agree, but if you are checking for false color, check the right one EXPOSURE not VIDEO.

If you believe that it should be reverted, then I ask you to do the following test.

- Set up a scene at ISO 500 and where the Exposure false color overlay shows some red.
- Now change the false color overlay to Video false color.
- Now keeping Video false color enabled change the ISO rating down to 100 and then back up to 1280.

Do you get the "exposure" feedback that you were expecting?
 
I will respectfully disagree with you, more likely that it would be ISO 800 if they were to pick one value.

Its also clear that you can have your Build 30 camera track a standard light meter across a wide ISO range.

The 800 asa image looks way brighter when in RedColor, whereas the 320 one is identical to the RAW view. Doesnt this mean that the actual rating of the sensor is 320?
 
The ideal would be to combine the two into a single overlay would it not? What I mean is you use the middle range false colours to indicate RGB IRE values, but have purple and red indicate RAW under-exposure and clipping respectively.

It may not be possible on the R1 due to processing limitations, but you might consider it for Epic.
 
The ideal would be to combine the two into a single overlay would it not? What I mean is you use the middle range false colours to indicate RGB IRE values, but have purple and red indicate RAW under-exposure and clipping respectively.

It may not be possible on the R1 due to processing limitations, but you might consider it for Epic.
Hi Nick,

I agree, but I'd even go so far to say simply have a false colour based on the RAW sensor data.

Paul
 
…I'd even go so far to say simply have a false colour based on the RAW sensor data

But what would false colour in the middle range mean for RAW? False colour (other than clipping and underexposure indication) shows the IRE values. Since these are dependent on the way the RAW is intended to be developed, they are only really relevant in RGB – except possibly at 320 ISO.
 
B30 and False Color

B30 and False Color

But what would false colour in the middle range mean for RAW?

That is the key point. False color can either be shown in true linear space (which our eyes don't understand) or developed via a Gamma, and that is controlled by the ISO rating.

BTW, this is a good discussion, its always good to hear alternative opinions and feedback from the field.
 
Last edited:
But what would false colour in the middle range mean for RAW? False colour (other than clipping and underexposure indication) shows the IRE values. Since these are dependent on the way the RAW is intended to be developed, they are only really relevant in RGB – except possibly at 320 ISO.
Hmm, ok. Well the way I imagine it working is that if you had a grey scale version made up of a combination of the RGB from each pixel, that grey scale would have a value for each pixel. I don't know how big the range of values that is for each pixel on the Red's sensor but say if it was 1 to 10,000 then you could assume for every 100 that was 1%.

You'd then have a false colour that goes by percentage of the RAW sensor, maybe 10% for each colour and have 10 colours in total. I don't think it would take long to build a relationship between those colours and how one likes to expose the sensor when looking at the footage in post.

It is 1.45am on a Friday (Well Saturday I should say) and I must confess to not being completely stable but the above does make sense in my head at the moment. I'll check again in the morning (When you'll probably all have torn my suggestion apart)!!!

Cheers
Paul
 
I love the Exposure Check mode in B30, I think it's probably the most helpful thing ever done for RED exposure. If I were to change anything about how False Color worked it would probably be nice to be able to have the option of turning on a 18% grey "color" that was based on the Video settings, but still have the Clipping and Crushing colors be based on RAW.

That seems like its the most in line with the idea that you can place your 18% grey wherever you want with FLUT, but that your "Ends" are very key also.

I could also see adding a user selectable "color" and range so that you could set your own range of the sensor that you most liked.
 
I love the Exposure Check mode in B30, I think it's probably the most helpful thing ever done for RED exposure. If I were to change anything about how False Color worked it would probably be nice to be able to have the option of turning on a 18% grey "color" that was based on the Video settings, but still have the Clipping and Crushing colors be based on RAW.

That seems like its the most in line with the idea that you can place your 18% grey wherever you want with FLUT™, but that your "Ends" are very key also.

I could also see adding a user selectable "color" and range so that you could set your own range of the sensor that you most liked.
I was thinking about this too. I've been finding that the E-check mode along with goalposts has been great as it tells me fairly quickly if I'm getting in trouble, but having the green 18% like we're used to that's based on video settings would be very cool to have on the same overlay if it's possible. If not, I will continue to use the E-check for watching my extremes, and the V-mode for checking the monitoring path and an interpretation of the signal. Combined with histogram, light meters, etc. we have quite a few tools for getting the exposure right.
 
Okay, so I've read through this thread and think I understand what's happened, but it still doesn't really help me when I am going to expose. To me, FC was one of the best tools I've ever used on a camera. I could always nail my exposure without a meter and I knew better what I was actually getting in my image.

To me, it makes no sense to really have the "video" mode on the camera if it's going to be like it is. I really need a FC mode that shows the full range of colors with skin tone and near over exposed/clipped, along with under exposed that I can tell what's clipped, what's not, and where I am on skin. To me, it makes sense to have a FC mode that displays those things in whatever mode you are in. So if you are at 320 in REDColor, it's showing what you would be getting with the colorspace and gamma applied. However, if you switch to RAW, it would be showing you what's happening in the RAW. Basically, I could set a button on my EVF/LCD to switch colorspaces and see what's happening in the RAW and when a colorspace is applied.

Now, with what's changed, I feel like I have far less information provided, and have to lean more on my meter, which I feel makes me work a little bit slower.

Maybe I am still not understanding it, but it seems to be a huge step backwards.

Matthew
 
So, let's all agree that what's best, is a FC that has both video non-clipping info(I would go for more than just a 18%, it's nice to know the scene's contrast, even in video levels) and RAW clipping ones. That's still handicapped if you're recording through HD-SDI or going for a simple transcode workflow without using redcine-x, but a better-or maybe faster- approach.
 
Back
Top