I installed CHDK on my Canon A570 IS camera and shot a few test pictures to find out defective pixels of my camera. To my surprise, this 7.1 mega-pixel CCD sensor has couple thousands defective pixels. The following picture represents the raw output from CCD sensor when I shot a 15 sec picture with ridiculously bright light source: (The green border is just showing image boundary, not from the actual picture.)

The raw file is 3152 columns by 2340 rows, 10 bits per pixel, so the file size is 3152 x 2340 x 10 bits = 9219600 bytes. The first few columns and rows are used for background subtraction (masked pixels, their values are usually around 30-40 on this 2¹⁰ = 1024 scale), so the active area is actually 3072 x 2304 pixels. The above picture is RAW CCD output down scaled to 0-255 and converted to 8-bit gray PNG (i.e., before demosaicing/gamma correction/any other process taken place). As you can see, there’re a lot (9205) of 0-valued defective pixels in the active area. There is no defective pixel in the masked area.

When I shot with faster shutter speed, I have less (2991) defective pixels. The following was shot with 1/250 sec shutter speed, showing CCD value 0 as black (defective pixels), 1-40 as gray (masked pixels), and 40-267 as white. No pixel has value more than 267.

I shot a lot of RAW pictures and found the number of defective pixels is either 9205 or 2991. Generally speaking, the slower the shutter speed, the more chance I get 9205 defective pixels. But I did have 2991 defective pixels with 1/30 sec picture, and 9205 defective pixels with 1/250 sec picture, with all other settings the same. So I have no idea what determines the defective pixel pattern. Also what’s interesting is those 2991 defective pixels are subset of the 9205 defective pixels.

If I go ahead and demosaic, combining RGB channels together, This is part of the image I get: (You can see defective pixels in different color channels.)

Instead, most RAW format processors find those 0-valued (sub)pixels and interpolate over with neighbor pixels. By doing that, here’s what I get: (white balance etc. was tuned a little bit as well)

Nicely white, no annoying dots any more, right? This “cheating” process is done inside the camera when saving JPEG file, and also done in most RAW format conversion. DNG specification states that:

Defective pixels should be mapped out (interpolated over) before the raw data is stored as DNG.

Enjoy your camera with 0.1% defective pixels!

（点进去可看原始分辨率大图）我的拍摄时间/地点是美西 11 月 24 日凌晨 1 点，西经 122 度，对照下面的 Stellarium 软件给出的星空图，我拍摄照片没有漏掉猎户座（Orion）和双子座（Gemini）的任何一颗哪怕再暗的星星，而当时我用肉眼根本认不全星座。

看起来民用相机要拍个简单的星空还是有可能的。由于镜头不够广角，我是拍了两个位置的照片拼接起来的，每个位置拍了三张 15 秒曝光的照片。照相机是标准 35 mm 镜头，横向视角 54 度覆盖 3072 个像素，所以在这 15 秒钟的曝光中，星星大概移动过 15 sec/(3600*24 sec) * 360 deg * 3072 pixel/54 deg = 四个像素；而且，15 秒曝光需要额外 15 秒去噪和一些存照片的时间，所以相邻两张照片的间隔大概是 40 秒钟，也即相差大概 10 个像素。下面是同一位置三张连续拍摄的照片直接叠加后的猎户座参宿四（Betelgeuse）区域的放大：

可以看到，星星的移动确实比较符合上面的计算。我需要在同一个位置拍三张的目的是为了取得更长时间曝光的效果，并且同时也能够平均掉一些噪声的影响（理论上说，在 CHDK 上写脚本拍摄可以获得更好的效果）。整个后期处理过程是：用 Matlab 自动寻找亮星位置确定偏移量叠加同一个位置的三张照片，然后到 Photoshop 旋转合成两个位置的照片，最后调整对比度和亮度以获得比较好的效果。

最后说一下火星，火星大概每两年绕太阳一圈，地球也会每两年接近一次火星，由于火星轨道在地球外面，所以接近的时候可以在夜晚很清楚的看到火星。现在看火星已经问题不大，不过要等到下个月中旬火星才最接近地球（火星轨道图），而且那个时候夜空没有月亮，看火星将会更加合适。

• Receiver: Thorlabs DET110 + 10k terminating resistor.
• Recording: 48 kHz sampling, 8 Bit, Mono. Delay settings I used:

  #define DELAY_SYNC   200
  #define DELAY_SPACE  50
  #define DELAY0       50
  #define DELAY1       100

  I slowed down the blinking to make my sound card happy. However, the following faster setting:

  #define DELAY_SYNC   45
  #define DELAY_SPACE  50
  #define DELAY0       1
  #define DELAY1       25

  does give very clean waveform (even with the shortest 5 us pulse) on the scope, so it should work with good sampling device (say a better sound card).

• LED: I used the least-frequently-used blue LED

  #define LED_BLUE 0xc02200c4

• Recording level set at about -5dB to -3dB
• Decoder setting:

  #define LEVEL_THRES_HI  0xa0
  #define LEVEL_THRES_LO  0x80
  
  #define LEN_SYNC        10
  #define LEN_SPACE       1
  #define LEN_0           3
  #define LEN_1           6

• Total dump time is about 2.5 hours. (about 3700 bits per second)
• I did not have any CRC error! I added an md5 checksum at the end. The camera took about 17 seconds to calculate md5sum of the 4MB firmware. Of course, no surprise, md5sum matches.
• Starting part of the dump:
  
  Decoded as 00110000, 00110001, 00110010, in other words, ASCII ‘0′, ‘1′, ‘2′. Also, for some reason the waveform is inverted (compared with CHDK website), so I have to manually invert the waveform for adc.
• The camera freezes about 3 milliseconds every few seconds. Here’s typical behavior:
  
  Since the protocol is decently robust, this extra delay is not a problem at all.
• Dumper code available for download: a570is dumper (based on code from CHDK website and kxn’s modification.).

Brilliant kxn ported CHDK to A570 IS 1.01A within two days.