FCam has a seemingly endless TODO list. Some of the big-ticket items are below. You can also help by fixing bugs you find, cleaning up the existing code, or clarifying the documentation. Post suggested patches to any of the above on the FCam forum under open discussion. If you want to add a feature it would be a really good idea to post on the forum first to make sure there isn't already some way to achieve what you want to do.

FCam is already quite Pythonic. For example, the large objects are all reference-counted pointer types. We like Python, and tried to design it with eventual Python bindings in mind. We sadly never got around to it, however. We'd be grateful to anyone who contributes some Python bindings.

While FCam can stream frames at a fixed framerate quite reliably, FCam currently has no clean way to encode and save video to disk. We think one of the example programs should be a demonstration of how to make an FCam program act as a gstreamer source node, to hook into all the existing codecs available there. FCam is good at fine-grain camera control. GStreamer is good at expressing a media pipeline. We think the two should be able to work together well.

Currently the dummy platform inside FCam isn't very useful as a camera simulator. It crudely models a few things like exposure and gain. Adding features like simulated noise and camera shake would be useful.

FCam::saveJPEG is very slow. The demosaicking takes about 800ms, and then the jpeg encode done by libjpeg takes much longer. It shouldn't be taking so long. It would be really nice to get an arm-optimized jpeg encoder in there (perhaps using NEON simd instructions). While you're at it, we don't currently have a loadJPEG method. A fast one would be nice.

There's no support for EXIF metadata in FCAM::saveJPEG either. Adding such support is much-requested, but not straightforward, since it's not directly supported by libjpeg.

FCam is built on top of V4L2, which doesn't handle rapidly varying resolutions. When a Shot with a different resolution to the previous one comes down the pipeline, FCam currently flushes the entire V4L2 pipeline, shuts down and restarts the whole camera subsystem, then starts streaming at the new resolution. This takes a long time (nearly a second), and is the cause of the horrible shutter lag on the N900. A brave kernel hacker may be able to reduce this time by fiddling with the FCam ISP kernel modules and the guts of the FCam library source (primarily Daemon.cpp).

Anyone who solves this one will have our undying gratitude. An ideal solution would be able to insert a 5MP capture into a stream of 640x480 frames running at 30fps, without skipping more than the frame time of the 5MP capture. That is, the viewfinder would effectively stay live while taking a photograph.