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 -~----------~----~----~----~------~----~------~--~---
