Welcome to our community

Be a part of something great, join today!

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

Mysterium-X dynamic range...

Noah Yuan-Vogel said:
even though when viewing a raw histogram on RED ONE stopping down one stop does move the value of a peak from what appears to be 100% down to 50%
Click to expand...

Jeff Kilgroe said:
Of course it does, you're cutting your light in half if you move down a full stop.
Click to expand...

Sure, if you went down a stop in Red Alert's linear light view the histogram would be halved, but doesn't the camera raw view have gamma applied?
 
Looks like I type way to slow and everyone beat me to it :)

Jeff, where have you seen information about the macbook pro having a 8bit LCD panel? I thought I saw a review that stated even the new LED backlit displays are still 6bit, I'd be interested to know if that is truly the case.
 
ronx said:
13 stops requires 8192 values if stored in a linear form,
Click to expand...

No it doesn't. A step chart from black to white with 13 discrete steps can be accurately represented in 4-bit grayscale (16 values), if you light it properly.
 
Irri said:
Sure, if you went down a stop in Red Alert's linear light view the histogram would be halved, but doesn't the camera raw view have gamma applied?
Click to expand...

I think REDCODE RAW is gamma encoded but that is transparent to the user and the raw histogram still displays the linear response of the sensor.
 
Noah Yuan-Vogel said:
I think REDCODE RAW is gamma encoded but that is transparent to the user and the raw histogram still displays the linear response of the sensor.
Click to expand...

It didn't look very linear, last time I looked.
 
Irri said:
It didn't look very linear, last time I looked.
Click to expand...

I could be wrong as I dont have a RED ONE in front of me to double check, but i recall trying this (with probably build 20?) and it being the case. And from what i recall, the raw histogram sure does seem to put too much information wayyy to the left for it not to be linear.
 
Noah Yuan-Vogel said:
Yes it can be recorded into a 4bit greyscale image, but it cannot be captured by a 4bit ADC.
Click to expand...

Why not? If you have a camera that only captures in 4-bit grayscale (an admittedly crappy camera, to be sure), why wouldn't it be able to take a nice picture of said chart?

Actually, I'm wrong -- it would quantize (or dither) most of the grays. But if it was a 16-step chart, I don't see why it wouldn't look right.
 
joshua csehak said:
No it doesn't. A step chart from black to white with 13 discrete steps can be accurately represented in 4-bit grayscale (16 values), if you light it properly.
Click to expand...

Printed step charts of any kind only cover 5-6 stops of DR, limited by the paper white and the ink black. More steps is just dividing the values into finer gradations, not changing DR.
 
joshua csehak said:
Why not? If you have a camera that only captures in 4-bit grayscale (an admittedly crappy camera, to be sure), why wouldn't it be able to take a nice picture of said chart?

Actually, I'm wrong -- it would quantize (or dither) most of the grays. But if it was a 16-step chart, I don't see why it wouldn't look right.
Click to expand...

Are you talking about arbitrary steps or are you talking about f-stops? I will assume f-stops since your original response was to ronx who was talking about f-stops.

13 stops cannot be captured by a sensor that responds to light linearly, when a 4bit ADC is used because a 4bit (16 possible values) ADC converts the darkest f-stop range worth of detail to 1-2, 2nd to 2-4, 3rd 4-8 and 4th to 8-16. Any further shadow latitude would all get averaged out to either a 1 or 2 value. However, you could use a 14bit ADC and use an LUT or other such processing to store that in a 4bit encoded image.

If you are talking about steps that have nothing to do with dynamic range, yes i suppose you could find a way to fit 13 steps into up to 16 values if you encoded or lit it correctly. But then I dont know why you originally responded to ronx's statement about capturing 13 STOPS of contrast.
 
Noah Yuan-Vogel said:
Jeff, where have you seen information about the macbook pro having a 8bit LCD panel? I thought I saw a review that stated even the new LED backlit displays are still 6bit, I'd be interested to know if that is truly the case.
Click to expand...

I've been told by a couple Apple techs that they are 8bit now. But now I guess I'd better try to figure out just which model they're using. Typically it's an LG panel, sometimes a Samsung. Both make a 17" 1920x1080 LED LCD panel that is 8bit, but their 1920x1200 panels are still listed as 6bit. I'll try to identify the panel when I get back to my 17" MBP.
 
David Rasberry said:
Printed step charts of any kind only cover 5-6 stops of DR, limited by the paper white and the ink black. More steps is just dividing the values into finer gradations, not changing DR.
Click to expand...

I dunno, I just metered a black piece of paper on a white piece with the light shining directly on it and got 8. I bet you could push it more with better lighting. But that's not the point. Pretend I said "4-step chart," "4 stops," and "2-bit grayscale sensor."

Noah Yuan-Vogel said:
Are you talking about arbitrary steps or are you talking about f-stops? I will assume f-stops since your original response was to ronx who was talking about f-stops.

13 stops cannot be captured by a sensor that responds to light linearly, when a 4bit ADC is used because a 4bit (16 possible values) ADC converts the darkest f-stop range worth of detail to 1-2, 2nd to 2-4, 3rd 4-8 and 4th to 8-16. Any further shadow latitude would all get averaged out to either a 1 or 2 value. However, you could use a 14bit ADC and use an LUT or other such processing to store that in a 4bit encoded image.

If you are talking about steps that have nothing to do with dynamic range, yes i suppose you could find a way to fit 13 steps into up to 16 values if you encoded or lit it correctly. But then I dont know why you originally responded to ronx's statement about capturing 13 STOPS of contrast.
Click to expand...

No, I meant 13 stops. I'll definitely allow that I could be wrong here (maybe one of the guys who works on the sensor can chime in? I just try to take pretty pictures), but the way I understand it, a sensor contains a whole bunch of sensor elements ("sensels"). There's some kind of filter or prism that separates light into red, green, and blue before it gets there, but we won't get into that, cause I don't really understand that bit :) But each sensel holds a charge, depending on how much light strikes it. The ADC converts the amount of that charge to a digital number. If it's a 1-bit ADC, it can only convert it to 1 or 0. If it's an 8-bit ADC, it can convert it into 256 values (00000000 through 11111111 in binary), and with an 8-bit number representing each red, green, and blue value, you now have a 24-bit number that represents a color value for 1 pixel. Do that some 9 million times and you have 1 frame of a Red One file.

So the way I understand it, it's the amount of photons each sensel can hold that determines dynamic range, not bit depth. I really don't think each sensel is only 1-bit and assigned to a different luminance range, but again, I could be wrong. I'm sure someone will let me know if I am ;)
 
joshua csehak said:
No, I meant 13 stops. I'll definitely allow that I could be wrong here (maybe one of the guys who works on the sensor can chime in? I just try to take pretty pictures), but the way I understand it, a sensor contains a whole bunch of sensor elements ("sensels"). There's some kind of filter or prism that separates light into red, green, and blue before it gets there, but we won't get into that, cause I don't really understand that bit :) But each sensel holds a charge, depending on how much light strikes it. The ADC converts the amount of that charge to a digital number. If it's a 1-bit ADC, it can only convert it to 1 or 0. If it's an 8-bit ADC, it can convert it into 256 values (00000000 through 11111111 in binary), and with an 8-bit number representing each red, green, and blue value, you now have a 24-bit number that represents a color value for 1 pixel. Do that some 9 million times and you have 1 frame of a Red One file.
Click to expand...

For a single sensor system like RED, yes the bayer filter puts a R, G, or B color filter over each sensel or photosite, and no there is no combining of red green or blue values for each pixel, they are read separately and no color values are combined together into single pixel RGB values until debayering which happens when you play your R3D.

joshua csehak said:
So the way I understand it, it's the amount of photons each sensel can hold that determines dynamic range, not bit depth. I really don't think each sensel is only 1-bit and assigned to a different luminance range, but again, I could be wrong. I'm sure someone will let me know if I am ;)
Click to expand...

I understand it similarly, yes the very first component that determines the maximum possible theoretical dynamic range of the imaging system is the sensor and its characteristics (quantum efficiency, noise). From there the signal can only get degraded, through conversion into the digital realm, processing, compression, quantization etc. The ADC component which converts photosite well voltages to digitally represented values reads linearly as does the sensor so the precision with which it represents the signal is particularly important to the darker (ones receiving far fewer photons than are required to result in a full well). On the other hand, no matter how precise the ADC is, the sensor's clip point will always be much better represented.

Here is a simple graphical representation of what would happen in an extreme situation of using a 4bit ADC with a sensor that has at least 6stops of latitude. Each bar represents a stop of light.

clip point_________________________________black
16___________________8__________4_____2__1_.5?_.25? <digital representation
|____________________|__________|_____|___|__|_|
1000fc______________500fc______250fc__125_64_32_16 <real world brightness

keep in mind 4bit allows 16 possible values (1-16 or 0-15), if you prefer to represent black as 0, just subtract 1 from each of the digital representation values.

As you can see, there are only enough values to read 4 stops of contrast. The lower two stops of detail are thrown away as they are not read with enough precision to be represented in the digital realm. each extra bit you add to the precision of the ADC would let you see one stop further into your shadow detail instead of throwing it out by averaging it all out to black.
 
But there are values in between, too:

clip point______________________________________black
16_15_14_13_12_11_10_09_08_07_06_05_04_03_02_01_ <digital representation
|________________________|___________|______|__|
1000fc_________________500fc_______250fc___125_64_ <real world brightness

And wouldn't you want to assign those values based on a curve? You wouldn't want half your available information going to describing your uppermost stop, right? So you'd digitize it like this, so each stop has 4 steps:

16______________________12__________8______4__1_ <digital representation
|________________________|___________|______|__|
1000fc_________________500fc_______250fc___125_64_ <real world brightness

Now, what if your sensor can measure down to 16fc? Couldn't you just digitize it like this?

16__________________13_______11______8____6__3_1_ <digital representation
|____________________|________|_______|____|__|_|
1000fc______________500fc____250fc___125__64_32_16_ <real world brightness

And now you've got 6 stops of dynamic range represented with 4 bits. Except, the problem with doing that is now you only have 2/3 values per stop, instead of 4. So you'll get some banding (or rather, more banding).

This is fun to think about.
 
My understanding is that, no, you cannot, because the linear response is read linearly with as many bits of precision as the ADC allows, but then you can process/encode/record that linear data with a curve as you suggest with whatever precision you want.
 
Noah Yuan-Vogel said:
Jeff, where have you seen information about the macbook pro having a 8bit LCD panel? I thought I saw a review that stated even the new LED backlit displays are still 6bit, I'd be interested to know if that is truly the case.
Click to expand...

Finally had a chance to query the Macbook Pro. Mine has the LG LP171WU6-TLB1. Unfortunately, I can't seem to round up actual specs for it as it's not listed on the LG-Philips LCD Panel site. It seems there is also an LP171WU6-TLA1, which is the glossy version (it seems the 'B1 denotes the matte version).

LG does have a LP181WU6-TLA1, which is an LED backlit 18" 1920x1080 panel and it is 8bit. HP is using and so are a few others in notebooks with 18" 16:9 screens. No way to tell if the panel in this MBP is for sure 6bit or 8bit until I can find a spec sheet. So there ya go.. :leaving:
 
Last edited:
Jeff Kilgroe said:
Finally had a chance to query the Macbook Pro. Mine has the LG LP171WU6-TLB1. Unfortunately, I can't seem to round up actual specs for it as it's not listed on the LG-Philips LCD Panel site. It seems there is also an LP171WU6-TLA1, which is the glossy version (it seems the 'B1 denotes the matte version).

LG does have a LP181WU6-TLA1, which is an LED backlit 18" 1920x1080 panel and it is 8bit. HP is using and so are a few others in notebooks with 18" 16:9 screens. No way to tell if the panel in this MBP is for sure 6bit or 8bit until I can find a spec sheet. So there ya go.. :leaving:
Click to expand...

Jeff, that info is shown in System Profiler. My MacBook Pro says "Pixel Depth: 32-Bit Color (ARGB8888)"
 
You must log in or register to reply here.
Back
Top