Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

techcrunch.com

Post reply on HN
Print view View original

231–240 of 262 posts

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

#231

Post by igravious »

jpap wrote: post #202
svantana wrote: post #196

Earlier quoted context omitted.

SIMD, you say? Are you relying mainly on NEON optimizations or are you also doing encoding stuff on the GPU? Very impressive performance I must say!

Thanks! :-) I first tried using the GPU, using old school GPGPU textures and OpenGL ES 2.0 shaders, but unfortunately the performance wasn't there for a variety of reasons given in [1]. SnappyCam has since been making extensive use of ARM NEON for the JPEG codec and a bunch of other image signal processing operations, like digital zoom. It's a great instruction set! [1] http://www.snappylabs.com/blog/snappycam/2013/0…

Just curious, I know nothing about low level ARM stuff. I was wondering is this iPhone/Apple specific tech or is the work you've done portable to other mobile platforms? Congrats on what you've done. I couldn't quite work out whether you've optimized the hell out of the standard DCT algorithms or whether you've come up with new algorithms. If it's the latter would you be able to publish them or would that give away too much secret sauce? ;-)

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

#232

Post by ajays »

bobbles wrote: post #138

jpap, Could you take the 'trimmed' section and create a looping GIF from that? (Can I do that already?)

The biggest problem with GIFs would be the colorspace: GIFs are usually limited to 256 colors. Color quantization from a JPEG to GIF would kill the photo.

The whole "living image" sounds nice. If it was possible to create a format, say "AJPEG", out of it, it would be awesome.

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

#233

Post by zeroDivisible »

I must say that this is one of the most interesting apps which I had found in last few weeks. You should get yourself a beer as this is a neat feat to accomplish:)

Also, some people were saying that webapp wasn't working for them on some chrome versions. As for me - I've got the 28.0.1500.95 - the culprit was Disconnect extension, which when disabled, allowed the whole application to behave as expected.

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

#235

Post by K2h »

jpap wrote: post #175
venomsnake wrote: post #157

Earlier quoted context omitted.

We should create a "marketing core" term the same way we have marketing HDD size. I have seen big.little advertised as 8 cores. I think the main advantage of the androids will be the fact that high end devices have generally more RAM than iOS counterparts. So even if the codec cannot be pushed as far as on the iOS the bigger possible buffers can help.

Yes, more RAM definitely helps. On SnappyCam, I had to arbitrarily limit the size of the buffer to a fraction of the system memory because there's no way to know "how much" RAM can be allocated to avoid the dreaded memory warnings until you hit one; and then it's a three strike's out policy: you get two and the third kills the app. The first two are "soft" warnings, but I suspect have a lower threshold than the "hard…

is there any value in having buffer size selectable for advanced users so they can play with it and see where the sweet spot is on their hardware?

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

#236

Post by egypturnash »

jpap wrote: post #93
egypturnash wrote: post #90

This is pretty cool. You got my buck! I was kinda hoping I could also turn the speed down to multiple seconds per photo, since it talks about doing time-lapse shots. One of my major uses for my phone's camera is selfies for art reference, currently done with Genius - which annoyingly won't do repeated shots at anything less than 10 seconds. Being able to take one shot every 1-3 seconds would be pretty damn cool for m…

Thanks! You can reduce the capture rate in the app settings, down to 1 photo per {1, 5, 10, 30, ... } seconds. Move the slider toward the turtle under "Camera Lens". jpap

Oh durf, I fail at exploring UIs. Thanks!

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

#237

Post by josh2600 »

jpap wrote: post #166
josh2600 wrote: post #161

Earlier quoted context omitted.

Have you thought about displaying a semi-transparent bar to show the buffer? Or maybe a one or 2 px white mark creeping up the side of the screen (turning to red as it get towards the top)? Just some thoughts. If you have a buffer, and I'm gonna get fubarr'd if I hit the limit, you should probably show me the buffer (not just a warning that it's too late).

Versions 1.x.x of SnappyCam had a linear buffer [1] but I felt it was distracting. I generally can see the "end" of the circular buffer around the shutter button, so it doesn't seem to be an issue for me. Perhaps I tend to touch it on the lower-right instead of dead-center. I made an effort to support lefties in the UI (see Advanced Settings), but the buffer doesn't spin the other way just yet. (To be honest, I've ha…

No, not left handed, but I didn't get the infinite visual cue until you explained it here or the border.

The red bar on the bottom woul probably be fine of you could make it like 70% transparent until it gets toward the end, the vacillate it between 0% and 50% so it looks like its flashing. Some visual indicator that I should be paying more attention to it.

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

#238

Post by Marat_Dukhan »

jpap wrote: post #208
Marat_Dukhan wrote: post #155

Wow, amazing performance tuning, so rare these days! However, you should be careful with this online ARM simulator. It simulates Cortex-A8 while iPhone 5 runs on Apple Swift, two generations ahead. It very likely has different instruction timings compared to Cortex-A8. I didn't have a chance to test Swift, but here is a list of what might be different, judging by Qualcomm Krait and ARM Cortex-A15, which are in the sa…

That's really cool, Marat. Thanks for the additional info on the A15 and Swift. It's a lot of work to optimize the assembly code to each ARM variant, but glad to know that Swift will generally run the same code at the same or faster speeds as the Cortex-A8. The 3-cycle latency on simple ALU instructions is a bummer, but fortunately I use them sparingly for computation as compared to NEON. (They're great for pointer a…

The 3-cycle latency refers to simple NEON ALU instructions (VADD.Ix, VORR, VAND, etc). Scalar ALU instructions are still single-cycle. Note that these numbers are from Cortex-A15 and Krait which are expected to be similar to Swift, but I didn't measure Swift itself to know for sure.

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

#239

Post by nine_k »

igravious wrote: post #231
jpap wrote: post #202

Earlier quoted context omitted.

Thanks! :-) I first tried using the GPU, using old school GPGPU textures and OpenGL ES 2.0 shaders, but unfortunately the performance wasn't there for a variety of reasons given in [1]. SnappyCam has since been making extensive use of ARM NEON for the JPEG codec and a bunch of other image signal processing operations, like digital zoom. It's a great instruction set! [1] http://www.snappylabs.com/blog/snappycam/2013/0…

Just curious, I know nothing about low level ARM stuff. I was wondering is this iPhone/Apple specific tech or is the work you've done portable to other mobile platforms? Congrats on what you've done. I couldn't quite work out whether you've optimized the hell out of the standard DCT algorithms or whether you've come up with new algorithms. If it's the latter would you be able to publish them or would that give away t…

No, NEON is an ARM-specific tech, and is widely available and used e.g. on Android smartphones.

It's like MMX / SSE of x86 world, a set of extra instructions to process many small integers in parallel in one instruction. Since image data are usually independent 3-byte pixels (or 3 planes of 1-byte subpixels, one per color channel), NEON is great for many image-processing tasks.

See e.g. https://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD...

Post reply on HN