# Why does an X megapixel sensor produce X MB of data (in image files)?

• 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?

• Can you provide a basis for your assertion that image file sizes are close to the number of megapixels captured? This does not match my experience. Nov 28, 2016 at 23:00
• We have +-10-20MP with files around +-10-30MB. If my calculation s correct we should expect files 2,3 times higher. Nov 29, 2016 at 12:02
• Are you looking at RAW or JPEG files? Nov 29, 2016 at 12:03
• Jpeg, but I expected the raws to follow my calculations... Nov 29, 2016 at 12:28

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.

• Does "1 pixel" equals 3 physical pixels (R,G,B)? Nov 28, 2016 at 21:57
• 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. Nov 28, 2016 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)? Nov 28, 2016 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. Nov 28, 2016 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. Nov 28, 2016 at 22:12

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.

• Thanks, so besides the various compression algorithms, my thinking is correct? Nov 28, 2016 at 21:39
• @michael yes, although you have to account for all colour channels and for any image headers or metadata Nov 28, 2016 at 21:40
• RAW data has no color channels. Each pixel value is a monochromatic luminance value. Nov 28, 2016 at 21:42
• JPEGs are usually much smaller than 1MB per MP, usually by around a factor of 1/8 to 1/10. Nov 28, 2016 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, 2016 at 22:11

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).

• better not mention JPEG because it is not even RGB, but YCbCr Nov 29, 2016 at 0: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. Nov 29, 2016 at 3: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). Nov 29, 2016 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. Nov 29, 2016 at 18:07
• @WayneF Yeah correct forgot that in CS MB is 2^20... Nov 29, 2016 at 18:59

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.

• RAW files are only "grayscale". Nov 28, 2016 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. Nov 28, 2016 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. Nov 29, 2016 at 0: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. Nov 29, 2016 at 0:03
• @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. Nov 29, 2016 at 4:22