Hi Tom, It does indeed seem like we're in the same situation.
I'm going to play around some more with the position, size and visibility of my PUSH_BUFFERS surface to see what works best. All in all though, I completely agree with your conclusion...this is a hack, and there's no telling how long it will work. I also agree with your point about the mysterious Camera API, here are my main gripes: 1. There's a callback for receiving viewfinder data, but it never occurred to the designer that 3rd parties might want to use that _instead_ of letting the framework draw it directly to a surface. 2. The callback for viewfinder data only let's you receive YUV data. This is good from a performance perspective as it comes directly from the camera, but IMHO causes the following issues: a) The YUV format is dependent on the sensor/vendor hardware. Yes, there is an API to query the format, but considering the not so stellar qualcomm driver implementation for HTC, this may not be trustworthy. b) 3rd parties wishing to use viewfinder data will have to be able to decode all forms of YUV data in order to be safe on future devices, assuming that the API mentioned in the point above is trustworthy. c) The requirement to decode the YUV raises the bar quite a bit for 3rd party developers who might have ideas in this field. Thus, it would seem reasonable to provide an option to receive the data in either YUV or RGB format. Unfortunately, even if the API's are modified in a future release we will be stuck with maintaining different code for different releases and/or OEMs... regards Anders On Oct 1, 1:51 pm, Tom Gibara <m...@tomgibara.com> wrote: > If I understand correctly, you're doing something very similar to what I'm > doing in my Moseycode application. In my case I render the camera YUV data > via a GLSurfaceView. > I can't say whether this will work for certain on all/any 1.6 devices, but > my approach since 1.5 has been to make the PUSH_BUFFERS surface very small > and to position it off-screen (a nasty hack that works in the emulator at > least). I think the smallest supported dimensions that preserve the aspect > ratio are 20px x 15px. > > That said, I'm just waiting for this circuitous implementation to blow-up on > me. Why the camera demands a surface in order to provide preview data is a > mystery to me (as is so much of the Camera API's operation). > > Tom > > 2009/10/1 Anders Johansson <svi...@gmail.com> > > > > > > > Hi all, > > > My company has so far developed four different camera-based > > applications that all work by manipulating the viewfinder feed from > > the camera. The Android camera API expects a Surface to draw the > > viewfinder feed to, however in our apps we rely on sidestepping the > > direct drawing and grabbing the YUV_420_SP data for manipulation and > > rendering to a Surface. > > > On 1.5, we achieved this by changing the Surface type from > > PUSH_BUFFERS to NORMAL, which would in one stroke disable the direct > > feed to the surface from the camera as well as giving us a Surface > > onto which we could render the manipulated feed. > > > The problem arises when upgrading to 1.6, as it appears that this > > "hole" has been plugged. The Camera class now refuses to start the > > preview feed if its associated preview display surface is of the wrong > > type (such as NORMAL). I realize that this is probably correct as per > > design, unfortunately it also makes our type of app very difficult to > > implement... > > > I have tried to work around it by creating a dummy surface view to set > > as preview display, and although I have managed to hide it, I haven't > > been able to stop the direct feed, which of course means that > > performance slows to a crawl as both the direct feed and manipulated > > feed are active and drawing at the same time. > > > I would be most grateful for any suggestions on how to resolve this > > issue... > > > best regards > > Anders Johansson > > -- > Tom Gibara > email: m...@tomgibara.com > web:http://www.tomgibara.com > blog:http://blog.tomgibara.com > twitter: tomgibara --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
