320-ISO 5000 K stuff

[Roberto Lequeux]

Hans, yea, but I would be setting exposure with the RGB histogram anyway, that I know for sure. However I can later with curves and some basic rotoscoping bring out different exposures so long as they all look to have acceptable levels of noise at the ISOs necessary... so the hood is probably still a valid term to use and I too think it sounds too cool to do away with completely... besides it could mean anything we want it to mean.

Is there a step in between 250 and 320? Just curious, I bet 250 is probably an excellent ISO to safeguard with a healthy little chunk of additional headroom for the highlights... especially if you are particularly annoyed at the way video handles them.

BTW, the histogram doesn't change with the ISO setting, does it?!?! Very important little detail I might have assumed incorrectly! Please clarify this.

 

[Shane Kelly]

I never thought about using filters to bring the high color temperatures (over 6500k) back to 5000k but that makes a lot of sense. I'll have to get an 81ef and try it out.
For the record, I shoot in 250asa, monitor in raw and expose to the right. This works for me and gives me beautiful quicktimes without any manipulation.

 

[Lauri Kettunen]

Here towards the end of your post, you are still talking about overexposing so long as you don't clip too much, correct? Simply getting the image nice and hot so as to take advantage of that last stop to get the most data, right?

Yes, precisely. Two advantages i) less noise, ii) more bits in use which is an advantage when applying filters in post.

What I don't understand is your proposal to mentain the 320 ASA in the metadata for maximal quality.

Hans, I noticed your earlier comment and if I've got it right, the nominal ISO value of the sensor depends somewhat on how it is specified. So, yes, see your point. However, when the raw view is employed, the ISO setting should not affect the histograms or "trafic lights" at all. So, in this light it can be whatever.

Not really - if coded and decoded properly, overexposing for lower noise works just the same as with linear data - there's plenty of precision for each f-stop.

Eki, this gets already beyond the horizon of this forum. But if you like, how familiar you are with linearity and linear operators? For instance, is it clear to you, what it means that an operator f: X -> Y preserves the structure of linearity, i.e., properties
i) f(x1+x2) = f(x1) + f(x2) and
ii) f(ax) = af(x), for all real numbers a
hold?

The reason to ask is that I believe this linearity is a crucial part of the raw work flow. In practice, think of the following. Shoot a 18% grey card and overexposure n stops to the right. If the system is linear, when you open the raw file in post and set n-stops of underexposure you end up with the same 18% grey image. What you gain by shooting to the right is less noise. But, if you apply a log-curve (i.e., a log map) then you won't result back in 18% gray. Moreover, the difference to the 18% gray will depend on how much you have overexposured.

Next, think of an ordinary image with all sorts of colors and tones. If you shoot to the right and apply a non-linear gamma map f between the sensor and storage, without information of f, formally you won't be able to return back to the image you started from.

However, perhaps you mean, if the non-linear map is included in the data file and the post processing system is programmed in an appropriate way, you are able to return to the image you started from. Yes, formally this is obvious. Just exploit the inverse map of f. But, it seems, applying a log-curve does not add the amount of information. And if you take a step from 12-bit system to 10-bits, you are effectively throwing away some data. So, why should one make the software system more complex? Compare, you can play the violin behind your back, but what's the point because it's just more difficult.

As I understand it, the whole point of raw view is that you take sides to the gamme curve/map only in post. Thus, the signal of the CMOS sensor is recorded "as is". Putting there anything between is a step away from this basic philosophy. I see the point that one can gain by such a move, but still, not without a cost.

But, still, I reserve the right to make mistakes in my reasoning.

 

[Hans von Sonntag]

Lauri,

what do you think is the RAWview in the RedOne? It's not raw obviously. It is a LUT transforming Red's RAW into RGB. The LUT is not linear - too bright. It's does not have a s-curve (at least not like Red's Rec709 LUT has). I guess it's logarithmic - to a certain extend at least.

What does it mean. Nothing really. Only perhaps that a mild logarithmic curve does map the RedOne's sensor nicely for our eyes - without any weighting. What wonder - don't our eyes look logarithmic.

I do unsterdstand that the simplicity of linearity carries a beauty in its self and is mathematically considerably easy. I also understand that maintaining the sensor's infomation throughout the pipeline is desirable. But I find in pratice that the the first two stops are burried in noise. I don't think that precise noise is the aim we are looking for. In this regard a 10 Bit log approach with an even milder compression for a given bitrate would pehaps increas fidelity.

Disclaimer: I'm no expert in coding.

Hans

 

[Hans von Sonntag]

BTW, the histogram doesn't change with the ISO setting, does it?!?! Very important little detail I might have assumed incorrectly! Please clarify this.

The histogram is affected by the ISO and Kelvin you set. This does not count for RAWview. RAWview is metadata agnostic.

If you use Rec709 or RedSpace and set ISO to say 1000 the picture becomes two stops brighter (compared to 250 ASA) and the histogram moves to the right.

Hans

 

[Eki Halkka]

However, perhaps you mean, if the non-linear map is included in the data file and the post processing system is programmed in an appropriate way, you are able to return to the image you started from. Yes, formally this is obvious. Just exploit the inverse map of f.

Exactly.

But, it seems, applying a log-curve does not add the amount of information. And if you take a step from 12-bit system to 10-bits, you are effectively throwing away some data. So, why should one make the software system more complex?

Less data.

 

[Lauri Kettunen]

what do you think is the RAWview in the RedOne? It's not raw obviously.

Yes, Graeme explained this some time ago in one of these threds. If remember correctly he said the histograms and the traffic lights still show the RAW signal.

But I find in pratice that the the first two stops are burried in noise ... In this regard a 10 Bit log approach with an even milder compression for a given bitrate would pehaps increas fidelity.

I'm not a specialist of sensor, but my guess is that the noise is mainly generated in the sensor. In principle the last bit of the binary number corresponds to the smallest amount of light that can be distincted from noise. The bit depth of the system follows from the dynamic range. As many bits are needed as the number of stops from black to white. Now, if such sensor data is recorded "as is", then whatever gamma map were employed within the camera, precisely the same should be doable also afterwards in post. And for a good reason this choice of the gamma curve is not fixed but is left to post. For this reson can't see why an in-camera gamma map reduced the amount of noise.

 

[Eki Halkka]

For this reson can't see why an in-camera gamma map reduced the amount of noise.

It doesn't, unless the sensor is read on a higher bit level than what gets saved.

 

[Hans von Sonntag]

And for a good reason this choice of the gamma curve is not fixed but is left to post. For this reson can't see why an in-camera gamma map reduced the amount of noise.

Lauri, I guess I did not make myself clear.

My idea was that since the first 2 stops are noisy a 10bit log "compression" would not harm in this area of bits. Precise noise does not help the picture quality.
By using a 10 bit log approach you will have a lower bit-rate. Now, you can use a milder compression than in a 12 bit linear approach for a given bitrate. The picture in the whole would benefit.

Again, I'm not an IT-tech. And yes, it would not reduce noise but increase fidelity, probably, perhaps....

Hans

 

[Lauri Kettunen]

My idea was that since the first 2 stops are noisy a 10bit log "compression" would not harm in this area of bits. Precise noise does not help the picture quality.
By using a 10 bit log approach you will have a lower bit-rate. Now, you can use a milder compression than in a 12 bit linear approach for a given bitrate. The picture in the whole would benefit.

Hans, ok I see your point now. Since this issue goes already to a rather detailed level better to leave the answer to Graeme or someone else who knows the Red One system in depth. Personally I'm convinced that only the best is good enough for Jim. Thus feel also confident that Red has taken whatever it takes to maximize the image quality.

 

[Christian Tanner]

the asa setting DOES affect the histogram?! now I'M confused...

if that's true, how is it possible to really know what will be recorded on camera? if - for example - i expose a scene with the asa set to 320 the histogram will tell me to expose, let's say for a t-stopf of 2.8, for my highlights to be save. now i change my asa setting to 160. if that histogramm is affected by the asa setting it will tell me that this very same scene should be exposed at 2 - and that way overexposing my highlights beyond saving. right?

and since i'm confused already - here's another one:
just to clarify - the red one isn't able to amplify gain right? if that's true though - what is the noise i'm seeing when i'm pushing the iso to a higher speed?

many thanx for the help in advance!
tanner

 

[Stephen Williams]

the red one isn't able to amplify gain right? if that's true though - what is the noise i'm seeing when i'm pushing the iso to a higher speed?

many thanx for the help in advance!
tanner

Hi,

You are seeing the noise floor, the image is just boosted so becomes more noisy.

Stephen

 

[Hans von Sonntag]

the asa setting DOES affect the histogram?! now I'M confused...

Hi Christian your are right with your assumptions.

I've never been a great friend of Red's metadata/ASA/Kelvin policy. They developed this to establish a pseudo WSIWYG workflow. When people started complaining that Red's Rec709 looks a bit dull and dark they desigend RedSpace to bring vibrant colours to the people.

The whole concept of ASA/Kelvin/WB etc. comes from the DSLR world. Other vedors of motion picture RAW cameras, Vision Research or Arri for instance, don't have that.

Fortunately they implemented RAWview which is, as mentioned above, ASA and Kelvin agnostic. In RAWview the histogram is showing what the sensor "feels".

For evaluation and exposure RAWview is the only meaningfull setup. All other LUTs (Rec709, RedSpace) and the possibility to tweak ASAs and Kelvins are purely metadata and for the client's monitor. Using them for exposure can be surprising.

If you are familiar with those LUTs you can establish a kind of WYSIWYG workflow utilising the Ref.MOVs the camera creates for FCP. Some experienced user on this board go this route, I'm not. I think of the RedOne as a digital film camera with a stock that has 250-500 ASA at 5.000K.

If you want to use one of Red's programs to develope your footage you must be aware that they rely on your metadata. Even you shoot with RAWview you have to set ASA and Kelvin and later in RA or RC decide for one of the given LUTs (Rec709, RedLog, RedSpace - RedLog is best for 10Bit finishing). I found that 250 ASA won't cut off higlights in RA/RC hence I set the camera to 250 ASA. You can rate the sensor differently though. Complicated. Sorry.

BTW, regarding noise Stephen is right, of course.


Hans

 

[Christian Tanner]

thanx for that stephen and hans.

good enough for me then - nothing a weekend of testing and fiddling can't sort out it seems...

tanner