Hi David, OK done, see http://code.google.com/p/android/issues/detail?id=2022
Many thanks ! regards On Feb 14, 4:01 am, Dave Sparks <davidspa...@android.com> wrote: > Some good suggestions. > > Please write up a feature request in the bug tracker. Otherwise I'll > probably never remember how to find this thread and we'll lose track > of these good ideas. > > Just in terms of expectations, advanced features like this are > probably several quarters out. Right now, we're working on improving > the common use cases. However, if there's an opportunity to implement > a feature in such a way that it enables more advanced use cases, I am > definitely in favor of spending the extra time on it, even if we > aren't able to take full advantage of it right away. > > On Feb 12, 2:59 pm, gjs <garyjamessi...@gmail.com> wrote: > > > Hi David, > > > I too would appreciate some of these suggested operations for image > > processing, particularly the arraycopy, xor and shift operations to > > use primarily for image edge detection. Just hope that you can access > > multiple full width 'scan lines' in a random io kind of fashion > > allowing backtracking, no just a single pass over the raw image data, > > which is probably obvious but I will state it anyway. > > > On a different note, could you also consider providing the ability to > > add more sensor details to > > the EXIF data for jpeg camera images. Camera name, picture > > orientation, location > > NET/GPS lat, lon, alt, tod etc is a good first step but I'd also like > > provision for - > > > GPS - bearing, speed & accuracy. > > Orientation - azimuth, pitch roll > > Acceleration - x, y,z > > Magnetic Field - x, y,z > > > - where these sensors are available. > > > As well as some of the standard camera meta data - shutter speed, > > aperture, ISO speed, lens, zoom & flash settings etc ( where available > > ) > > > Ideally I would like to add additional EXIF data to any jpeg image I > > create, no just camera images. And the ability to preserve ( extract > > and re-inject ) EXIF data across JPEG edits. > > > Some of this may conflict with existing EXIF 'standards' and > > limitations ( EXIF data must fit into a single 64k segment for jpeg > > images etc ) so an XMP segment may be more appropriate for some of > > this stuff ? > > > My vision (pun intended) is that panaramio, picasa, google maps and > > others could put some of > > these additional camera image attributes to good use. > > > Thanks for listening. > > > Regards > > > On Feb 13, 4:36 am, blindfold <seeingwithso...@gmail.com> wrote: > > > > Fine! As a comparatively easy to design-and-implement yet very > > > powerful solution to boost the computational performance of Android, > > > you might consider adding a basic vector function API. Think > > > java.lang.System.arraycopy() and java.util.Arrays.fill(), but then > > > much enriched to cover most computational needs in media and signal > > > processing. For instance, array_add(a, b) would add arrays a and b > > > through native code, potentially further exploiting SIMD based > > > hardware acceleration if/once available, making it all nicely future- > > > proof. If the arrays are long enough, say > 100, the overhead of the > > > Android vector function calls over the native code execution times > > > becomes negligible. This approach easily extends to logical operators, > > > say array_xor(a, b), left/right shift operators (needed for > > > convolution type of processing and typical pixel-level image filtering > > > operations involving nearest neighbors within a couple of image > > > lines), multiplication by and addition of scalars, and so on. > > > Importantly, it also to a large extent covers (replaces) the need for > > > costly looping over conditional branches at Android level through the > > > use of mask vectors, as you can find explained in section 2.5 of the > > > online tutorial > > > >http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-do... > > > > An image processing example of how to use vector operators to > > > implement Prewitt or Sobel edge enhancement can be found in Table 1 > > > (p. 30) of > > > > http://wsnl.stanford.edu/papers/icdsc07_mapp.pdf > > > > Having support for a basic set of vector operators may replace a > > > (likely more restrictive) image processing kernel, as well as avoid > > > the alternative of developing a dedicated compiler for a Java language > > > subset (a balancing act with a possible future generic JIT compiler). > > > A first generation implementation - for an early performance boost to > > > Android - can simply be realized by implementing the array operators > > > as for-loops in C code, generating native code from that and linking > > > the object code through JNI (all under the hood, such that the Android > > > application developer never sees any JNI stuff!). For computational > > > work in media and signal processing this will likely give an order of > > > magnitude speed improvement over the Dalvik interpreter, and/or > > > improve battery life because far fewer CPU cycles are spent on a given > > > task. The memory footprint will remain small too because it involves > > > only a small amount of code underneath the API. Later speed > > > optimizations may use platform dependent hand-coded assembly and > > > hardware acceleration. > > > > Any future JIT compiler support in Android would be complementary, by > > > improving efficiency in higher level processing. The vector operators > > > would not become obsolete because a JIT compiler would in all > > > likelihood never reach the efficiency for low level processing > > > obtainable through hand-crafted or even hardware accelerated > > > implementations of the small set of vector operators under the > > > proposed media and signal processing API. > > > > Of course it remains the responsibility of the Android application > > > programmer to make good use of the vector operators to replace the > > > most costly Android for-loops and conditional branches. > > > > Regards > > > > On Feb 12, 5:29 am, Dave Sparks <davidspa...@android.com> wrote: > > > > > I think we'll be able to give you something that will meet your needs. > > > > It's always a balancing act between taking the time to get the API > > > > just right and getting a product to market. > > > > > Keep making suggestions, we are listening. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
