Modern tech products (cameras, media players, phones, cars etc) are a blend of hardware with capabilities supplied by software. Although hardware is important, software can have a dramatic effect on usability, features and performance. With hardware increasingly becoming generic and available for manufacture by smaller companies, the main differentiation is in the software, which for some products will be backed up by company supplied infrastructure and services.
Many manufacturers are quite zealous (and I think, misguided) in preventing their products from running 3rd party or “unapproved” software, and use a variety of means to discourage this. Some manufacturers actively support 3rd party development, while others if not actually helpful will at least look the other way rather than impede such work. The situation is made somewhat more complex because some manufacturers rely on 3rd party development and open source to create their products in the first place.
One of the factors I consider when buying a new toy is whether it is a target for 3rd party firmware or software development either currently or in the near future. For some devices, this really pays off – for example, longterm problems with one aspect of my Linksys WRT54GS wireless AP/router that were never resolved by the manufacturer were resolved by installing 3rd party, open source firmware (Tomato) while at the same time adding capabilities that never existed on the original device.
Sansdisk made a small mp3 player (the Sansa e200 series) that could really only be described as pathetic as shipped, yet installing RockBox (an open source community project) dramatically improved the performance and audio quality of the player, and added support for multiple video formats, and games like Doom and Frozen Bubble. It is interesting to note that RockBox runs on Ipod media players despite active opposition from Apple. Hanlin e-book readers (manufactured by Jinke) rely on Linux as the device firmware, running on generic hardware – a logical target for 3rd party community development; and to date, the pace and improvement to capabilities provided by the Open InkPot project has been astounding.
Canon Hacker’s Development Kit
The same is true of digital cameras – to a large degree the hardware and features have all become very standardised, and it is software that makes the difference, and this is often used in ways to artificially create market segmentation and price differentiation. Features may deliberately not be implemented in software in lower priced cameras, possibly to simplify the user experience, but also to induce the customer to spend more on a higher priced camera with those features included.
CHDK let the cat out of the bag when it started in 2006. While it was initially a few individuals trying to make a Canon camera do something that they specifically wanted, it soon gathered momentum and has grown in scope and capability, and now actively supports a large range of Canon cameras. This includes cameras with the DIG!CII and DIG!CIII processors running VWorks and is currently just starting to support recent cameras with the DIG!CIV processor running DryOS.
Canon Hacker’s Development Kit (CHDK – as usual, community development often seems to pick annoying names) is an extension to the standard firmware installed on Canon “Point and Shoot” cameras. It is installed on an SD card and loaded when required, or (optionally) automatically loaded at boot – yes, just like any PC, your camera actually “boots” when you switch it on. This makes using it trivially easy as you don’t have to make any changes to the camera itself.
Once running, CHDK adds an astounding range of capabilities to even very basic cameras, for example:
- aperture priority and shutter priority even on fully automatic cameras
- ability to shoot RAW images – a feature usually only found on high-end enthusiast cameras
- USB remote cable release
- exposure bracketing
- focus bracketing
- very long and very short shutter times
- display tools to help get correct exposures (live histogram, zebra mode clipping indicators)
- the ability to run scripts on the camera
At first glance, the last item above seems a little strange, but it actually is the reason for much of the interest in CHDK. When you think about it, your camera has all the main components that your PC has – a processor, volatile and non-volatile memory, an OS, a display for output and keys for input. Consider that even a basic digital camera probably has a much faster processor, more memory and far more storage that the early PCs; even the display has a higher resolution than early PC monitors.
CHDK is able to run scripts that contain a subset of the features of uBASIC. Scripts can get input from, and control almost any aspect of the camera’s physical hardware – they can get input from buttons, write output to the display (and to files), emulate button presses to send commands to the hardware, control leds and so on. Scripts can use variables and logic just as you would in any BASIC, and as such is easily accessible to any body who has experience with BASIC from years past. For many PC enthusiasts at the dawn of personal computing, BASIC was the first language they used; strange to think it should still be useful in 2009.
Using scripts, it is possible to do things like timelapse photography, use long shutter delays, wide range exposure and focus bracketing, motion detection triggering (actually fast enough to capture lightning, handheld, in daylight!), with more capabilities being dreamed up continually.
Uses and Warning
CHDK opens up a whole world of photography, enabling the synchronisation of two (or even dozens) of cameras for stereo photography; control of cameras for rocketry and kite aerial photography; use of motion detection for surveillance and wildlife photography, even relatively simple timelapse and HDR photography.
Be aware though, that many of the activities that CHDK opens up will generate huge numbers of images and may require processing with specialised software. For example, timelapse photography will use hundreds of images for even a short video, and will require processing in Windows Movie Maker or VirtualDub; likewise HDR photography, though it doesn’t generate as many images, is most easily processed using free specialised tools unless you are proficient in and have a copy of Photoshop, the GIMP or similar. If you shoot RAW to avoid the camera’s preset noise processing, you will need software like Picasa or RawTherapee to process the file, and you may need software like Neat Image to perform noise reduction.
It is also important to note that CHDK runs invisibly in the background and just quietly enhances your camera’s functionality unless you configure otherwise. As such, it has many features that may be useful for day to day photography. However, in common with many community developed projects the user interface (though menu based) is extremely complex and offers a vast array of configuration choices. If you are not comfortable using your camera’s normal menu system you’ll likely find the CHDK interface difficult – but it is easy to try out to see.
Documentation and Examples
To get started with CHDK, go to http://chdk.wikia.com/wiki/FAQ – see if your camera is supported.
I’d been intending to experiment with timelapse photography for some time, and recently bought a very battered and cheap Canon camera for this specific purpose. The first few resulting videos can be seen at http://vimeo.com/hindesite/videos or at https://hindesite.wordpress.com/2009/07/03/timelapse-video-rona-bay-sunset/