这么一篇空洞无意义的文章实在是很浪费大家时间，于是我贴一张图吧。这是上周末在我阳台上拍的，定时每分钟一张，一共 29 张照片合成，动画速度是真实速度的一千倍。短短半个小时云行千里，请大家珍惜生命，远离博客，去看看大自然，哈哈。

技术信息：相机 Canon A570IS，使用 CHDK 脚本定时拍摄。土鳖低端相机也能用 Intervalometer，呵呵呵。

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!

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