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

Post B16 comments here...

RAW vs. REDSpace

RAW vs. REDSpace

Looking through EVF and LCD.. I go to RAW view and set exposure. Everything is fine, but if I move to REDSpace then the Green and Red channels are blown on the "stoplight".

I would think that the RAW output would be the one to follow.. Am I correct?

Jay
 
Looking through EVF and LCD.. I go to RAW view and set exposure. Everything is fine, but if I move to REDSpace then the Green and Red channels are blown on the "stoplight".

I would think that the RAW output would be the one to follow.. Am I correct?

Jay

Jay,

This is a really good question. We have struggled with this one internally and can adjust as we go down the road. Currently the histogram is tied to REDspace. WYSIWYG. That means there is a bit of highlight protection built in. If you view REDspace and see the RAW histogram, there is an apparent disconnect between the two which is a bit disconcerting. We feel like this is the best compromise (for now) but we are open to comments. We can also add (assuming there is a large group that want it) a new space/histogram combo in the future.

Jim
 
Thanks Jim,

At this point, my lack of experience on the new build would keep me from offering a viewpoint.

But first let me paraphrase you to make sure I got this:

You are saying that even if we select RAW view, the Histogram (In my case the RGB Histotram) is still showing REDSpace and not RAW.

This assumption is based on the following:
"Currently the histogram is tied to REDspace"

But you also said:
If you view REDspace and see the RAW histogram, there is an apparent disconnect between the two which is a bit disconcerting.

So these two comments are confusing me a little ... Can you clarify for those of us that may not be operating on all thrusters? :)

(Ok just me)

Jay
 
I'll let Stuart weigh in on this topic... he is much more eloquent than I.

Jim
 
If you goto VIEW RAW the histogram is different then the histogram that is displayed when you are viewing REDSPACE ( or REC 709 for that matter). The differences increase when you start to deviate from the 320-500 asa range. View Raw will give you close to the native range of the sensor, and you will notice that when you change ISO when you are in VIEW RAW nothing visually changes on your monitor... histograms nor actual luminance of the image. VIEW RAW is basically bypassing the metadata flags and changes you are making in the camera.

One piece of advice I can to help with the confusion, and its what I do here, is to take the camera and set it up right beside the system you use to process R3D files.

Point the camera at something with a nice range of contrast ( a bit of blow out, something just under blow out, and dark dark dark shadows) , take a shot and leave the camera on. Open the files in Red Alert, and compare what is going with the histograms etc.

Its much easier to put the connection together when you can directly compare what you see on your camera, to what you see in Red Alert and final output, and it will help build a little confidence (hopefully)
 
Just installed 16.
I can't figure out how to adjust the evf brightness now.
To see everything on the chipchart on the evf I have to put the dark detail at .2%, which also makes the evf look a lot more like the image on the lcd. .2% was not the default.
 
I would like to assign one of the user buttons to 'pop' in and out of RAWspace to check, at an instant, what is actually hitting the sensor and make sure that clipping isn't occurring in areas that detail should be kept.

Like Mark said, this is important if you're using really contrasty 'looks' in camera, etc...
 
How does build 16 look in 2k and 3k recording modes now with noise improvements? Something to test for... Can we shoot higher framerates now with less penalty?
 
I wish I knew what to say here.

For now I will simply say, I think having this choice is wonderful. It will take time to find out the best way to run it.

FOR RIGHT NOW... I am inclined to stay on RAW unless I find is nessesary to come off ASA 320.

But that may change

Jay
 
Jim and Jarred,

Don't you think it's pretty cool how you can release this thing and suddenly hundreds of people are out there testing the crap out of it and providing feedback in less than 6 hours!?!?

I love the realtime element of all this.. I think it's fasinating.. I've loaded B16, but I'm just sitting here reading before I play with it.. I'm learning 5x faster just reading what 200 people are al experiencing at the same time than me by myself.

This is so cool

Jay

I completely agree with everything you've said. I don't even own a camera, nor am I a DP. However, I follow the boards religiously because I can shoot, it's interesting to me, I'm a nerd, and above all: I learn so damn much just reading the threads. If I needed to pick up a camera in the next few minutes to shoot something, I could do it w/out hesitation, and feel as though I have a solid understanding of its pros, "limitations," and workarounds.
 
How does build 16 look in 2k and 3k recording modes now with noise improvements? Something to test for... Can we shoot higher framerates now with less penalty?

There are several major improvements in Build 16 (hence "monumental"). The noise is less and better looking. The compression engine has been completely re-worked so you will see a lot less compression artifacts and a lot more information in highly detailed scenes. This translates across all resolutions and frame rates.

Jim
 
Just got back from shooting an interview with Build 16. I have not brought the clips into post yet, but initial observations:

During recording, image looked very clean, absolutely striking especially in the viewfinder. Upon playback I was seeing some banding. Did not see this at all during live preview. I need to explore this to see what it could be.

Focusing with the edge highlight seems to have improved quite a bit. I was seeing it a lot better now. It popped while looking through the viewfinder especially.

I do notice some weird color flickering in the viewfinder occasionally, especially when moving forward and back from it. Probably something that has been discussed and I missed it in the past. But otherwise, so far I'm really loving the VF.

Is there a way to have the low battery warning come on sooner? I was running two cameras, and while checking something on the other camera, the battery had dropped low, so I stopped recording and tried to power down but the file was still posting and the camera shutdown during that process. Did I damage the file? Usually I would be on top of these things and never let the battery get down that low, but given the circumstance, I missed it this time.

I'm sure I'll have more notes. I'm a bit fried right now.
 
I'd definitely like to see an option to have histograms, traffic lights and particularly false color exposure mode based on raw, even when monitoring in REDSpace. These functions are most useful, in my opinion, when they provide objective indications of exposure.

Jim, you say it's a bit disconcerting when the meters don't reflect the image being displayed... but that's sort of the point, isn't it? You should be able to see at a glance how much of the nice looking image you see is a result of your exposure actually being correct, and how much is the camera pushing things around in the image processing pipeline.
 
REDspace v's RAW

REDspace v's RAW

Looking through EVF and LCD.. I go to RAW view and set exposure. Everything is fine, but if I move to REDSpace then the Green and Red channels are blown on the "stoplight". I would think that the RAW output would be the one to follow.. Am I correct?

Great question, but in my view as the camera exists in an RGB visual infrastructure, no.

Its best to monitor the camera using REDspace, paying attention to the visual look of the image in your monitors, backed up by the histogram and traffic lights. Note that all of these work in RGB color space - REDspace in this example, but it could also be REC709 - and especially when working in REDspace they will obviously track each other i.e what looks blown out visually is confirmed by the histogram and traffic lights.

Is this the same as what the sensor is seeing? No.

If you want to know what the sensor is seeing select view RAW. If you want to expose your camera using view RAW go right ahead, but recognize that if you expose to the right when in view RAW, when you bring the recorded data into post production your material may look blown out because a standard RAW to REC 709 or REDspace conversion adds some amount of gain to the signal.

Now you CAN use curves to avoid that, but this is more time to spend than is necessary than if you shoot the camera in REDspace directly.

So bottom line - why do we have both views? REDspace gives you the immediate WYSIWIG view that you will see in post. RAW is a reality check to see where the sensor really sits. Sometimes its useful to know when working in REDspace that when the traffic lights are blinking on, you can flip over to view RAW to see if there is headroom in the RAW recording that you can exploit in post to correct for the RGB domain visual clipping.
 
Great question, but in my view as the camera exists in an RGB visual infrastructure, no.

Its best to monitor the camera using REDspace, paying attention to the visual look of the image in your monitors, backed up by the histogram and traffic lights. Note that all of these work in RGB color space - REDspace in this example, but it could also be REC709 - and especially when working in REDspace they will obviously track each other i.e what looks blown out visually is confirmed by the histogram and traffic lights.

Is this the same as what the sensor is seeing? No.

If you want to know what the sensor is seeing select view RAW. If you want to expose your camera using view RAW go right ahead, but recognize that if you expose to the right when in view RAW, when you bring the recorded data into post production your material may look blown out because a standard RAW to REC 709 or REDspace conversion adds some amount of gain to the signal.

Now you CAN use curves to avoid that, but this is more time to spend than is necessary than if you shoot the camera in REDspace directly.

So bottom line - why do we have both views? REDspace gives you the immediate WYSIWIG view that you will see in post. RAW is a reality check to see where the sensor really sits. Sometimes its useful to know when working in REDspace that when the traffic lights are blinking on, you can flip over to view RAW to see if there is headroom in the RAW recording that you can exploit in post to correct for the RGB domain visual clipping.

Ok.. this helps a lot.. Thanks!

Good call sending up Stuart, Jim.

:)
Jay
 
Jay,
That means there is a bit of highlight protection built in.

Jim

Jim,

What is the highlight protection (in stops) that you have built in? I find that stuff that is metered and then exposed according to the meter seems under by 2/3rds to 1 and 1/4 stops.

Is this the "highlight protection" you are talking about?

To me, it seems that you need to expose one way for "straight to video" (quicktimes that don't need much "work" when opened in FCP) than if you are going to a filmout. Testing is the best policy but what are your thoughts on this?

Is that a correct assumption?

Thanks,

David
 
I'd like to second what Chris Kenny said: see RedSpace on monitors, but have histogram, false color and traffic lights relate to sensor data. For me, they are measuring instruments telling me precisely what hits the sensor.

LCD and monitoring should look nice for those standing around too.

Just my two cents, but maybe I'm thinking too technical ?

Uli
 
16!!!

16!!!

Just shot some 4k 16x9 footage, dropped H proxys into FCP, rendered it, looks
delicioso!!!!! Much better color and contrast....now we're getting somewhere.

Thanks!
 
So if I understand the request that is surfacing, people want to be able to not only select the kind of histogram they are seeing, but the colorspace it's based off of. And they want that to be independant of the monitor's color space.

I have a feeling this will ask a lot of the camera's computing power.


Jay
 
Back
Top