I worked on camera drivers for mobile phone SoCs 5 years ago. Back then a strong constraint that separated "video" from "picture" was that we didn't have enough memory bandwidth to stream uncompressed "picture"-sized frames at "video" framerate.
Google's Camera2 API no longer presents that distinction.
Funny how things change, that's my personal experience with Moore's law.
Another problem we had is that we'd developed flexible OpenMAX-compliant modules to expose the hardware's capabilities, following Nokia's requirements. We tried pushing those to Google whose APIs back then were much more limited. They (as far as I knew back then) didn't care.
Yes with devices implementing fully Camera2, the rule is that you can stream full resolution sensor data to buffers that you can capture and save either for processing (like HDR & superresolution) or video recording :)
At that time, was the viewfinder preview built on full sensor readout or line-skipped/binned sensor readout?
Yes, the new API makes much more sense. I'm just surprised and a bit disappointed it took so long to come about :(. I was always disappointed by the capabilities of production phones compared to what we could do in dev, but of course, in dev we didn't have all the constraints of running alongside the rest of the OS and only using the vendor's APIs!
As for your question, I'm rusty on the details. I definitely remember binning was used for some use-cases. For viewfinder, our hardware pipeline would generate a lower-resolution stream from the full-resolution stream used for encoding.
Yes and one reason it took so much time might be the same reason why there's the risk Camera2 might stay a Nexus-only thing.
Manufacturers like keeping camera features, UI and processing exclusive to their devices, which is one thing encourages brand loyalty.
The most users will rely on a favorite third party app, the more likely they might switch to another brand on their next device.
Sony's updating their Xperia phones to Lolipop starting today, but with none of the Camera2 features. Just the same magical DRM-locked noise reduction and everything that breaks if you unlock the bootloader, and makes low-light photos look like shit in any 3rd party camera app.
Seemed like a good idea at the time... And there's all of 3 phones to choose from if you don't want a huge screen. Love the battery life, but unless you're in broad daylight it takes worse pictures than my 4S did.
As a minor correction, the N5 front camera is a LIMITED, not a LEGACY device.
It doesn't quite do the per-frame synchronized controls required for FULL like the main back-facing camera, but otherwise offers manual control and high-speed output.
That's absolutely correct, thank you for the correction :)
It's still LIMITED on 5.1, however it's possible to control ISO, white balance, shutter speed, set a custom color space conversion matrix which allows a lot of cool things for a font camera.
Kind of a shame none of the OEMs are picking up the API. Google really should have worked with Intel/Qualcomm/etc. to come up with something that the parts vendors were willing to support. The API really seems dead in the water as is.
It is a hard problem. When I worked at an OEM these were the same companies that were constantly making kernel source releases nearly impossible with strict licensed binary blobs for their parts, like Bluetooth modules. Not really unexpected that Google came up with an API and they ignored it.
Google's Camera2 API no longer presents that distinction.
Funny how things change, that's my personal experience with Moore's law.
Another problem we had is that we'd developed flexible OpenMAX-compliant modules to expose the hardware's capabilities, following Nokia's requirements. We tried pushing those to Google whose APIs back then were much more limited. They (as far as I knew back then) didn't care.
Again, funny how things change...