In this project, you're going to write some simple C code to manipulate image data at the pixel level using the PPM format. In particular, you're going to use Dave Coffin's dcraw to convert raw images into PPM files which you will then use to do a very crude type of HDR image synthesis.
HDR (which really stands for High Dynamic Range) refers to the concept of capturing scene details that span an exceptionally large range of brightness. Dynamic range (DR) is essentially the ratio between the lightest and darkest distinguishable tones in a scene. That sounds simple enough, but the word distinguishable actually has a somewhat imprecise meaning. For example, in darker portions of a scene, noise from both the camera and the light itself (photon shot noise) make distinguishing different tones a statistical thing; what probablity threshold do we apply to call two tones distinguished? A common answer is 50% certainty, but that seems rather generous.... There is also the issue of tonal resolution; how small must the tonal step be to consider a tone distinguished from a similar tone? In any case, measuring DR of a captured image isn't quite as straightforward as you'd expect.
Of course, imprecision in the defition doesn't prevent folks from measuring and talking about DR. DxOMark and sensorgen give lots of measurements. Usually, DR is expressed in terms of stops or (equivalently) EV. One EV change represents a doubling or halving of the brightness. In real life, it is not clear that there are limits on the EV that can be spanned within a scene, and it certainly isn't difficult to find examples with over 20EV. Imagine looking at the Sun from inside a dark cave... but don't actually do that. Why? Because human eyesight isn't designed to handle such great instantaneous DR. The exact number is debatable, but humans can see something 10-14EV DR at a glance; our pupils dilate/constrict (mydriasis/miosis for MDs, change f/number for us) to allow us to handle a larger DR over time. The problem is that most digital cameras only have about 9-11EV DR, which means they can't even record what we see at a glance. Some of the better sensors, notably many made by Sony, can capture 13-15EV DR... which is great, but still far from sufficient for that cave-to-Sun view. Perhaps more importantly, it's also insufficient for things like seeing the kid walking behind your car when the backup camera is blinded by another car's headlights. It's also not sufficient if you're trying to capture the lighting of the scene so you can duplicate it in computer-generated renderings that you are placing in the images (e.g., movie special effects).
HDR imaging begins with using some trick to capture image data with a larger-than-normal dynamic range. Normal DR for your Canon PowerShot is about 9-10EV, and it really can't do much better -- in one capture. However, it can if we capture multiple exposures of the exact same scene with a range of exposure settings so that images range from underexposed to overexposed. This can be done quite easily using CHDK. Shoot in raw mode to get the maximum possible DR -- you'll then use dcraw to convert them into PPM files. Let CHDK build 8-bit PPMs; 16-bit is not necessary.
Given a set of normal DR images, the next step is to merge them into a single HDR image. Classically, this is done by a camera calibration procedure.
Finally, there is the issue of taking the HDR image data and mapping it into a reasonable-looking normal DR display or image file. This is usually called tone mapping.
What will you do? Well, you're going to write a program that avoids the calibration and tone mapping by writing C code that simply averages a bunch of PPM files.
Reading a PPM (Portable Pixel Map) file is actually very easy, and I'm making it even easier by giving you code to read and write them. Here is C code to read and write P6 files using memory mapping for the input. I do expect you to use mmap() to read the input PPM files, although it is acceptable for you to use conventional file I/O provided you write your own code the read the PPM files (your code may be derived from the code I gave you).
You will be submitting source code for your CHDK Lua script (if you used one), stand-alone C code that does the HDR combining, a make file (which does whatever is necessary), and a simple "implementor's notes" document. For this project, you don't have too much to talk about in the notes, but you should at least mention how you got PPM images to input.
For full consideration, your project should be submitted no later than the Final exam timeslot. Submit your .tar or .tgz file here: