Well sensor noise comes in two main flavors - read noise and photon shot noise. The photon shot noise is inherent in the light - photons come in semi-randomly. The read noise is noise in the sensor circuitry.

If you take 100 pictures with 1/100s exposures and average them, then in terms of photon shot noise it's the same as taking a 1s exposure. You've recorded the same number of photons. However, you paid the read noise penalty 100 times, and while you're still averaging that away, you start with a lot more than if you just took a 1s exposure.

So in the end, your synthetic 1s exposure is noisier than a real 1s exposure, but much less noisy than the longest hand-held exposure you could normally take (~1/60s, depending on focal length).

So it works pretty well.

Well no, to be honest. Right now we're using Canon lenses in front of a tiny sensor. This gives us a 6x crop factor, so we're wasting almost all of the field of view of the lens. We're currently working on replacing the sensor with something larger.

Yeah, that's exactly the kind of thing we're talking about. You need low level access to the sensor for it to work. In fact, that idea works so well that its one of the few things from the area that has made it into a commercial camera - the Casio EX-F1 does it.

You can find such lens specifications available for most lenses in patent databases. The patents list the curvatures, indices of refraction, etc, etc. That's kind of the point of patents - when used correctly they remove the need for trade secrets. I'm not sure if this holds true for Canon lenses in particular.

I agree with you that many aspects of the hardware are not as open as they could be. However, we're trying to make a camera that actually works well as a camera without reinventing too many wheels. We'd also like to be able to replicate and distribute the camera to other researchers. That means off-the-shelf parts that anyone can buy, like Canon lenses.

- Andrew (one of the grad students involved)

Computational photography is the accepted term for this subfield of computer graphics and computer vision: http://lmgtfy.com/?q=computational+photography

Secondly, we're not making an open source camera OS for existing hardware, we're making camera hardware that runs an existing open source OS - linux - with particular drivers and APIs to help you program the camera.

We're very well aware of CHDK and have used it for many projects. This is not like that (I have an earlier post that elaborates above).

Because we have a lot of Canon lenses lying around. It's not a fundamental part of the system - it would be easy to switch in a different lens mount.

- Andrew (one of the grad students involved)

It's not a Nokia imaging chip, it's just the one that happens to be used in Nokia N95s. Aptina makes it and sells it to anyone who wants one. They do make you sign an NDA to get the full data sheet, but that's pretty much impossible to avoid.

As the poster above mentioned, Canon lenses have been thoroughly reverse-engineered.

The lenses would be fairly easy to swap out for a different optical system - we communicate with the lens controller over a simple serial link. The sensor is more involved - for one you'd need a linux kernel driver for your new sensor. Also, it's a pain to properly mount a sensor and get the all support circuitry working. None of it is secret or proprietary though, beyond the NDA you usually need to sign to get the register map for the sensor you want to use.

- Andrew (one of the grad students working on the project)

I hear you - we want the same thing. Our target is basically a Nokia N900 (which covers 1, 2, 3, 4 and runs linux to boot), plus a much higher quality sensor and lens.

- Andrew (one of the grad students working on the project).

The existence of prior art doesn't mean we shouldn't try and do it better. There's plenty of related work and similar projects.

We're aware of chdk (and have used it for a bunch of stuff), and it's close in some respects, but it's not the same thing. Chdk doesn't turn your camera into a fully functioning linux box, which is part of what we're trying to do, though this has also been done before sans viewfinder (www.elphel.com). You can plug random stuff in over USB, you can control the sensor with extremely low latency (by hacking the kernel if all else fails), you can ssh in, you could even run a web-server off your camera if you wanted to like the elphel cameras. Last week I plugged an SSD drive in over USB (alas no sata interface yet) to save off raw data faster. It's a fairly standard linux so it just worked.

You also have a lot more compute than you might get in something like chdk. You have access to a unified shader architecture GPU, a DSP, a CPU with an SSE-like vector coprocessor, and a fixed-function set of image processing tools (like histogram generation).

The other half of what we're trying to do is make a really good API for a programmable camera, including stuff for synchronization of multiple external devices (eg flashes), optimized image processing routines, frame-level control of the sensor at high frame rates, and camera user interface stuff, including physical widgets like buttons and dials (we use a phidgets board for this).

- Andrew (One of the grad students working on the frankencamera)

That's exactly right - that way it's free for poor people. As unpopular as it is in the US, redistribution of wealth is a hallmark of civilization worldwide.