Scientific Breakthrough Lets SnappyCam App Take 20 Full-Res Photos Per Second

Post by Hopka » Thu, Aug 01, 2013, 12:01 PM UTC

jpap wrote: post #190

Hopka wrote: post #187

It crashes for me every time I take somewhere between 60 and 75 frames with the main camera. With the front-facing camera, I can shoot forever. In the iPhone Settings (somewhere called Diagnosis & Usage), I have a bunch of LowMemory warnings. I'm using an iPhone 4S.

Thanks for reporting it in! It seems I enthusiastically chose a larger buffer size that appears to be having some issues on some devices that have a lot of memory pressure. If you reboot your phone, as awful as that sounds, it will likely fix the issue. EDIT: I've just submitted an update to Apple that uses a more conservative buffer size. This aspect is hard to get right: I once used an adaptive buffer size that hee…

Post by runn1ng » Thu, Aug 01, 2013, 12:11 PM UTC

bulte-rs wrote: post #220

runn1ng wrote: post #219

WHY DONT YOU CURE CANCER INSTEAD

Actually, cancer research can benefit (admittedly by a long shot, but still) by these kind of improvements in image processing. Don't forget that medical imaging and - thereby indirectly - the recognition/detection of cancer is one of the first steps in curing said disease.

Post by mansr » Thu, Aug 01, 2013, 12:24 PM UTC

jpap wrote: post #48

mappu wrote: post #45

That's fantastic, and a very cool demo. How does the encoder performance compare to libjpeg-turbo? That also has some SIMD work for NEON.

Yes, Nokia contributed the NEON code for the DCT in libjpeg-turbo. I haven't had a chance to do a side-by-side comparison as yet, but I suspect the SnappyCam encoder is faster for many reasons, including choice of algorithm and the way they use two multiplies (low, high) at times, and their image row-by-row nature with function call overhead in favour of code maintainability.

Post by mansr » Thu, Aug 01, 2013, 12:50 PM UTC

jpap wrote: post #16

revelation wrote: post #11

DCT is already lossy [1], so the statements around 8 megapixels are completely pointless, and worst of all, its 1990 lossy technology. Wavelet transformations completely destroy any DCT. That said, if their emphasis is on producing pictures with minimal time delta at highest resolution, algorithms used for still pictures are out of place. Video compression algorithms still use DCT and wavelets, but they do so only af…

You are right on the loss: it's purposefully introduced as a quantization step after performing the DCT, and before losslessly compressing the resulting coefficients with Huffman and encoding to the final JPEG bitstream. Despite all of that, JPEG has now become computationally tractable. I remember the days where it took tens of seconds to encode a JPEG on a commodity machine. Now, with the help of SIMD, we can encod…

Post by jpap » Thu, Aug 01, 2013, 1:07 PM UTC

bulte-rs wrote: post #220

runn1ng wrote: post #219

WHY DONT YOU CURE CANCER INSTEAD

Actually, cancer research can benefit (admittedly by a long shot, but still) by these kind of improvements in image processing. Don't forget that medical imaging and - thereby indirectly - the recognition/detection of cancer is one of the first steps in curing said disease.