• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname

    Register

    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

Bayer Filter, sensor, bit depth

Leonardo Boher

pro member
Hi,

I know what's demosaising and color depth, bayer filter, sensors, ACD, S/N and most of the technical stuff, but I have a question and hope some grinner could drop some help since I could'nt obtain an answer by browsing the Internet.

I'm starting to think that (will put a 9mp sensor as something figurative):

1) A 9mp sensor has a Bayer Filter before of it.
2) This Bayer Filter, filters the respective color that belongs to each filter's color.
3) We have then, the mosaising.
4) So, the true color is just 1/3 per mosaic, the others are generated by interpolation by the ADC.

Conclusions (self deduction):

1) Each color is fragmented in mosaics.
2) The sensor is divided by these mosaics which are 3 (RGB).
3) So, a 9mp sensor has 3mp per mosaic.
4) When demosaising occurs, we have the composition, which is the sum of the 3 mosaics RGB and, in consecuence, the 9mp of the sensor, fully covered. (Sounds like a Gif file or Indexed files).

I'm starting to think that a demosaised RAW of any bits has 1/3 of the whole tonal values. For example, a 12 bits RAW File, which has 4.096 tonal values in total (I assume after demosaising) has 1365.33 tonal values per each channel, depicting the color interpolation.

But I have a doubt, because a JPEG (256 tonal values per channel) will have, in this statement, 85.33 tonal values per mosaic...

Suppose we have a 12 bit file.

This file has 12 bits (4.096 possible tonal values) per mosaic? or just in the whole composition, the sum of the 3 mosaics, and just in the demosaising we achieve those 4.096 possible tonal values?

I'm asking this because I cannot find in Google if those 4.096 possible tonal values are per mosaic or they become that amount in the demosaising process.

Thanks in advance. I will appreciate a lot some light in this matter :)

Leo :)
 

Andrew Rodney

New member
2) This Bayer Filter, filters the respective color that belongs to each filter's color.

Actually the sensor is a photon counter and there's no actual color other than the color of the filter and, at some point in the processing pipeline, an assumption of the XYZ (usually) color based on the filtration used (red, two green's and blue). IOW, the color characteristics of color are those colored filters.
 
Hi,

I know what's demosaising and color depth, bayer filter, sensors, ACD, S/N and most of the technical stuff, but I have a question and hope some grinner could drop some help since I could'nt obtain an answer by browsing the Internet.

I'm starting to think that (will put a 9mp sensor as something figurative):

1) A 9mp sensor has a Bayer Filter before of it.
2) This Bayer Filter, filters the respective color that belongs to each filter's color.
3) We have then, the mosaising.
4) So, the true color is just 1/3 per mosaic, the others are generated by interpolation by the ADC.

Conclusions (self deduction):

1) Each color is fragmented in mosaics.
2) The sensor is divided by these mosaics which are 3 (RGB).

What you have at this point, is a projection of the scene colors through (usually) 3 filters, where 25% of the filters is Red, 50% is Green, and 25% is Blue. The great and elegant invention by Dr. Bryce E. Bayer is in the arrangement of those filters. They are strategically placed in order to allow the sensor array to sample the projected image, with a good distribution that allows a decent full color reconstruction of the missing parts of the spectrum. It also allows to reconstruct the Luminance per pixel of the original scene quite well (but that demosaicing is more complicated than simple interpolation, if you want good results).

The demosaicing does not use neighboring RGB filtered sensel triplets to recreate an RGB pixel. Instead, for each sensel, the missing colors are reconstructed from clues given by surrounding sensels in addition to what was already recorded after filtering. Thus, for each sensel position a full RGB pixel is created and usually output after applying a tonecurve of some sort.

Bart
 

Leonardo Boher

pro member
Actually the sensor is a photon counter and there's no actual color other than the color of the filter and, at some point in the processing pipeline, an assumption of the XYZ (usually) color based on the filtration used (red, two green's and blue). IOW, the color characteristics of color are those colored filters.

Hi Andrew! I think I know you from other place...

Yeah, I know a bit of that, but what about the amount of tonal values per color. I don't think a 12 bit file will have 4.096 values per each color, for example. I cannot find in Google about how much tonal values are per channel in a 12 bits fiole inside the camera, before demosaising and after demosaising. Do you have any clue?

Thanks again for the reply, Andrew :)

Leo :)
 
Hi Andrew! I think I know you from other place...

Yeah, I know a bit of that, but what about the amount of tonal values per color. I don't think a 12 bit file will have 4.096 values per each color, for example. I cannot find in Google about how much tonal values are per channel in a 12 bits fiole inside the camera, before demosaising and after demosaising. Do you have any clue?

Leo,

The number of bits only tells you how many separate levels of luminance for a given filter color can be discriminated. It tells how detailed e.g. a gradient can be recorded. That binary value is used in the demosaicing calculations and the results can be represented with higher numbers of bits to retain the subtleties after gamma correction and other tonecurve adjustments.

Bart
 
Last edited:

Leonardo Boher

pro member
Thanks for the reply Bart, but I'm still wondering how many tonal values holds the camera before demosaising and after doing it. Because the image is not composed, rather than de-composed in 3 colors (Bayer here) I'm wondering if each of those 3 colors have 4.096 tonal values in a 12 bits file or they exists just in the demosaised "image". Otherwise, the demosaised image should have 4.096�³.

By the way, what does mean "Sensel"? Couldn't find in dictionaries (I have the babylon program).
 

Leonardo Boher

pro member
Leo,

The number of bits only tells you how many sepatrate levels of luminance for a given filter color can be discriminated. It tells how detailed e.g. a gradient can be recorded. That binary value is used in the demosaicing calculations and the results can be represented with higher numbers of bits to retain the subtleties after gamma correction and other tonecurve adjustments.

Bart

Hi Bart,

So we're talking that a 12 bits file has 4.096 tonal values per mosaic color? Wondering wondering...
 

Doug Kerr

Well-known member
Hi, Leonardo,

"Sensel" is the name used to describe one of the elements in a sensor. Since we use the CFA scheme, each such element does not (of itself) determine the color of one pixel of the image (that being only inferred through demoscaicing). The term "sensel" (rather than "pixel") is intended to remind us of that

Thanks for the reply Bart, but I'm still wondering how many tonal values holds the camera before demosaising and after doing it. Because the image is not composed, rather than de-composed in 3 colors (Bayer here) I'm wondering if each of those 3 colors have 4.096 tonal values in a 12 bits file or they exists just in the demosaiced "image". Otherwise, the demosaiced image should have 4.096�³.

The output of each sensel is typically encoded to a precision of 12 bits (a little less than 4096 values, since the bottom of the scale is not used) or 14 bits (again, with perhaps the same caveat).

The precision of the demosaiced pixels (in the "first RGB representation") depends on the scheme used for calculation and its precision. (For example, that work may be done with 16-bit arithmetic.) And in most cameras, we do not have that stage of the output available to us. It has an unknown number of bits for R, G, and B (people often assume 8, but that is not necessarily so).

When that RGB image is is encoded into JPEG form, it is first converted it to YCbCr form, with 8 bits per component (8 for Y, 8 for Cb, and 8 for Cr). That would seem to conceptually provide 2^24 different recordable colors, but it doesn't, since many of those YCbCr combinations imply "impossible" RGB combinations (colors that are out of the sRGB gamut), and are thus not allowed in a "standard" JPEG representation.

When the JPEG file is decoded, an RGB image with 8 bits per component is often generated, but it may in fact be in 16 bits per component (for example, we can tell Photoshop to do it either way for us). But of course the actual equivalent "bit depth" is limited (not in an easily-calculated or explained way) by the 8 bit depth of the YCbCr representation that is actually "sent".
 

Leonardo Boher

pro member
Hi, Leonardo,

"Sensel" is the name used to describe one of the elements in a sensor. Since we use the CFA scheme, each such element does not (of itself) determine the color of one pixel of the image (that being only inferred through demoscaicing). The term "sensel" (rather than "pixel") is intended to remind us of that



The output of each sensel is typically encoded to a precision of 12 bits (a little less than 4096 values, since the bottom of the scale is not used) or 14 bits (again, with perhaps the same caveat).

The precision of the demosaiced pixels (in the "first RGB representation") depends on the scheme used for calculation and its precision. (For example, that work may be done with 16-bit arithmetic.) And in most cameras, we do not have that stage of the output available to us. It has an unknown number of bits for R, G, and B (people often assume 8, but that is not necessarily so).

When that RGB image is is encoded into JPEG form, it is first converted it to YCbCr form, with 8 bits per component (8 for Y, 8 for Cb, and 8 for Cr). That would seem to conceptually provide 2^24 different recordable colors, but it doesn't, since many of those YCbCr combinations imply "impossible" RGB combinations (colors that are out of the sRGB gamut), and are thus not allowed in a "standard" JPEG representation.

When the JPEG file is decoded, an RGB image with 8 bits per component is often generated, but it may in fact be in 16 bits per component (for example, we can tell Photoshop to do it either way for us). But of course the actual equivalent "bit depth" is limited (not in an easily-calculated or explained way) by the 8 bit depth of the YCbCr representation that is actually "sent".

Hi Doug :)

Mmmhhh... Too much info... Seems the topic goes far beyond from what I thought...

I guess "sensel" is some kind of slang, a mix between sensivity and pixel.

I understand that each primary color is represented by each mosaic generated by the Bayer Filter and decomposing the image in mosaics we have some kind of image divided into red; green; and blue squares per mosaic.

Now, my question is if each of those squares are composed by 4.096 tonal values or, only after demosaising, the image have those 4.096 tonal values.
As far as I've red in thousand of forums and websites, a 12 bit image has 4.096 tonal values, but those forums or websites don't specify if those tonal values are per mosaic or in the final RAW image.

That's my doubt, shrotly explained.

Thanks for the reply, and please, let me know about that.

Thanks again :)

Leo :)
 
By the way, what does mean "Sensel"? Couldn't find in dictionaries (I have the babylon program).

Sensel is short for Sensor element, one element from the sensor array. It distinguishes it from the (e.g. RGB) pixel that's the result of demosaicing.

So we're talking that a 12 bits file has 4.096 tonal values per mosaic color? Wondering wondering...

Yes, it encodes a potential maximum of 4096 discrete signal levels per sensel position (if not for some noise offset at the lower end of the scale, and perhaps a maximum a bit lower than 4095). But that is only a value which is the start of a calculation of a color. At this stage it is only part of a color, the rest is yet to be calculated. The 12-bit value represents not a color but an integrated amount of energy in a part of the spectrum (roughly a bandpass of 1/3rd of the visible spectrum, but with some overlap with the neighboring spectral regions). The calculation is complex and may require more bits to represent the resulting pixel color without too much inaccuracy.

Bart
 

Doug Kerr

Well-known member
Hi, Leonoardo,

Mmmhhh... Too much info...
Only enough to "partly" answer your questions. (See the tag to my signature block.)

I guess "sensel" is some kind of slang, a mix between sensivity and pixel.
Sorry I forgot to decode that, but I see my colleague has filled in the gap. It is short for sensor element.

I understand that each primary color is represented by each mosaic generated by the Bayer Filter and decomposing the image in mosaics we have some kind of image divided into red; green; and blue squares per mosaic.

No, the mosaic is the entire array of sensels, with the different filters in front of them. We do not speak of one "cluster" of a filtered sensel from each of the four sets as a "mosaic". The clusters are not treated as entities.

The demosaicing algorithm attempts to guess the luminance and chromaticity of the scene at each pixel location (these will be at all the same locations where the sensels are) by looking at the output of the sensel at that point and a number of surrounding ones (which have differing "color" sensitivity). Do not think of this as examining the four sensel outputs in a predefined "little mosaic". The pattern of sensels actually examined depends on the particualr algorithm used.

The output of each individual sensor is digitized into a 12 or 14 bit number (depending on the camera model). Thus, except for the fact that we cut off the bottom of the range for various reasons, the output of each sensel could take on up to 4096 (or 16384 values).

The demosaicing algorithm uses a number of bits that is a design decision - perhaps 16. It does not automatically follow from the bit depth of the sensel outputs (although it might be the same).

After the demosaicing algorithm makes its guess as to the color (luminance and chromaticity) of each pixel (as I discussed above), it records that temporarily in (usually) RGB form, with each coordinate typically stated in the number of bits used in the calculation (again, perhaps 16). Thus, there might be up to 65,536 distinct colors for each pixel in this intermediate image - we don't know this, and we don't get to look at this RGB image.

The rest of the process I discussed in my earlier message.

Best regards,

Doug
 

Leonardo Boher

pro member
Sensel is short for Sensor element, one element from the sensor array. It distinguishes it from the (e.g. RGB) pixel that's the result of demosaicing.



Yes, it encodes a potential maximum of 4096 discrete signal levels per sensel position (if not for some noise offset at the lower end of the scale, and perhaps a maximum a bit lower than 4095). But that is only a value which is the start of a calculation of a color. At this stage it is only part of a color, the rest is yet to be calculated. The 12-bit value represents not a color but an integrated amount of energy in a part of the spectrum (roughly a bandpass of 1/3rd of the visible spectrum, but with some overlap with the neighboring spectral regions). The calculation is complex and may require more bits to represent the resulting pixel color without too much inaccuracy.

Bart

Mmmhhh

Okay, let me see if I get it.

4096 discrete signal levels exists in each mosaic, so, when demosaising occurs, what happens with all these 4096 tonal values? I mean, if we have 4096 tonal values per mosaic, so, after demosaising occurs, we should get lot of tonal values, which is 4096 multiplied per 3 or 4096³?(each mosaic). My head is going crazy.

For one hand, we have that the Bayer Filter only get 1/3 of the total amount of "colors" (at the end of the day they're shades of grey) because the way the colors are composed, by using green and blue, but the red part of the filter is only able to grab pure red (other colors are rejected), same with the other colors of the filter. Like an injeckt printer, needs to mix colors in order to get some type of red.

For the other hand, we have these 4096 tonal values per mosaic (or per "channel"). So the demosaised image has lot of tonal values which are a third of the whole image after interpolation?

Why a 12 bits image has 4096 tonal values? It's that the result of demosaising? I know that 2 multiplied by 12 gives 4096 because the bytes/bits and such, my question goes for other road :)

Sorry for aswking so much, Bart. But I don't have other place to ask for.

Thanks a lot. If you don't want to keep answering, is okay :) Otherwise, I will keep wondering ^^

Leo :)
 

Leonardo Boher

pro member
Hi, Leonoardo,


Only enough to "partly" answer your questions. (See the tag to my signature block.)


Sorry I forgot to decode that, but I see my colleague has filled in the gap. It is short for sensor element.



No, the mosaic is the entire array of sensels, with the different filters in front of them. We do not speak of one "cluster" of a filtered sensel from each of the four sets as a "mosaic". The clusters are not treated as entities.

The demosaicing algorithm attempts to guess the luminance and chromaticity of the scene at each pixel location (these will be at all the same locations where the sensels are) by looking at the output of the sensel at that point and a number of surrounding ones (which have differing "color" sensitivity). Do not think of this as examining the four sensel outputs in a predefined "little mosaic". The pattern of sensels actually examined depends on the particualr algorithm used.

The output of each individual sensor is digitized into a 12 or 14 bit number (depending on the camera model). Thus, except for the fact that we cut off the bottom of the range for various reasons, the output of each sensel could take on up to 4096 (or 16384 values).

The demosaicing algorithm uses a number of bits that is a design decision - perhaps 16. It does not automatically follow from the bit depth of the sensel outputs (although it might be the same).

After the demosaicing algorithm makes its guess as to the color (luminance and chromaticity) of each pixel (as I discussed above), it records that temporarily in (usually) RGB form, with each coordinate typically stated in the number of bits used in the calculation (again, perhaps 16). Thus, there might be up to 65,536 distinct colors for each pixel in this intermediate image - we don't know this, and we don't get to look at this RGB image.

The rest of the process I discussed in my earlier message.

Best regards,

Doug

Doug, I'm sorry, but I couldn't understand. Do you have a link or something that explains these topics? It seems something quite large, like a book. I'm not good a maths, so, if it could be something more graphic, the better.

Actually, no one in my country knows about this stuff, so I cannot go to some school and ask to some teacher... Sad, yes, saaaaaaaaad. I hate that, I hate that I cannot go to some school and learn this. All what I know have been learnt by reading in the Internet.

Thanks, and my apologizes for not understanding and wasting your time and the time of the people who responded here... well...........................................
 

Doug Kerr

Well-known member
Hi, Leonarh0,

Do you have a link or something that explains these topics? It seems something quite large, like a book. I'm not good a maths, so, if it could be something more graphic, the better.
Well, there is a lot of stuff, but you would really have to wade through it to find out what you are interested in.

Let me suggest that you patiently review what I have said here, taking the time to let each step "sink in". I'll bet you will get there!

Best regards,

Doug
 

John Sheehy

New member
Why a 12 bits image has 4096 tonal values? It's that the result of demosaising? I know that 2 multiplied by 12 gives 4096 because the bytes/bits and such, my question goes for other road :)

The output of a converter can use whatever level of precision it likes, and can conceivably use all of it, even if it is much deeper than the original RAW data. Simply applying WB and performing the demosaicing can "ask" for more levels than the RAW data has, from a purist's perspective. RAW data and converted images are completely different in terms of their needed precision. The need for precision in the output is determined by the amount of noise reduction used (the smoother you make your output, the more precision it needs to avoid posterization). If the output is left dithered by noise, precision is less important.

Noise changes everything. Simple mathematical ponderings about the numbers of levels fall apart when noise enters the picture, and it enters every digital RAW, no matter how clean the output may look or be. Noise limits the usefulness of high precision.

Interpolation changes everything as well. Interpolations need extra precision to accommodate the "in-between" values needed, just to avoid posterization (if only at the purist's level); not because there is more information per se.

Some of the more noisy digitals can actually represent all of the RAW capture very well with just 30-40 levels at high ISO. 40 level may be sufficient in the output, if left noisy, but with any kind of heavy noise reduction, more levels are needed to avoid posterization.
 
Mmmhhh

Okay, let me see if I get it.

4096 discrete signal levels exists in each mosaic, so, when demosaising occurs, what happens with all these 4096 tonal values? I mean, if we have 4096 tonal values per mosaic, so, after demosaising occurs, we should get lot of tonal values, which is 4096 multiplied per 3 or 4096³?(each mosaic). My head is going crazy.

Don't go crazy, it's not worth it ;-)

Think of it this way. The photons that pass the filter on top of a specific sensel are accumulated during exposure. Depending on design, the sensel can store a limited number of photons in the form of their electronic charge (e.g. 1500 photons per square micron, or 1500 electron Volts). The actual charge levels for each sensel are read by the camera's image processor circuits, and converted to a binary number for each sensel, which is then stored in the Raw data.

The required precision of those numbers (their bit depth) depends on the quality of electronics and the resulting dynamic range (dynamic range is the ratio between maximum signal level and the noise floor). If e.g. there is a maximum charge of 60000 electrons per sensel, and the 'read noise' is 6, then the dynamic range is 60000:6 (or 10000:1, same ratio). To encode such differences with enough precision, it would be adequate to use a 14-bit number (Log(10000) / Log(2) = 13.3 bits). Lower quantities, and/or lower dynamic range, could be represented by fewer bits. That also means that e.g. the 60000 photons will be represented by a number like e.g. 10000, therefore the so-called Analog to Digital conversion (ADC) uses a certain "gain" factor to make things fit within the available bits. There are several other sources of noise besides read noise, but I'm trying not to complicate things too much.

You'll notice that I haven't mentioned color or something like it yet. We have at this stage binary numbers in the Raw file that represent, within the camera's capabilities of precision, numbers of photons that passed the filters. So each Raw data number (DN) represents a range of spectral energy, and each DN can consist of a number of photons from different wavelengths or frequency. The numbers from many surrounding sensels are combined with the actual registration by a sensel, and that result is output as a simplified tri-chromatic number, usually an RGB triplet for each output pixel.

Since that triplet is calculated from a complex combination of many numbers, the actual values for R, G, and B, might be best represented by floating point numbers, but that would consume a lot of space, and we ultimately would like to have 8 or 16-bit integer values so we can display/print them easily. So it makes sense to store them in a format that's fit for that purpose, and that usually also involves a gamma correction (another calculation that results in a floating point result). Since that result has to be rounded to integer numbers, one often uses precalculated lookup tables to speed up the calculations by avoiding to do them repeatedly.

As you may see, there is no simple direct relationship between the number of bits in the Raw data, and the number of colors in the output pixels.

Bart
 

Leonardo Boher

pro member
Hi bart :)

Mmmmhhh.......... I'm getting the point of this... I know the surface of all these events: photon -> Lens -> Bayer Filter -> Mosaicing -> Photodiodes -> Static (noise) -> Demosaising -> Image. That's what I know and that was what I found in the Internet.

My curiosity started in the bayer filter and its relation with the sensor. I guess each square on the Bayer Filter is aligned with each square in the sensor. An straight aligmnet between the Bayer Filter and the sensor. So, if we have the Bayer Filter divided into 3 colors (RGGB), so, the sensor also gets divided into 3 portions, so I can say that the 25% of the sensor is for the reds, other 25% for the Blues and 50% for the greens. So the sensor is not really a 9mp sensor (let suppose a 9mp sensor), it's a 1.5mp for the reds, 1.5mp for the blues and 6mp for the greens, in other words. That's why there are 3CCD cameras, in order to avoid so much interpolation in the ADC and more fidelity in the colors, I suppose.


Don't go crazy, it's not worth it ;-)

Think of it this way. The photons that pass the filter on top of a specific sensel are accumulated during exposure. Depending on design, the sensel can store a limited number of photons in the form of their electronic charge (e.g. 1500 photons per square micron, or 1500 electron Volts). The actual charge levels for each sensel are read by the camera's image processor circuits, and converted to a binary number for each sensel, which is then stored in the Raw data.

Mmmmmhhhhhh....... This has more sense now... That's why the sensor is more a photon counter than other thing. It stores photons, I know that, but I didn't know that each sensel has a limit. I wold like to know what is the parameter that determines that limit, may be the bit depth? The Dynamic Range? I'm guessing that burnt highlights means that the sensel have reached its limits and it have been overwhelmed by photons.
I'm guessing here is some kind of relation between the amount of photons allowed per sensel and with the dynamic range (in general terms) and much more with the bit depth. Talking in deeper words, we cannot say that each camera has certain stops of dynamic range because that's purely determined by the sensel. As far as I understand, the sensel is the dynamic range and is the bit depth of certain camera because the sensel is like the cells that composes the human eye. Of course, the process of the ADC "polish" this structure and the sensel is not the final result, just the begining, exactly like the vision: our eyes only collect photons but many group of neurons, behind the hypothalamus and the cerebellum, are resposible of representing the colors we see, representing the movement, shapes and the like. In fact, we have like 2 sensors with billon of sensels (retina's nerves) which nerve impulses are sent to our 12 ADC (the12 groups of cells, responsible of what and how we see) in the back of our brain which backs to our brain the image (the RAW image). If I'm getting closer, this comparisson between the human vision and the camera vision should be correct.

The required precision of those numbers (their bit depth) depends on the quality of electronics and the resulting dynamic range (dynamic range is the ratio between maximum signal level and the noise floor). If e.g. there is a maximum charge of 60000 electrons per sensel, and the 'read noise' is 6, then the dynamic range is 60000:6 (or 10000:1, same ratio). To encode such differences with enough precision, it would be adequate to use a 14-bit number (Log(10000) / Log(2) = 13.3 bits). Lower quantities, and/or lower dynamic range, could be represented by fewer bits. That also means that e.g. the 60000 photons will be represented by a number like e.g. 10000, therefore the so-called Analog to Digital conversion (ADC) uses a certain "gain" factor to make things fit within the available bits. There are several other sources of noise besides read noise, but I'm trying not to complicate things too much.

Mmmmhhh.... I got the read noise thing and how it modifies the dynamic range, also the thing of "same ratio". So not all the photons are grabbed by the sensels. It will depend on the read noise and then, the ADC fills the gaps with interpolation.

You'll notice that I haven't mentioned color or something like it yet. We have at this stage binary numbers in the Raw file that represent, within the camera's capabilities of precision, numbers of photons that passed the filters. So each Raw data number (DN) represents a range of spectral energy, and each DN can consist of a number of photons from different wavelengths or frequency. The numbers from many surrounding sensels are combined with the actual registration by a sensel, and that result is output as a simplified tri-chromatic number, usually an RGB triplet for each output pixel.

Okay, let see... a certain amount of photons are stored in a sensel, this amount of photons are represented by a Data Number (DN). This DN gets combined with the sorrounding DN from other sensels and they get combined in a tri-chromatic number per output pixel. Same happens when converting from TIFF to PSD, for example. TIFF maitains the independence of each RGB color which are merged when passing the TIFF to PSD. For example, R=235; G=5; B=5 gives us a certain type of red and it independence is kept by the TIFF File, but converting to PSD we will get just one color, which is the result of merging each color into one, and that color will have some kind of DN like an hexadecimal value like # f00505. If I'm correct in this comparisson between DN and Hexadecimal Values I'm understanding this topic.

Since that triplet is calculated from a complex combination of many numbers, the actual values for R, G, and B, might be best represented by floating point numbers, but that would consume a lot of space, and we ultimately would like to have 8 or 16-bit integer values so we can display/print them easily. So it makes sense to store them in a format that's fit for that purpose, and that usually also involves a gamma correction (another calculation that results in a floating point result). Since that result has to be rounded to integer numbers, one often uses precalculated lookup tables to speed up the calculations by avoiding to do them repeatedly.

As you may see, there is no simple direct relationship between the number of bits in the Raw data, and the number of colors in the output pixels.

Bart

yeah, I see... I will keep thinking...

Thanks Bart :)
 

Andrew Rodney

New member
So the sensor is not really a 9mp sensor (let suppose a 9mp sensor), it's a 1.5mp for the reds, 1.5mp for the blues and 6mp for the greens, in other words. That's why there are 3CCD cameras, in order to avoid so much interpolation in the ADC and more fidelity in the colors, I suppose.

I guess that's one way of looking at it. But after demosaicing, you've got 9MP of pixels, albeit, using interpolation of color to get there.

I'm more upset by the so called "megapixel" rating when its used to describe the sensor in total, not the majority that is used to capture an image. That's cheating. Some of the pixels are used for tasks other than image capture.
 

Leonardo Boher

pro member
I guess that's one way of looking at it. But after demosaicing, you've got 9MP of pixels, albeit, using interpolation of color to get there.

I'm more upset by the so called "megapixel" rating when its used to describe the sensor in total, not the majority that is used to capture an image. That's cheating. Some of the pixels are used for tasks other than image capture.

Hi Andrew! :)

Yes, I understand that after demosaising I got the 9MP again, but I suppose that's because the fusion of each mosaic. Making it simplier: R25%+B25%+G50% = RGB100% = 9MP again, despiting the interpolation, we get pure 9mp again. With interpolation it could be 9.3mp more or less...

I'm curious about what are those tasks you mention "Some of the pixels are used for tasks other than image capture".

Thanks for your reply, was clear and balanced and cleared part of my doubts :) I will ask you something more: When we say that a 12 bit file has around 4096 tonal values, is that per channel or just in the whole image?

Leo :)
 

Andrew Rodney

New member
I'm curious about what are those tasks you mention "Some of the pixels are used for tasks other than image capture".

White balance for one. Probably others as well but after dinner and wine, I'm fried <g>.

Its not a great number of pixels but pixels used for non image capture. So a manufacturer can quote the full sensor values without necessarily quoting the image capture values. Just a pet peeve.
 

Leonardo Boher

pro member
Sensel is short for Sensor element, one element from the sensor array. It distinguishes it from the (e.g. RGB) pixel that's the result of demosaicing.



Yes, it encodes a potential maximum of 4096 discrete signal levels per sensel position (if not for some noise offset at the lower end of the scale, and perhaps a maximum a bit lower than 4095). But that is only a value which is the start of a calculation of a color. At this stage it is only part of a color, the rest is yet to be calculated. The 12-bit value represents not a color but an integrated amount of energy in a part of the spectrum (roughly a bandpass of 1/3rd of the visible spectrum, but with some overlap with the neighboring spectral regions). The calculation is complex and may require more bits to represent the resulting pixel color without too much inaccuracy.

Bart

Hi again Bart, I'm re-reading some of the posts.

You say that "it encodes a potential maximum of 4096 discrete signal levels per sensel position". Could you explain this a bit more? It looks like each sensel is able to hold 4096 signal levels.

Thanks,

Leo :)
 
Hi again Bart, I'm re-reading some of the posts.

You say that "it encodes a potential maximum of 4096 discrete signal levels per sensel position". Could you explain this a bit more? It looks like each sensel is able to hold 4096 signal levels.

Hi Leo,

The 'sensel' itself stores a charge, an analog Voltage. The ADC encodes that analog Voltage as a digital data number. If 12-bit data numbers are used, then we can theoretically use the values 0-4095 for that encoding. In practice the effective range that is usable is a bit smaller. At the low end there is mostly noise, and at the high end there can be slightly lower numbers for a saturated DN.

Cheers,
Bart
 

Leonardo Boher

pro member
Hi Leo,

The 'sensel' itself stores a charge, an analog Voltage. The ADC encodes that analog Voltage as a digital data number. If 12-bit data numbers are used, then we can theoretically use the values 0-4095 for that encoding. In practice the effective range that is usable is a bit smaller. At the low end there is mostly noise, and at the high end there can be slightly lower numbers for a saturated DN.

Cheers,
Bart

Hi Bart!

Ah, okay...So I must assume that the sensel is constatly receiving photons (as the shutter is open) and the ADC just grab that data and convert it into binries?
 

Doug Kerr

Well-known member
Hi, Leonardo,
Hi Bart!

Ah, okay...So I must assume that the sensel is constatly receiving photons (as the shutter is open) and the ADC just grab that data and convert it into binries?
Yes, it receives photons the entire time the shutter is open, and that causes an ongoing change in the electric charge of the sensel, which results in a change in the sensel voltage (which reflects that charge). At the end of the exposure, when the shutter has closed, the system grabs that voltage and converts it to a binary number.

Best regards,

Doug
 

Leonardo Boher

pro member
Hi, Leonardo,

Yes, it receives photons the entire time the shutter is open, and that causes an ongoing change in the electric charge of the sensel, which results in a change in the sensel voltage (which reflects that charge). At the end of the exposure, when the shutter has closed, the system grabs that voltage and converts it to a binary number.

Best regards,

Doug

Ah!!! Thanks!!! I'm going in the right direction!!! Finally, I'm getting some clear concepts!!! =D =D =D
 

Doug Kerr

Well-known member
Charge vs. discharge

Just for the benefit of all the onlookers, let me mention this.

It is popular to think of the operation of a sensel detector as that when each photon strikes, it causes an increment of charge (one electron, actually) to be deposited, thus increasing the charge in the little capacitor that is one aspect of the sensel detector (and thus increasing the voltage across that capacitor).

In fact, in the typical sensel detector, the detector is pre-charged to a certain voltage (and thus charge) before the onset of exposure. As each photon strikes, it in effect causes a momentary "leak" which dissipates one electron worth of charge. Thus the voltage sinks as further photons strike.

After the exposure, the then-voltage on the capacitor is compared with the original voltage, and the difference (the decrease in voltage) is digitized, to be an indication of the total amount of photometric exposure received by the sensel detector.

Now, this leads to two phenomena of considerable concern to us:

If the initial charge voltage is not absolutely stable, then the interpretation of the after-exposure voltage of the capacitor as a voltage change will not be correct, a source of random variation in the readout (part of the infamous "read noise").

If the reference voltage (to which the after-exposure voltage of the capacitor is compared) is not absolutely stable, then the interpretation of the after-exposure voltage as a voltage change will not be correct, another source of random variation in the readout (another part of the infamous "read noise").

Best regards,

Doug
 

Doug Kerr

Well-known member
Those intersted in further technical insight into the operation of the sensel detectors in a typical CMOS sensor array may find interesting my technical article, "The CMOS APS Digital Camera Sensor", available here:

http://doug.kerr.home.att.net/pumpkin/index.htm#CMOS-APS

Note that "APS" here does not refer to the sensor size (we actually never use that repulsive notation), but stands for "Active Pixel Sensor".

Best regards,

Doug
 

Leonardo Boher

pro member
Those intersted in further technical insight into the operation of the sensel detectors in a typical CMOS sensor array may find interesting my technical article, "The CMOS APS Digital Camera Sensor", available here:

http://doug.kerr.home.att.net/pumpkin/index.htm#CMOS-APS

Note that "APS" here does not refer to the sensor size (we actually never use that repulsive notation), but stands for "Active Pixel Sensor".

Best regards,

Doug

I went to your website at the first time you posted here... Too much for my brain. I don't have enough knowledge to understand what's written in your website. I'm sorry :(
 

Doug Kerr

Well-known member
Hi, Leonardo,
I went to your website at the first time you posted here... Too much for my brain. I don't have enough knowledge to understand what's written in your website. I'm sorry :(
No need to be sorry - following these technical discussions isn't for everybody.

I any case, we are all enjoying your wonderful photography.

Best regards,

Doug
 
Top