Hi David, > I am inclined to deprecate that API entirely and replace it with hooks > for native signal processing.
Can you please elaborate on that? First of all I am using the existing APIs in my app and don't like the idea of things breaking through deprecation of the camera APIs that are in the official SDK 1.0. Secondly, *every* Android API *is* in most if not all cases already a hook to native processing - but a hook that is platform-neutral. I'd really hate to see everything move into JNI for instance, but I hope that is not what you meant. I also don't see how you cannot create a separate camera "heap" (4n MB reserved memory area for an n-megapixel camera) that one could communicate with and get image chunks from through Android APIs that *could* be upward compatible extensions of the existing camera callback APIs (even while these are ugly)? After all, there is no fundamental difference between communicating with a camera and communicating with an external memory block. For image processing purposes, communication can be line-by-line as a good trade- off between speed (a whole image line gets transferred per - slow - Android call), memory needs (never load an entire hi-res snapshot to the app's limited heap) and algorithmic needs (storing a couple of lines within the Android heap suffices for most filtering, feature detection and subsampling operations, although camera API *extensions* that further support this are welcome). Are there any image processing experts involved in the camera API decision making? No offense but the camera API for SDK 1.0 gives me the impression that things were - perhaps due to time pressure - thrown together without *any* background in (real-time) image processing as required for future augmented reality applications and location-based image processing. Regards On Feb 11, 5:27 am, Dave Sparks <davidspa...@android.com> wrote: > Highly unlikely. Applications are restricted to a heap of 16MB. An 8MP > image in RG888 will use 32MB. > > I am inclined to deprecate that API entirely and replace it with hooks > for native signal processing. > > On Feb 10, 6:17 pm, gjs <garyjamessi...@gmail.com> wrote: > > > Hi, > > > I'm hoping that Android will supported this in future for RGB888 and > > (at least) 8mp images. > > > I know this is a big ask, probably requiring much larger process heap > > size ( > 16MB & high speed bus/memory ) but there already is 8mp > > camera phones available on other platforms. > > > And yes I know these phones do not yet support loading such large > > images into (java) application memory but I'm hoping the Android > > architecture can accommodate this in the not to distant future. > > > Regards > > > On Feb 10, 7:01 pm, Dave Sparks <davidspa...@android.com> wrote: > > > > On the G1, no data is returned - only a null pointer. The original > > > intent was to return an uncompressed RGB565 frame, but this proved to > > > be impractical. > > > > On Feb 9, 3:57 pm, Xster <xyxyx...@gmail.com> wrote: > > > > > Hi, > > > > Our university is intending to use the Android as a platform for > > > > mobile image analysis. We're wondering what kind of information is > > > > returned in the raw format when android.hardware.Camera.takePicture() > > > > is called with a raw Camera.PictureCallback. I can't seem to find more > > > > information about it on > > > > thehttp://code.google.com/android/reference/android/hardware/Camera.Pict... > > > > page. > > > > > Thanks, > > > > Xiao --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
