About pixel count

[illia]

I've read many times that it's better to expose the red one to the right of the histogram (as the digital still cameras). This has to do with the noise floor of the signal and with the numer of levels of the values of the pixel, according to the brightness of the scene.
In a web site I found that (where niveles means levels):
0EV: 2048 niveles, 2048..4095
-1EV: 1024 niveles, 1024..2047
-2EV: 512 niveles, 512..1023
-3EV: 256 niveles, 256..511
-4EV: 128 niveles, 128..255
-5EV: 64 niveles, 64..127
-6EV: 32 niveles, 32..63
-7EV: 16 niveles, 16..31
-8EV: 8 niveles, 8..15
-9EV: 4 niveles, 4..7
-10EV: 2 niveles, 2..3
-11EV: 1 nivel, 1


According to this, the dark areas of the scene will have less possible values than the bright areas... but, the sensor has a linear response to the light... so, what is this all about?

 

[Gunleik Groven]

Well, as you double the levels (stops) you double the precission.

A bit simplified, you could say that half your precission (2048 levels) is between white and burn-out (between but 11 and 12 in the linear mapping on the M sensor).

This is one of the reasons we want higher bit-depth, so that we can "throw away" more in the bottom and map lowlight to higher-precission without lolsing significant precission in the highlights.

I am in no way an engineer, so this is a layman explanation, but if you take a grey-cards and look at the levels and how flexible each step is with this in mind, you probably will see how this works out for pratctical use....

 

[illia]

Dark areas and bright ones

Dark areas and bright ones

Yeah, I understand the conclusions that come out of this data, the problem is that I don't get the reason there are so many pixel values to that last stop brightness and so few in the dark areas... I mean, that doesn't appear to be an issue that comes out of the CMOS characteristics, as it's a linear device.
Is that has something to do with the A/D conversion?

Another thing I've read, if I'm not wrong, is that human perception follows a logarithmic rule in which you can only perceive changes in brightness if the exposure is increased in a factor of 2. Also the eye seems to be more sensitive to changes that are produced in the low areas of a scene, in the dark areas, rather that in bright ones, that's to say that we are more able to notice subtle changes in brightness in this dark area... That's one of the reasons log curves are designed this way to handle the data that come out of the sensor... so to have more info gathered in the dark areas, and increasing the steps for the samples in the bright areas... am I right?
so,what would be the reason for this spetial attention regarding bright areas ?

 

[Gunleik Groven]

OK, again I am no engineer, but I think this is an interesting discussion, so I answer more to get corrections than to give a definite answer.

As perception:
I find what you say... strange...?

Look at the sky: I can note an infinite level of blue's and in skintones, (which of course are lower) what makes it alive are the nuances, and one of the first things you notice in low-bitdepth formats is stepping in the skyes and plastic-like skintones.

While in the dark, I basically just see "a face with skin" but not wether it is too filled with makeup. Actually I will need much more makeup (higher contrast) to note what the eyes look like, or the mouth, as opposed to seeing it is "eyes" or "a mouth".

You have the saying: "at night, all cats look grey" which illustrates the point.

As to the eyes being logarithmic... Dunno. The eyes are very flexible and able to compensate images in the direction we find "normal" independently of color-temperature and lightlevels. Don't know much about this, really - but it is fascinating...

As to the mapping of the RED1, I think it is more practical considerations than anything else that made RED make the decissions they did...

Let's say (for arguments sake) that they found they could extract 11+ "theoretical" stops out of the M sensor, what was the lowest bit-depth they could keep all that info intact without having to add additional bitdepth for oversampling and remapping of the levels (which would demand more powerfull in-camera processing, powerdraw etc)

The answer is: 12 bit with one stop mapped to each bit, with a little re-mapping going on at the bottom and top to get higher precission at the lower levels, but not an internal - say 14 or 16 bit - oversampling to get a precise log result.

This way the approach to log was allowed to develop with experience - like we have recently got the brilliant redlogFilm option.

So... I think it was a practical/economical approach giving us this result.

The MX has wider latitude, and thus one have to give up some precission and a more "drastical" re-mapping has to take place to accomodate that within the available 12 bits. That gives a lot of promise for the Epic and its higher internal processingpower, though - even with the same sensor.

Dunno if these speculations even attempted to answer your questions, but these are the thoughts they triggered...

Cheers!

G

 

[illia]

Pixel values

Pixel values

Well, actually I think the hole visual perception is logarithmic.
Imagine a device that is increasing the brightness by steps, and you can choose the way to increase that brightness ... well, it's been studied that we perceive changes in brightness following a lograrhmic relation... this is call the Weber-Fecher law, and is not perfectly equal all along the hole range of brightness the human eye can handle (it fails in the low and in the highest part of the range)... well, that really sounds familiar isn't it... it's howthe photochemical system works...
Well, actually the hole human perception follows that rule of non linearity according to how we perceive changes in the stimulus.
Anyways, I'm not so good in math I'm going to quote the viper filmstream characteristics so you can understand better what are my doubts right now:
The human eye responds to light in a logarithmic way. The human eye can see more color values, and is also more discerning, the darker the scene. Therefore, it is preferable to assign more bits for the darker regions of the CCD range than for the brighter parts. A logarithmic transfer curve achieves precisely this by assigning smaller steps for the darker part of the range (more code values), and bigger steps for the brighter part (less code values). Moreover, the logarithmic data format can express more color tones. In fact, 10-bit logarithmic values would require more than 12-bits of linear values to maintain the same visible color space in order to express the full contrast range of the CCDs. By digitizing the CCD signals with logarithmic encoding, optimum use is made of the finite pool of available bits (a total of 1024 code values). The bits are used in the area where they are needed most in terms of the eye's sensitivity.


About the things you've described about your perception in the dark (absence of colour information) is due to the cells we have in the eye, cones and rodes... the cones (sensitivity to colour) aren't active in low light situations, where the rodes (sensitive to brightness changes) are.

 

[Gunleik Groven]

As to the eysight, I would think that not only one logarithmic curve would do, but what do I know...

As to the Viper argument, it is equal to what I say, just tat RED chose 12 bit lin, instead of 10 bit log. It all comes down to what the sensor records, though, and RED figured that 12 bit linear-light gave them the most flexibility for post (and further development). It is also a point that 12-bit log undebayered data is a lot easier to compress (apparently) and storage intensive, than a 12 bit RGB image.

For a person who have followed and done RED post allmost since it came out, that has made a lot of sense. - But I know that's besides the point of this thread... -

 

[David Rasberry]

It has to do with the way logarithmic exposure values ( EV or f stops) get mapped to digital values on a linear scale. The most obvious visible day to day example of what this looks like can be seen in low contrast deep shadow pixel blocking on any 8 bit LCD TV.

 

[illia]

What I still don't understanding is the pixel value issue... I think I understood that 10 bit linear o log or whatever, means that, for each and everypixel, you have 2exp10 possible values of ones and zeroes to describe what's happening there, in this case, colourwise...
Does this distribution of values I talked later, has something to do with the amount of values a pixel can have, I mean, is it a technical decision based on red criteria, or is the way CMOS work?

 

[illia]

Huh... I've donde some little research to find out that the pixel count issue is a very simple issue explained with very complicated words... The CMOS or CCD sensors are linear and respond to light in a proportional way... the double the light, the double the strength of the electrical signal that prduced by the sensor.

If we have a rich image well exposed, from pure black areas to pure white ones, we'll be using the hole capacity of the sensor to express values to describe this image, however, if we underexpose the same image of one stop, due to the linearity of the sensor, we're only having half of the hole possible values to describe the same image: that's the hole point, if we wanted to stretch the signal (in post) to recover the white, we'll have to create values that weren't there: so a crapy histogram...

 

[Gunleik Groven]

hm...

I thought this was the premise all along.

One can cheat the file, though - in an rgb recording, by remapping values with a log-curve, or you could do that in post with raw.

have you checked out redlogfilm on the same high latitude image set at 320 & 3200 iso?

 

[Lauri Kettunen]

According to this, the dark areas of the scene will have less possible values than the bright areas... but, the sensor has a linear response to the light... so, what is this all about?

Ok, let's make this straight. Think first of light in terms of counting how many photons hit the sensor. If n photons is the smallest amount of photons one is able to distinct from noise, then the next possible value that can be realiably read is 2n. The next value is obviously 3n, thereafter 4n, 5n, 6n, .... all the way up until clipping. Saying the sensor has a linear response to light means the output (which is about charge/voltages) is directly proportional to the amount of photons.

But now, if the same is expressed in powers of two which means in terms of stops, i.e., "twice" corresponds to "one stop", then the first stop is from n to 2n, but the next one is 4n, thereafter to 8n, 16n, 32n, 64n, 128n and so on. This is why the last stop has half of the bits, and thus, the idea to exposure-to-the-right.

Summing up, the output of the sensor is still linearly proportionally to the amount of light, but the output of the sensor is not linearly proportional to the amount of stops of light. Notice, if one reads the f-values, f1.4, f2.8, f5.6, etc. instead of the amount of stops these f-values reveal the coefficients that (basically) correspond with the amount of light/photons. (Somebody may feel compelled to make this more precise by explaining the difference between T and F-values, but I'll skip that.)

 

[Richard Foster]

The f-stop number is a ratio of the focal length of the lens to the diameter of the aperture. This value is not actual because it does not measure light loss through transmission through the glass elements of the lens. T-stop is the actual ratio taking into consideration the transmission (T) loss. Thus T-stop is a more accurate measurement of exposure.

For example an f1.8 lens may actually be a T2 or T2.1, and thus if you expose by the meter to f1.8 you will be a fraction of a stop under-exposed.

 

[illia]

But now, if the same is expressed in powers of two which means in terms of stops, i.e., "twice" corresponds to "one stop", then the first stop is from n to 2n, but the next one is 4n, thereafter to 8n, 16n, 32n, 64n, 128n and so on. This is why the last stop has half of the bits, and thus, the idea to exposure-to-the-right.

I think there's a misunderstanding about number of bits issue... every pixel has a fixed amount of bits designed to describe it's value, let's say: 12bit, that means that whatever is the light input, this signal is going to be sampled and translated into a digital number with 12 possible combinations of ones and zeroes, no matter the voltage for each pixel... this is an independent factor.
What really changes is the actual amount of combinations to describe the value of the pixel...

 

[Daniel Browning]

I've read many times that it's better to expose the red one to the right of the histogram (as the digital still cameras). This has to do with the noise floor of the signal and with the number of levels of the values of the pixel, according to the brightness of the scene.

The part about noise floor is correct, but the part about the number of levels is not. In the RED ONE, as in every well-designed raw camera, the accuracy is limited by noise, not the number of levels.

That's one way that camera raw files are different from computer-generated graphics files. In CGI, noise is optional -- you can create a 14-bit linear file that uses the maximum theoretical number of levels. The brightest stop of the file has a max of 2048 values and you canuse all 2048 of them. Or, you can add noise and reduce the effective number of levels to something much lower.

But in real life, photon shot noise is always there. In most cameras, it reduces the effective number of gradations from 2048 to less than 256. For this reason, only 8 bits are required to accurately record the top stop, and any intelligently-designed compression system assign bit depth based on tonal value.

The reason why ETTR is so beneficial is that it increases the amount of light. More light means less noise (less photon shot noise for a given image tone and further distance from the noise floor). Less noise means more color depth (tonal gradations), dynamic range, and many other things (flexibility in sharpening, etc.).

I think the main reason why this "number of levels" misconception has spread so widely is because of the ETTR page at Luminous Landscape.

When you ETTR 1 stop, you double the "maximum theoretical level of precision" for that set of tonal values, but if your actual accuracy is already far below the current maximum theoretical value, then increasing the maximum does you no good.

If bit depth (or number of levels) was all it took to increase tonal resolution, camera manufacturers would all be using 24- or 32-bit ADC and raw filesfiles. In fact, some MFDB do store 16-bit files even though, by their own admission, they need less than 13 bits. Here is a Phase One 16-bit where one half has been quantized to 12 bits and the other left at 16:




So there is no benefit to additional bit depth except to avoid quantization error.

Let's say there is a Skin Tone "A" that is exposed to be 3 stops below clipping at ISO 100, and it is completely dominated by photon shot noise. Skin Tone "B" is 2 stops below clipping, so there is one stop between the two tones. If it was a computer generated 12-bit file, there would be 512 different values possible between the two tones (the entire theoretical maximum is utilized). But in a camera-generated 12-bit file, there enough photon shot noise that the effective number of levels is much lower, we'll say 128 (I'm too lazy to calculate the real number). That means the theoretical maximum is not achieved.

Now, say we increase analog gain two stops (100 -> 400). That reduces read noise, which affects shadows, not midtones like this one. So there is no effect on the SNR. But it does increase the brightness, so now Skin Tone B is right as the very maximum value (4095) and Skin Tone A is one stop behind it: 2047. The theoretically possible number of tones is 2048, up from a theoretical 512 before. But the SNR has not changed, so the noise std dev still reduces the effective number of levels to the same amount it was before: 128.

Now say we took the same camera and scene, and upgraded it from a 12-bit ADC to an amazing (think Star Trek) 32-bit ADC that actually had 32 bits of precision. Now Skin Tone B goes from 4095 to over 4 billion and Skin Tone B goes from 2047 to 2 billion. The file can now store over 2 billion possible tonal gradations between the two skin tones. And if the file is computer-generated, it can actually have that many gradations. But the camera-generated file is still limited by photon shot noise. And still restricted to just 128 distinct gradations.

Now, let's change the 12-bit example so that instead of increasing the gain, we do the exposure (ETTR). ISO is left at 100 and exposure (f-number, shutter, flash, ND, etc.) is increased two stops. (f/8 -> f/4). Just as before, Skin Tone B goes from 1023 -> 4095 and Skin Tone A goes from 511 -> 2047. The theoretically possible number of tones is still 2048. But now, the SNR has increased due to photon shot noise. Instead of 128 possible gradations, there are many more (we'll say 512, as long as I'm pulling numbers from thin air).

For a real-life example, consider the following 14-bit image (Canon 40D) quantized to a variety of different bit depths. The noise is so high that there is no loss at 9 bits.



Now a more technical example. Say we have a 12-bit raw file of a white card from any semi-modern DSLR at ISO 100, exposed so that its average value is one stop below clipping. We'll say the number of detected photons is 43008, which makes the conversion gain 21 photoelectron per ADU. We'll set aside the effect of PRNU (which is very minor anyway). The mean raw level will be 2048 (out of 4096). The ADU will fluctuate wildly due to photon shot noise: one pixel will be 2038 and its next door neighbor 2058, because the std dev is 10 ADU (sqrt(43008)/21). Since read noise, thermal noise, and all other noises sources are insignificant at this luminance, the total S/N is 2048/10 = 202:1 = 7.66 stops.

What is the effect of going to 16-bits? Now the conversion gain is 1.3125 e-/16-bit ADU (20/2^(16-12)). With the same exposure (1 stop below clipping), the mean ADU is 32768 (2^(16-1)), and the number of photons is still the same (43008). But the the std dev is now 162 (sqrt(43008)/1.3125). Instead of jumping around by an average distance of 10 raw levels from the mean, they're now jumping around by 162. So you have 32606 right next to 32930. The S/N is 32768/162 = 202:1 = 7.66 stops, same as with 12 bits.

Technically speaking, it could be said that precision has increased, but there is no change in actual information content, accuracy, or S/N.

So the location inside the raw file doesn't really matter: the SNR is what's important, becuase the SNR itself is what limits the tonal resolution. The raw file should have a the theoretical maximum number of gradations that is larger than the actual gradations. Fortunately, that is always the case, because most cameras are correctly engineered. If they weren't, there would be quantization error (cases of that are pretty rare and minor).

I hope that helps.

 

[Lauri Kettunen]

I think there's a misunderstanding about number of bits issue... into a digital number with 12 possible combinations of ones and zeroes, no matter the voltage for each pixel... this is an independent factor.

Right, but binary number 000000000001 is the same as 1, 000000000010 is the same as 10 and so one. That is, although the zeroes are there in front, they have no meaning. Furthermore, between 100000000000 (eleven zeros) and 111111111111 (twelve ones) there are half of the bits/binary numbers.