# Why are effective pixels greater than the actual resolution?

This page compares Canon EOS 550D and Canon EOS 500D cameras and mentions

18.7 million effective pixels

for 550D. However the best resolution possible using this camera is

5184 * 3456 = 17915904 ~ 17.9 million pixels


What are effective pixels, and why is that number greater than 17.9 million in this case?

• Also be aware that "resolution" has two meanings. In computers, we use it to refer to the pixel dimensions of a screen or image. And in a computer drawing or generated image, that usually does correspond to the "real" resolution — the amount of detail actually resolved in the image. But in a photograph, it's not necessarily the case. Commented Mar 13, 2011 at 16:54
• That's not what's going on here — just an additional source of confusion. Commented Mar 13, 2011 at 16:54
• Hmm. What happens when someone with dyslexia tries to type 17.8? Could they actually enter 18.7? Commented Jan 20, 2022 at 21:47

Part of what we're seeing here is (I'm reasonably certain) nothing more than a simple typo (or something on that order) on the part of DPReview.com. According to Canon, [PDF, page 225] the number of wells on the sensor is "Approx. 18.00 megapixels".

Those are then reduced to the approximately 17.9 megapixels when the Bayer pattern inputs are turned into what most of us would think of as pixels. The difference is fairly simple: each well on the sensor only senses the total amount of light allowed through a colored filter, but a pixel as you normally expect it in the output (e.g., a JPEG or TIFF file) has three colors for each pixel. At first glance, it might seem like that would mean a file would have only about one third as many pixels as there are sensor wells in the input. Obviously, that's not the case. Here's (a simplified view of) how things work:

Each letter represents one well on the sensor. Each box represents one tri-color pixel as it'll go in the output file.

In the "interior" part of the sensor, each output pixel depends on input from four sensor wells, but each sensor well is used as input to four different output pixels, so the number of inputs and number of outputs remains the same.

Around the edges, however, we have sensor wells that only contribute to two pixels instead of four. At the corners, each sensor well only contributes to one output pixel.

That means the total number of output pixels is smaller than the number of sensor wells. Specifically, the result is smaller by one row and one column compared to the input (e.g., in the example, we have an 8x3 sensor, but 7x2 output pixels).

• +1 especially for the diagram. But I'm still puzzled, because this would explain the absence of 2(5184-1 + 3456-1) = about 17K pixels, which would just be lost in the rounding in computing 18.0 - 17.9 = 0.1M pixels. It would seem that at least three times as many pixels have to be stripped from the boundary (because anything less than 50K should round down to 0.0M). Perhaps the demosaicing is using a larger neighborhood than the 2 x 2 ones shown here: maybe it's using around a 7 x 7 neighborhood? Commented Mar 13, 2011 at 19:05
• @whuber: Offhand, I'm not sure I can directly account for the rest. It's certainly possible to use more sensors to produce a single output pixel, but I don't have any real way of know that it's what Canon is doing in this case. A raw file from the camera would give the exact number of sensor wells, but still wouldn't tell exactly how Canon is getting from input X to output Y. Commented Mar 13, 2011 at 19:38
• In good demosaicing algorithms (e.g. adaptive homogeneity-directed) each sensor well contributes to more than four output pixels so it's more than just one row or column that gets lost. It's easy enough to grab the undemosaiced output from dcraw and compare image dimensions with the output of Canon's DPP to get a definitive answer, I'll give it a go when I have time. Commented Mar 13, 2011 at 20:07
• @Matt Grum: Right -- looking back, my previous comment is rather poorly worded. What I was trying to get at is that there are several algorithms that could (and will) lose/discard ~3 row/columns of pixels, but pixel count alone won't tell you which of those they're using. Using a more sophisticate algorithm that uses more sensors per output pixel is virtually a given though. Commented Mar 13, 2011 at 20:16

There are two reasons why the effective pixels are less than the actual number of sensor pixels (sensing elements, or sensels.) First, Bayer sensors are composed of "pixels" that have color filters over them, allowing more light the same color as the filter through than light of different colors. Usually, we call them red, green, and blue filters organized in row pairs in the form of:

RGRGRGRG
GBGBGBGB


A single "pixel" as most of us are familiar with it, the RGB style pixel of a computer screen, is generated from a Bayer sensor by combining four sensels, an RGBG quartet:

          R G
(sensor)       -->  RGB (computer)
G B


Since a 2x2 grid of four RGBG sensels is used to generate a single RGB computer pixel, there are not always enough pixels along the edge of a sensor to create a full pixel. An "extra" border of pixels is usually present on Bayer sensors to accommodate this. An additional border of pixels may also be present simply to compensate for the full design of a sensor, serve as calibration pixels, and accommodate extra-sensor components which usually includes IR and UV filters, anti-aliasing filters, etc. that may obstruct a full amount of light from reaching the outer periphery of the sensor.

Finally, Bayer sensors must be "demosaiced" to produce a normal RGB image of computer pixels. There are a variety of different ways to demosaic a Bayer sensor, however most algorithms try to maximize the amount of RGB pixels that can be extracted by blending RGB pixels from every possible overlapping set of 2x2 RGBG quartets:

For a sensor with a total of 36 single-color sensels, a grand total of 24 RGB pixels can be extracted. Notice the overlapping nature of the demosaicing algorithm by watching the animated GIF above. Also note how during the third and fourth passes, the top and bottom rows were not used. This demonstrates how the border pixels of a sensor may not always be utilized when demosaicing a Bayer sensel array.

As for the DPReview page, I believe they may have their information wrong. I believe the total number of sensels (pixels) on the Canon 550D Bayer sensor is 18.0mp, while the effective pixels, or the number of RGB computer pixels that can be generated from that base 18mp, is 5184x3456 or 17,915,904 (17.9mp). The difference would boil down to those border pixels that can't quite make up a full quartet, and possibly some additional border pixels to compensate for the design of the filters and mounting hardware that go in front of the sensor.

• I just noticed that I counted sensels wrong in my animated image. In the first two steps, it doesn't combine 8 sensels...it combines 28 sensels into 8 pixels. In the final two steps, it combines 14 sensels into 4 pixels. Sorry for the discrepancy. I'll try to fix it soon. Commented Mar 15, 2011 at 18:50

I don't know why the term "effective" is used by DPReview, but there are a couple of reasons for the discrepancy between the number of photosites (pixels) on the chip and the size in pixels of the resulting images.

Some camera sensors have a strip of masked pixels down each side. These pixels are identical to the bulk of the pixels on the sensor except they receive no light. They are used to detect interference and subtract it from the signal produced by the light sensitive pixels.

Secondly [good] demosaicing algorithms use lots of "neighbourhood operations" this means the value of a pixel depends somewhat on the value of it's neighbouring pixels. Pixels on the extreme edge of the image have no neighbours so contribute to other pixels but don't add to the image dimensions.

It's also possible that the camera crops the sensor for other reasons (e.g. the lens image circle doesn't quite cover the sensor) although I doubt this is the case with the 550D.

• Are the border pixels used to remove interference, or just to set the black point? Commented Mar 13, 2011 at 17:24
• Both I guess, if there wasn't any interference (including thermal response) the black point would be 0 Commented Mar 13, 2011 at 18:08
• DPReview's description. It seems to me as though it goes back and forth between two opposite concepts, and I don't see it actually define the term, except implicitly. Your answer I think helps a little, but still leaves me wondering why the "effective" pixels would be more than real photo sites, though the dpreview page does give some possibilities. Effective: used to effect image data? Or image date ultimately so effected? (note: effect verb with an e: creating existence.) I'm still wondering which they mean. Commented Mar 13, 2011 at 18:21
• DP Review probably uses effective pixels because Canon uses the same term when describing their sensors. But in the case of Canon, the number of effective pixels equals the dimensions of (uncorrected for lens distortion) out of camera JPEGs and is ALWAYS less than the number of actual photo sites on the surface of a sensor. I think in this case someone at DP Review just typed the wrong number. Commented Jan 20, 2022 at 21:43

Sorry to dissappoint, but none of those explanations are true. On every sensor there is a region outside of the imaging area that also contains photosites. Some of these are turned off, some are turned on completely, and some are used for other monitoring purposes. These are used to set amp and white-balance levels, as a "control set" against those doing the actual imaging.

If you take the RAW sensor data from any of the CHDK compatible Powershot cameras, and use dcraw to convert them, you can obtain the full sensor image including these 100% black and 100% white regions.

What is interesting though, is that in-camera RAW image-size resolution is always larger than in-camera JPG results. The reason being, the simpler and faster interpolation methods used in-camera to go from RAW to JPG require surrounding RGB photosites to determine each pixel's final color. Edge and corner photosites don't have these surrounding color references on all sides to do so. Doing the process later though on a computer with better RAW interpolation software, will enable you to regain a little more image-size resolution than what can be obtained from an in-camera JPG.

p.s. DPReview reviewers and article authors should never be taken as gospel by anyone. I've found so many holes in their tests and blatant examples where the testers didn't even know how to use cameras, that I have discounted their advice many years ago.

• Despite your comment that "none of those explanations are true", other answers actually cover this already. Commented Apr 7, 2011 at 0:46