Hacker News new | past | comments | ask | show | jobs | submit login

Any chance of this coming to Android soonish? This is seriously cool!



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 "easily" ported to Android by making use the JNI.

While the R&D for the fast JPEG codec took about a year to perfect, the iOS app took just about the same time to get polished (including the NodeJS backend work, the HTML5 website and embeddable widgets in AngularJS).

Writing the rest of the app would take a few months of full time work, and it's not yet clear if that might pay off at this stage.

We'll see... and glad to hear there's interest! :D


Don't overlook the fact that the source for the stock Android camera is available under a commercial-use-friendly open source license and has a quite nice native android UI. You don't have to reinvent all the wheels unless you're stubborn.

https://android.googlesource.com/platform/packages/apps/Came...

I would buy that in a heartbeat.

Unrelated, how quickly can you alter exposure settings? Can you get 30 pictures per second with three interleaved exposure brackets? (i.e. burst of 10 HDR photos / second) That would be very, very, very, very cool.


That's really interesting. I wasn't aware of that. I'll have a look at it once social sharing is out the door.

I did consider getting into other aspects of iPhoneography, like HDR, etc. The trouble with HDR in particular is that there's no API access to direct the sensor into each of the bracketing modes.

In the case of HDR, it might be more fruitful to attempt some kind of image signal processing, similar to "Clarity" on Camera+.

I looked into that for a while, and I figured that Camera+ might be using some version of the Contrast Limited Adaptive Histogram Equalization (CLAHE) algorithm. In any case, what they've done is really neat from a DSP perspective. :D


Hi,

There's also a cool technology allows you to save near the same jpeg with much, much smaller file size.

https://news.ycombinator.com/item?id=2940505


If I was you, if you're unsure it might pay off, I'd go to the phone makers and offer them licenses for just the encoder.


There's similar app on Android for years

https://play.google.com/store/apps/details?id=com.spritefish...

The claimed speed is 30 fps, the moar RAM the better I think.


I thought the app was pretty cool, just super slow to save out the JPEGs.

That's one of the reasons I spent a lot of time to make sure SnappyCam could compress these images, thumbnails and Exif metadata included, at a ridiculous speed.


Yes, SnappyCam has a faster algorithm advantage.

Android on the other hand, has more open and better hardware, e.g. larger full-res camera, much larger RAM, faster external storage or even OTG, more CPU/GPU cores. In theory if SnappyCam is full ported to Android you can make it faster than 8M pixels @ 20fps


The possibilities are exciting for sure! :-)


I might point out that, depending on the device, you could have many more cores to work with in Android-land.


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" one that sends SIGKILL.

In setting the limit arbitrarily, I unfortunately have no choice but to select it rather conservatively: it might otherwise be (a lot?) higher.


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?


Purely wishful thinking: how about this and the latest lumia camera?


I don't know much about their device (maybe Nokia might send me one?!? hehe)...

... but they must have an awesome JPEG encoder. I'd assume 41Mpx stills would need to be compressed in no more than 1 second for a reasonable UX. That there is a 41+Mpx/sec encoder.

I've also noticed they are using higher quality chroma sampling (4:2:2) so their encoder is actually doing a lot more work than say SnappyCam.

But I bet they're not doing it in software, either.


They will send you one if you send them 670 USD back...


I might try to (naively) implement something similar for Android just to see how fast it goes without too much low-level fiddling. It really is pretty darn cool.


Awesome! Drop me a line, would love to see how you go. :-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: