The black dot problem
The Canon 5D Mark 2 was announced on Sep 17th 2008 and many early orders were fulfilled around Christmas. Unfortunately, the camera turned out to have a defect that was particularly noticeable in pictures featuring Christmas lights. The problem shows up as black dots directly to the right of small bright lights. Here “to the right” assumes landscape mode and this translates to top (or bottom) in portrait mode. The problem shows up on RAW images and presumably in JPG images as well.
I have only photo showing this, taken during a Winter evening (Canon 70-200mm f/4L IS, 800 ISO, 1 stop underexposed, f/4, 1/60 s, 21 MPixel Raw, camera firmware 1.0.6).
Pixel peeping to the max
If you would plot the intensity scanning from left-to-right through one of these small highlights, you expect to see pixel brightness rise to the maximum measurable intensity, a plateau at this maximum intensity (255 on an 8-bit scale), a decrease down to background intensity. BUT (see actual scan at the end of the article), the ramp down “overshoots” and forms a small black dot.
You normally only see these black dots when viewing at 100% and can miss them unless you are looking for them. They appear to be a digital processing artifact. One clue is the phrase “to the right of..”. The lens itself has axial symmetry, so will not know what we users consider to be the right side of the image. The sensor itself (at the photosite level) also cannot behave like this. So the problem apparently lies in analog or digital signal processing inside the camera.
Speculations on the cause
One likely culprit seems to be the “highlight tone priority” feature which attempts to avoid blown highlights. This presumably gives a local HDR-like treatment: the area around a highlight is digitally underexposed to compress the scene’s dynamic range. This helps keep the bride’s bright white wedding dress from showing burnt out highlights.
If the “highlight tone priority” algorithm works left-to-right, you could imagine that a bright spot will result in a local adjacent dark spot – just like you are temporarily blinded by the headlights of an oncoming car at night: the feedback loop in your vision which reduces the pupils and probably sensitivity of the retina itself needs some time to adjust to the “normal” darkness again.
But this assumes that “to the right” is somehow associated with “later” in time. A digital filter is normally design to work symmetrically: the information needed to compensate in all directions (left, right, up, down) is available once you have a bitmap stored in memory. So the “black dot to the right” is reminiscent of analog processing whereby the photo sites are read out left-to-right and first processed using analog circuitry. The fundamental reason for this is that an analog filter which fed with a time-dependent signal can only react to the present (current signal) or past (previous signal values) and not to the future (the still to be processed pixels). A simple analog gain control loop (e.g. used to regulate audio levels) shows such behaviour: after a strong signal, it may temporarily be blinded.
Fortunately, speculations about the detailed cause of black dots are no longer relevant. Canon supplied a firmware upgrade (1.07) in early January which fixes the problem.
The fact that it could be fixed by a digital modification may suggests that it is a digital algorithm problem (you can design algorithms that have this blinded-to-the-right phenomenon simply by emulating an analog filter), or that the analog processing is digitally controlled or that the problem can be masked by digital means. Current collective Internet opinion suggests that critical users seem satisfied with the patch. Unfortunately the firmware patch has the side-effect that the raw convertors created for the Canon 5D2 now need software upgrades but this is a one-time inconvenience for early adopters. So either this patch is fixing the problem rather than masking it, or the masking simply works well enough.
Since I took the above picture, I have upgraded to the 1.0.7 firmware and will hopefully not run into the problem again.
The details are even weirder
The graph shown above shows the intensity of the Red, Green, and Blue channels when I scanned manually (Lightroom) from left to right throught the topmost (of the the two) Christmas lights. The basics are obvious: the light has a width of about 16 pixels. Blue is a little less intense on the left side, leading to the yellow color. There is indeed a dip around X=2 which is clearly lower than that around X=16. The peak at X=6 is due to the proximity of a second light source.
The dip at X=2 is not convincingly lower than the intensity at X=-18 or X=13. This might be explainable by strong linearity: you firstly need to combine R/G/B into a single number which might just be lower at 2 than at 13. And you apparently need to subtract a black level from that. Some have reported that the dip is actually lower than the black level you subtract, leading to a negative light intensity.
The RGB readout of Lightroom shows the dip at X=2, while the darkest spot on the screen is clearly at X=0. This is likely a bug in Lightroom 2.2, but needs validation.
The RGB readout of Lightroom (at 11x) shows 11×11 pixel squares. Strangely the Lightroom cursor seems to read out varying intensity within a square (as if you could read out the intensity at sub-pixel resolution). So the actual values will tend to vary a bit if you repeat the experment.