1
  • Suppose I have 1 mega pixel sensor, it means I have 1*10^6 (1 mega) pixels.
  • If and only if each pixel represent the density of his color in 8 bit depth, so 8 bit = 1 byte, means each pixel is 1 byte
  • Then we have number_of_pixels*byte = 1*10^6*byte = 1 Mega Byte of data.

So why when most of the sensors are far beyond 8 bit depth, we still have image files with size very close to the number of mega pixels we have on the camera?

mattdm
  • 143,140
  • 52
  • 417
  • 741
michael
  • 113
  • 4

4 Answers4

6

To start with, the sensor doesn't output any color. Each pixel only records a single value: how much light struck the sensor. The number of bits determines how fine the steps between each brightness level can be. That's why a 12-bit or 14-bit file can record much finer gradations of lightness than an 8-bit file.

But raw files are also compressed, just normally in a lossless manner. If there are fewer unique values from all of a sensor's pixel wells the data can be compressed smaller than if there are more of the 2^12 or 2^14 possible tonal values for each pixel. Raw files from my 24MP camera generally run anywhere from 22MB to 29MB each depending on the content. Some cameras even use lossy compression to store raw files.

The way color is derived is by filtering each pixel for one of three colors: Red, Green, and Blue. But all that is measured on the other side of the filter by that pixel well is how much (i.e. how bright) light was allowed to pass through the filter. The filters still each let some light through that are colors other than the exact color of the filter. The further a color is from the color of the filter, though, the less amount of that color falling on the filter will make it through and be recorded by the pixel well. Some green gets past both the red and blue filters. Some red and blue get past the green filter. By comparing the difference in brightness of adjacent and surrounding pixels filtered for different colors the process known as debayering or demosaicing can interpolate an R, G, and B value for each pixel. Only after the color has been interpolated will the value of each color for each pixel be stated using 8-bits per color for 24-bits per pixel. In the case of JPEG this data will also be compressed. Basically JPEG designates which pixels are all the same exact combination of all of the different combinations of R,G, & B contained in the image. That is why images that are mostly the same uniform colors can be compressed smaller than images that have almost every possible combination of colors.

If you output a 28-30MB raw file from a 24MP camera after debayering it into a 16-bit TIFF the file will very likely be over 100MB in size because it is recording 16-bits for each of three colors for each pixel.

Michael C
  • 175,039
  • 10
  • 209
  • 561
  • Does "1 pixel" equals 3 physical pixels (R,G,B)? – michael Nov 28 '16 at 21:57
  • 1
    One the sensor, no. In a jpeg file, yes. On your monitor, yes. Unless you have a Foveon or similar sensor. But the vast majority of sensors in existence either have a Bayer mask in front of them or can only put put in monochrome. – Michael C Nov 28 '16 at 21:59
  • Speaking about the sensor, so the single pixel got his main color (by the filter) + little bit from the other 2 colors, and then during the debayering (on the file format) this pixel has RGB value = 3*single_color_bit_depth? But still on the raw format, this pixel store the raw brightness level he collected as single bit_depth (of his main color by filter)? – michael Nov 28 '16 at 22:02
  • Remember, light can have many more than only three wavelengths. Each filter is attenuated to be most responsive to a particular wavelength and less responsive to wavelengths on either side of that. Wavelengths near the attenuated value only lose a little brightness to the filter. Wavelengths lose more and more brightness the further they are for the color each filter is centered upon. The idea that the green filtered pixels all use the same value for green as the grey value from that pixel is vastly oversimplified. All three color values require interpolation from the monochromatic values. – Michael C Nov 28 '16 at 22:09
  • After debayering each pixel can have a 2^12 (or 2^14 or 2^10, etc - depending on the camera) value for green, a 2^12 value for blue, and a 2^12 value for red. It all depends upon the demosaicing algorithm exactly what the bit depth of each color for each pixel is. – Michael C Nov 28 '16 at 22:12
  • Look at it this way. If you put a color filter in front of black and white film you still get a black and white image. The difference is that the color of the filter affects which colors wind up a brighter gray on the film and which colors wind up a darker gray when they are the same brightness before they go through the filter. – Michael C Nov 28 '16 at 22:14
  • The way astronomical cameras on large telescopes created color images of celestial objects for many years was to take the same photo onto black and white film using various color filters and then deriving the colors from the differences between each exposure. – Michael C Nov 28 '16 at 22:17
5

Nearly all image file formats worth speaking of are compressed in some way. The mechanism for doing this varies depending on the file format you're using - but the files which you see will have been compressed. This is also why not all the files are the same size, despite having the same number of pixels in them.

Harry Harrison
  • 2,337
  • 2
  • 12
  • 20
  • Thanks, so besides the various compression algorithms, my thinking is correct? – michael Nov 28 '16 at 21:39
  • @michael yes, although you have to account for all colour channels and for any image headers or metadata – Harry Harrison Nov 28 '16 at 21:40
  • 2
    RAW data has no color channels. Each pixel value is a monochromatic luminance value. – Michael C Nov 28 '16 at 21:42
  • 2
    JPEGs are usually much smaller than 1MB per MP, usually by around a factor of 1/8 to 1/10. – Michael C Nov 28 '16 at 21:52
  • @MichaelClark I'd say: pixels have color channels, subpixels (which are separately available in RAW) don't. Every subpixel in the bayer matrix has only its one value. Right? – smow Nov 28 '16 at 22:11
  • But it is not a color. It is only a brightness value. It doesn't tell us exactly what shade of green or blue or red it is. It only tells us how many photons of all colors got by each of the filters. If you have a 2x2 matrix of R-G-G-B pixels with values of 130-188-188-155 it doesn't mean the red component of the first pixel will wind up 130 or that the green component of the green filtered pixels will necessarily wind up 188 or that the red component of the red filtered pixel will wind up 155. – Michael C Nov 28 '16 at 22:24
  • It just like putting a color filter in front of black & white film. You don't get colors. You just get different gray levels for things that are the same brightness but different colors. – Michael C Nov 28 '16 at 22:25
  • There's no such thing as a subpixel in bayer sensor. A 20MP sensor typically has 10 million pixels filtered for green and 5 million pixels each filtered for red and blue. Some Fuji sensors change the ratio slightly so that every 36 pixels have 20 green, 8 blue, and 8 red filters in front of them. – Michael C Nov 28 '16 at 22:27
  • That's why the absolute resolution of a classic (R-G-G-B) Bayer masked sensor is only about 1/√2 of the total number of pixels. – Michael C Nov 28 '16 at 22:30
2

Sensors are typically 12 bits of raw data per pixel, which is 1.5 bytes per pixel. (Some offer 14 bits, 1.75 bytes per pixel.) However, the data is typically compressed smaller in the file, which is STILL 12 or 14 bit data, but the compression result conceivably perhaps might crudely approximate one byte per pixel then (smaller than 1.5 bytes anyway, in the file).

But MB is NOT 1*10^6*byte. Million is, and mega is properly a million, however MB is treated special (not per mega definition), and MB is 2^20 bytes, or about 1,048,5576 bytes (so size in MB is about 5% less than size in millions). Megapixels properly use millions, but bytes usually use 2^20, which is 1024x1024.

When raw is interpolated into RGB, for example to JPG, then JPG is 8 bits per color, so then three bytes per pixel (when RGB and JPG).

WayneF
  • 12,879
  • 1
  • 16
  • 30
  • better not mention JPEG because it is not even RGB, but YCbCr – szulat Nov 29 '16 at 00:02
  • Only during the compression phase. JPG data of course goes in and comes out as RGB. Our monitors and virtually all of our printers can only use RGB. – WayneF Nov 29 '16 at 03:41
  • @WayneF: printer do no use RGB, but CMYK. Anyway JPEG is using YCC, so less bits per pixel (only Y is provided for all pixels). – Giacomo Catenazzi Nov 29 '16 at 16:32
  • No, the data absolutely comes out of JPG decode as RGB. The printer drivers do then have to convert it to CMYK, but (with exception of RIP, which is extremely uncommon except pro labs), our PC printer driver always expects to be given RGB data to process. Because, our operating systems, video cards, monitors, and photo software use only RGB. The computer has no use for anything else. YCC is only part of the internal JPG compression steps... NOT for any printer or computer. So this is just a distraction away from the question subject. – WayneF Nov 29 '16 at 18:07
  • @WayneF Yeah correct forgot that in CS MB is 2^20... – michael Nov 29 '16 at 18:59
2

Nop, your initial math is incomplete. Let me explain the math of uncompressed files.

  • 1 Mpx square photo. Ok.

  • 8 bits = 1 byte. Ok.

If the image were only grayscale yeap, the image would measure arround 1Mb. But an RGB file it is arround 3Mb because it has 3 channels. Prepare one image 1000x1000 and save it as 24 bit BMP format. 2.93Mb.

But that is for an uncompressed image.

Save the exact blank image in some other formats. In PNG will measure... 23k. 1/123 of the size of the uncompressed BMP file.

Compressed image's file weight has nothing to do with that math. It has to do with:

  • The file size (width and height)

  • The bit depth

  • The compression algorithm

  • The content of the image itself. A flat white square compresses very efficiently, but a photo of a landscape with a lot of trees and a house wil not do as eficient.

  • If the file supports it, other layers, or channels.

Rafael
  • 24,760
  • 1
  • 43
  • 81
  • RAW files are only "grayscale". – Michael C Nov 28 '16 at 23:43
  • @MichaelClark That's really digging into semantics. A RAW file has a series of values and CFAPattern/CFARepeatPatternDim (or equivalent), and while that doesn't cover the magic of demosaicing, it's completely reasonable to think of this as an array of RGB (or RGGB, or whatever) images. Insisting that it's grayscale seems like an affection without much value. – mattdm Nov 28 '16 at 23:58
  • But the values are in no way, shape, or form RGB values. All three of the RGB values have to be interpolated for each pixel. The information is no more "color" information than a B&W negative exposed with a filter on the front of the camera. – Michael C Nov 29 '16 at 00:00
  • The three different colors of the filters on a Bayer mask don't even have to be centered exactly on the wavelengths for the red, green, and blue values of RGB. As long as the demosaicing algorithm knows the exact colors of the Bayer filter it can interpolate correct RGB values. – Michael C Nov 29 '16 at 00:03
  • They don't have to be. You can just literally display them as a matrix of RGGB values. You can get a better image by demosaicing, but that doesn't mean there isn't a set of values which correspond to color in the first place. – mattdm Nov 29 '16 at 00:03
  • But the red filter doesn't allow only a specific wavelength of red light to pass through - there's even a significant amount of green that will pass through the red filter as well. The green filter doesn't allow only a specific wavelength of green to pass through - there's even a significant amount of both red and blue that will pass through the green filter as well. The blue filter doesn't allow only a specific wavelength of blue to pass through - there's also a significant amount of green that will pass through the blue filter as well. – Michael C Nov 29 '16 at 00:07
  • Literally displaying the values as a matrix of RGGB values will not even remotely approximate the correct values for the specific wavelengths of the components of RGB. – Michael C Nov 29 '16 at 00:09
  • 1
    @MichaelClark You're significantly over-complicating this. You can create a quarter-sized image by simply taking the R-G-G-B values for each four pixels into one, averaging the two green values and using red and green directly. You'll need to correct for white balance and color space (and make it non-linear for viewing), but that's a global adjustment — not anything to hang "it's not a color image" on. – mattdm Nov 29 '16 at 04:22
  • But that's not what happens when raw files are demosaiced by the overwhelming majority of converters and users. To stick our fingers in our ears and say, "La, la, la, la..." because we don't want to acknowledge the complexity of what is really going on is why we have people like smow who believe that every group of 4 RGGB pixels are subpixels of a single "pixel". The tonal information gathered by the filtered pixels can be used to debayer the raw data into pretty much any color space, not just RGB. There is not a necessary 1:1 correspondence between the colors of the Bayer mask and RGB. – Michael C Nov 29 '16 at 04:41
  • I genuinely think it is most helpful to understand what a raw file is and how we get color information from it if we see the data gathered as the digital equivalent of the analog process that used B&W film to collect three images of the scene with three different color filters over the front of the camera and then used the differences to produce a color image. Even if, ironically, that was closer to your 1/4 resolution non-interpolated version of the raw data than what really goes on. – Michael C Nov 29 '16 at 04:44
  • You can also convert to any color space from decomposed RGB layers. There's really nothing different going on here — that's not "la la la". You can treat the four pixels as subpixels (although in the normal array doing so in a naive way can produce spacial artifacts). – mattdm Nov 29 '16 at 11:32
  • We may have to agree to disagree on this — but you don't have to to just take my word for it. Here's a document from the people who wrote LibRaw http://www.fastrawviewer.com/viewing-raw-is-not-impossible – mattdm Nov 29 '16 at 11:32
  • PS obviously in my comment above that should say "red and blue directly" – mattdm Nov 29 '16 at 11:34