Page top

Home page

Contents

Index

API

Page bottom

Defective pixels

There is an advantage in combining photos which have not been guided, and this was a further motivation for developing GRIP. Digital cameras typically have several defective pixels. Obviously manufacturers try to keep them to a minimum but if they rejected all but the absolutely perfect detector chips (assuming that is achievable at all) the cameras would be far too expensive - astronomically priced you might say. The interpolation process which gets from the RAW data to an RGB image (see our image structure page) generally also deals with the defective pixels. The camera manufacturers will have built something for that into their processing. So in most kinds of photography a few defective pixels scattered across the frame are not significant. They are never seen.

However, in a series of well-guided astrophotographs defective pixels are a real problem because a star image, comprising only a very few pixels, is drastically modified if some of those pixels don't work properly. The conventional way of reducing the consequences of defective pixels is to take "dark frames" (with the lens cap on) and subtract them from the real frames. The dark frames should be of the same exposure length as the real photos and taken at the same temperature. What tends to happen is that defective pixels claim to have detected some light even when dark and the amount they detect increases with exposure time and temperature, rather like the noise we discussed earlier.

The author's view is that that is a far from satisfactory correction, so GRIP is designed to use a different approach. Fix the camera on a tripod (or simply on the ground). Deliberately do not follow the sky as the Earth rotates. Then all star images will move across the detector, falling in a different position in every frame relative to any defective pixels. GRIP then aligns the images and averages them so that the region overlapped by all photos in the series is corrected both for noise and for defective pixels. The more photos are taken in the sequence, the fainter will be the evidence of defective pixels (forming trails now, among the fixed stars) in the result. The trade-off is that the area of overlap gets smaller so, depending on the angular field of view, there is a limit to the overall time range of the series of photos.

GRIP is able to load RAW files and show the original data in image form, before the processing to convert to RGB. This makes it possible to see the defective pixels, so we can map them for any particular camera. Here is a magnified example from the author's Canon EOS 5D. The RAW (.cr2) file has been loaded, the contrast has then been auto-stretched (all channels by the same amount) and in the hovering measurement mode an area around a pair of defects has been magnified in a separate window:

Canon EOS5D dark frame 30s ISO1600

In my camera there are about 30 such defective pixels (out of 12.8 million). They are completely repeatable, so they are not just noise. By magnifying a portion of the raw data away from the defects and auto-stretching the contrast even further, noise pixels can be seen. They are different in each photo, not repeatable. Look at this image from different angles and you will see some of them:

Canon EOS5D dark frame 30s ISO1600

So there will inevitably be some defective pixels in your camera. How can we find out where they are and deal with them? (This is only a problem for predominantly dark images, such as astronomical ones.)

I have become convinced that the positions of these pixels are recorded in each RAW image file, inside the <MakerNote> metadata tag, but camera manufacturers keep the details secret. Evidence for this is that if I spend time converting my RAW images to TIFF using Canon or Adobe software before processing them through GRIP, the results of my astro-process no longer contain the bright primary-colour spots revealing the bad pixels. So I think Adobe are allowed to read where my defective pixels are, and interpolate to repair them, but I am not! I have spent quite a lot of time examining the MakerNote data but cannot see where the particular information is or how it is represented (there are several possible ways that I can think of). GRIP's Exif class would enable you to have a go: see here.

I have provided menu options in GRIP to enable the defective pixels to be detected, saved as a list, and repaired when RAW images are processed. Before version 8.2.7 of GRIP this was very experimental and unreliable but now I have used the results of my experiments to make a useful facility. However, the user has to understand what is going on, which I will now describe.

With the lens cap still on the camera, take a 30-second RAW photo at ISO 1600, a so-called dark frame. Open the image in GRIP. Go to the levels menu and use auto-stretch (all channels the same). Zoom in so the image is displayed at 100%. Scrolling around you will soon notice isolated bright pixels in primary colours. On the measurement menu, select Whole image. This will produce a histogram looking something like this:

Towards the right of this graph there are brightness levels represented by very few pixels in the image - just one or two pixels for each. Those are the defective pixels. But the left side of the graph shows that we do not have perfect blackness. The peak of the graph occurs significantly above level 0. That is due to thermal noise. If the camera were cooled or warmed I would expect that peak to move respectively to the left or right. Unfortunately (in my camera at room temperature anyway) there is no clear gap between the noisy-but-functional pixels and the defective ones.

On the levels menu of GRIP (version 8.2.x onwards) there is an option to "Detect defective pixels". This will record the positions of all pixels with a brightness in any channel that is more than a certain fraction of the maximum brightness that could occur. The actual values used are set in the configuration menu. There are two relevant properties in the configuration:

1. the "RAW bits per channel", default value 12 (some recent high-end cameras are 14); this determines the maximum level captured: 4095 for 12 bits (or 16383 for 14 bits).
2. the "RAW defects, proportion of maximum level", default value 0.8.

The default values of those mean that for my camera, with 12 bits per channel, the brightness above which a pixel would be considered to be defective in a dark frame is 0.8 x 4095 = 3276. Using these settings I find that GRIP detects 23 defective pixels.

If I vary the proportion setting, the number of defects detected changes, as I would expect from the histogram. Results on one particular dark frame were as follows.

I interpret this to mean that I definitely have at least 19 defective pixels and probably more like 30-something. The sudden increase in the last row of the table is because simply noisy pixels are being recorded. The noisy pixels would not be the same ones in every image. So the next step will be to do the measurement on several dark images and only record as defective those pixels which are brighter than some level x on every image. This is planned to be available as an automated process from the batch menu soon (as of 3 Feb 08).

The defective pixels detected from the levels menu as just described are saved in a comma-separated values (CSV) file (a text file, so easy to examine). The configuration menu has an option for reloading such a file. If a list of defects has been loaded, the option on the levels menu for interpreting a RAW image first repairs the defects before doing the Bayer interpolation. The repair consists of replacing the value at each defective position by the average of 4 values from the pixels 2 away (north, east, south and west).