Welcome to our community

Be a part of something great, join today!

Log in
  • 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 :)

Determining ISO...

Cardmaverick said:
I've been thinking some more about this....

Like I mentioned earlier about applying LUTs in post and what not, I have a feeling that the big missing piece with regard to this whole output monitoring issue is this:

User definable viewing LUTs

Bingo! Thats it. I bet if you could load a linear LUT into the camera for viewing, you would be seeing the "real" picture with regard to how things are really being recorded. This all makes sense now. If you are shooting for a certain LUT that will be applied in post, it makes sense to measure your data after the LUT has been applied, but still be able to monitor the RAW data in its natural pre-processed state.
Click to expand...

YES!

That's what I'm talking about.

I think you are right Chris...that there is some sort of LUT applied to the 720 output. I would love to be able to monitor the RAW data via a waveform...

...just for the purposes of testing.

Dylan Macleod, CSC
Cinematographer
Toronto, Canada
www.dylanmacleod.com
 
You can't really monitor the levels of a live RAW signal -- the whole process of converting it live to 720P 8-bit 4:2:2 in REC 709 color space for on-set monitoring means that that's the only live "video" signal to monitor on a waveform.

I know that Geoff Boyle made a similar comment, that he wished he could see the "RAW" image on set, but what he really meant was that he wished he could see a live 10-bit LOG conversion, like what a Viper or Genesis outputs to tape, the idea being that at least a LOG signal would contain all the luminence values in an easy-to-see manner, though the image itself would look "wrong" on a monitor without a LUT.
 
David Mullen ASC said:
You can't really monitor the levels of a live RAW signal -- the whole process of converting it live to 720P 8-bit 4:2:2 in REC 709 color space for on-set monitoring means that that's the only live "video" signal to monitor on a waveform.

I know that Geoff Boyle made a similar comment, that he wished he could see the "RAW" image on set, but what he really meant was that he wished he could see a live 10-bit LOG conversion, like what a Viper or Genesis outputs to tape, the idea being that at least a LOG signal would contain all the luminence values in an easy-to-see manner, though the image itself would look "wrong" on a monitor without a LUT.
Click to expand...

Thanks for the clarification David. I am now getting my head firmly wrapped around this concept.

Do you think it is possible for RED change this output to give us something greater than the 8 bit 4:2:2?

Guess I could ask them...

Dylan Macleod, CSC
Cinematographer
Toronto, Canada
www.dylanmacleod.com
 
I'm a little confused as to why you want to see a LOG image rather than a REC709 one. I thought the point of LOG was to fit a larger amount of information in the 10 bit container. What does a LOG image give you in terms of placing exposure that REC709 doesn't? I could see the point in have a 10bit LOG image being shown on a 16bit monitor with a LUT. I get the feeling I am missing something.
 
Irri said:
I'm a little confused as to why you want to see a LOG image rather than a REC709 one. I thought the point of LOG was to fit a larger amount of information in the 10 bit container. What does a LOG image give you in terms of placing exposure that REC709 doesn't? I could see the point in have a 10bit LOG image being shown on a 16bit monitor with a LUT. I get the feeling I am missing something.
Click to expand...

I think it is me that is probably missing something. :huh:

Quick re-cap on my original post.

I am testing a RED and want to be able to get an "accurate" live feed.

The test I did last month showed 109% (ish) white level from the top end of the gray scale in the "live" feed (720 output) to a waveform. When I viewed this in REDCINE, that 109% sat around "middle gray" on the histogram.

For the prupose of testing, I think it would be useful to see as close to the "full" information that the sensor is recording as possible.

Dylan Macleod, CSC
Cinematographer
Toronto, Canada
www.dylanmacleod.com
 
Ah, I think I get what you mean. I didn't realise you were talking about the waveform on a monitor rather than the image itself.
 
Irri said:
I'm a little confused as to why you want to see a LOG image rather than a REC709 one. I thought the point of LOG was to fit a larger amount of information in the 10 bit container. What does a LOG image give you in terms of placing exposure that REC709 doesn't? I could see the point in have a 10bit LOG image being shown on a 16bit monitor with a LUT. I get the feeling I am missing something.
Click to expand...

Rec 709 would make more sense here. In actuality, the curve applied (whether, log, 709 gamma, etc.) should be the inverse of the transfer function in the monitor so that the output of the monitor is linear luminosity. Many monitors would be able to undo the 709 gamma, but for Log type, one may have to program the inverse log (i.e., an exponential) values via a LUT, as David Mullen mentioned, and that in case if the monitor lets your program LUTs.

One more point about 10 bit log values. Typical video imaging systems tend to operate where the brightest object is about 90-100 times more luminous than the darkest black. More advanced (film-type) imaging systems aim for the brightest object to be 1000 times brighter. Assuming the 1% rule of human sensitivity threshold, about 463 indices would be required for video systems, which require 9 bits as you can store upto 512 indices in 9 bits. However, typically 8 bits are used, hence, you see banding -- more noticeably in the darker (bluish) tones. For film type systems with a 1000 range about 695 indices would be required, which would require 10 bits. However, instead of using 695 indices, the film imaging systems use all 1024 indices available via 10 bits numbers. Hence, a typical video imaging representation in 8 bits is undersampled, and a film imaging system in 10 bits is over sampled.
 
Thanks Joofa.

Reading that kept me up a little later than I had planned (early shoot tomorrow), but very informative.
 
Joofa, I don't believe that "Typical video imaging systems tend to operate where the brightest object is about 90-100 times more luminous than the darkest black." is correct.

Graeme
 
As I mentioned in the "bits" thread, the range is probably 1:600, but with an aggressive knee to bring the 100 to 500 range into the top 10% or so of the recorded range.

Graeme
 
Joofa, I'd be curious as to where your initial figure came from?

I also believe that aggressive knees contribute to the "video look". I don't have proof of that though....

Graeme
 
Graeme Nattress said:
Joofa, I'd be curious as to where your initial figure came from?

I also believe that aggressive knees contribute to the "video look". I don't have proof of that though....

Graeme
Click to expand...

From the top of my head I would think I read that in Steve Wright's book. But I could be wrong. I just have to go home and double check with my books. I am thinking about your thoughts on the "video look". There is certainly food for thought here and I am pondering if that really contributes to that look.
 
My two cents, the video look to me is: interlace, 4:3, knee, loss of color in the knee and detail circuitry. Edit: and lots of depth of field!

I will probably think of more.
 
richcam1 said:
My two cents, the video look to me is: interlace, 4:3, knee, loss of color in the knee and detail circuitry.

I will probably think of more.
Click to expand...

I might add excessively deep focus with 1/3" sensor cameras -- though deep focus and 4x3 could also describe "Citizen Kane"!

I'd also add excessive clipping. Motion smearing from turning off the shutter in 24P.
 
for me, it is deep, deep focus and lack of black.
Aloha
-A
 
You guys are all going to have to redo your tests after we release Build 15.

Jim
 
You must log in or register to reply here.
Back
Top