jpap

8 ms·

91.
by jpap 13y ago
Thanks! I just hope Apple's engineers don't get pissed off by the press. SnappyCam is built on their hardware, which can do remarkable things. Though we as app developers don't get access to a lot of their smarts, e.g. hardw
92.
by jpap 13y ago
Thanks! :D I'm just very happy to have more people try the app. It's been a hard slog working 7 day weeks for just over two years now. Feels great to receive some kind of recognition for the work.
93.
by jpap 13y ago
Oh, I actually do both---see the other thread on the topic. I buffer as much as possible, while also encoding on any other cores that are available. There's a reason why a "simple camera app" can total some 80 kLOC. :)
94.
by jpap 13y ago
Nice find! It's going to form part of the Facebook Timeline integration that's coming soon... as well as embeds, though Josh already linked to the "press samples" page in the article. :-)
95.
by jpap 13y ago
Actually, I do both on dual core devices. One core is dedicated to host the capture/buffer, the other will encode shots in the background. When you see the big circle percent animation, both cores are dedicated to compression to clear
96.
by jpap 13y ago
I'd love to disclose the implementation details, and even release it on GitHub, but unfortunately I have to keep it as a trade secret for obvious reasons. Perhaps one day! :D It was a tonne of work that I'd love for fellow engine
97.
by jpap 13y ago
1. Instragram is only shown if you actually have Instagram installed on your device. ;-) As you might know, Instagram guard their API carefully: we don't yet have general access to it. 2. E-Mail is also only shown if your device has b
98.
by jpap 13y ago
Don't forget that SnappyCam pumps both CPU cores when available. The actual DCT algorithm created and used in the app is different to the typical AAN (Arai, Agui, Nakajima) DCT algorithm that's used in JPEG codecs, at least all th
99.
by jpap 13y ago
Hey, thanks! The Australian Communications Theory Workshop was such a long time ago--what great memories. :-) What are you up to these days?
100.
by jpap 13y ago
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
101.
by jpap 13y ago
That's a really interesting machine vision problem and a lot more complex than a JPEG codec. :-) I wonder how long before we start to see Kinect-like infrared cameras mounted on phones to make the depth problem easier to solve. That
102.
by jpap 13y ago
The fast JPEG codec was written for the ARM NEON SIMD coprocessor found in the iPhone. Most Android devices also sport the same architecture, so it is indeed possible. The code for the codec is written in mixed C and assembly, so it can be
103.
by jpap 13y ago
I've given a bit more background to the fast JPEG codec on my engineering blog: http://www.snappylabs.com/blog/snappycam/2013/07/31/iphone-k... If you like signal processing, fixed point arithm
104.
IPhone is King of Speed - SnappyCam unlocks 20 pictures/sec at 8 Mpx(snappylabs.com)
17 points by jpap 13y ago|0 comments
105.
Templating your Jekyll Blog with Jade(snappylabs.com)
2 points by jpap 13y ago|0 comments