I'm interested to know how their method compares to how dedicated digital cameras and DSLRs do it? are cameras running dedicated hardware/firmware to achieve the same result? Or have they optimised their software in the same way that SnappyCam has done it?
I can't say, as SnappyCam is my first foray into image signal processing. (Though DSP isn't new to me.)
I'd guess that DSLRs use a combination of hardware acceleration on the "tricky" bits (like DCT) with firmware to control the compute hardware.
Huffman is a particularly difficult beast, as it can't be parallelized. The JPEG bitstream is inherently serial, though there has been some proposals to improve that.
If you run a SnappyCam JPEG that you pluck from iTunes File Sharing through djpeg (from libJpeg) you will notice that each of the YCbCr planes are not interleaved.
I once experimented with a parallel JPEG encoder, encoding the Y, Cb, and Cr planes in parallel but the threading overhead was more than just queuing up each JPEG encode separately in a multithread queue.
Bonus points if you notice another marker in the JPEG. That's intended for parallel JPEG decoding but hasn't yet been implemented in SnappyCam as yet. (The existing decoder is fast enough for 8Mpx shots.)
When you read about 'DIGIC', 'BIONZ', or 'EXPEED' in dedicated digital cameras, you're on the spot with custom processors. (In some cases, more than one) They're often multi-chip modules that can be scaled depending on the level of camera and can be based on standard SoC or embedded macros.
On top of that, you'll have the 'firmware', which is where projects such as Magic Lantern/CHDK make things fun.
