Issue 238 in webp: WebP JNI Wrapper for Advanced API

[we...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 238 by Sajjad.J...@gmail.com: WebP JNI Wrapper for Advanced API
https://code.google.com/p/webp/issues/detail?id=238

I have seen a Swig file for the simple API, but there isn't a JNI wrapper
for the Advanced API. It would be very helpful to include this especially
for folks who want to integrate the library into Android.

As you know, WebP is supported in Android starting from version 4.0;
however, transparency is not supported until after version 4.2.1. This
means that about 34% of Android devices can not decode WebP with
transparency. Also, with the simple API, we can't perform scaled decoding,
which is a must on Android. This makes the need for the Advanced APIs
support on Android even more.

Are there any plans to implement this, and is there a timeline that you can
share? We're planning on integrating webp into our app and would like to
take advantage of the Advanced API.

Thanks!


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[we...@googlecode.com]

Comment #1 on issue 238 by jz...@google.com: WebP JNI Wrapper for Advanced
API
https://code.google.com/p/webp/issues/detail?id=238

Hi,

There's no work being on this currently. Would the imageio plugin [1] work?

[1] https://bitbucket.org/luciad/webp-imageio

[we...@googlecode.com]

Comment #2 on issue 238 by thorh...@gmail.com: WebP JNI Wrapper for
Advanced API
https://code.google.com/p/webp/issues/detail?id=238

"WebP decoding supports an advanced API to provide ability to have
on-the-fly cropping and rescaling, something of great usefulness on
memory-constrained environments like mobile phones." -- WebP API
Documentation

As Google is targeting this usage scenario, it is only fair to expect that
Google should provide access to its Advanced API in what is ostensibly the
language binding of WebP for Google-powered mobile phones. The omission of
such a binding is somewhat embarrassing seen in this light.

[we...@googlecode.com]

Comment #3 on issue 238 by pepijn.v...@luciad.com: WebP JNI Wrapper for
Advanced API
https://code.google.com/p/webp/issues/detail?id=238

ImageIO plugin author here. That won't work on Android since it's tied to
javax.imageio which isn't available on Android. If there's sufficient
interest, I can make the core WebP interface part JavaSE/Android
independent so it can be used on both platforms.

[we...@googlecode.com]

Comment #4 on issue 238 by Sajjad.J...@gmail.com: WebP JNI Wrapper for
Advanced API
https://code.google.com/p/webp/issues/detail?id=238

@pepijn.v...@luciad.com, we're definitely interested, and I've seen others
who are interested in back porting webp to earlier versions of Android. For
example, https://github.com/mreichelt/webp-android-backport-library is an
attempt to back port but that only uses the Simple API, which isn't ideal.
Having an independent interface will be great!

I also wanted to mention that, although we're not experienced in this area,
we can help out with development of the interface. We'd need some guidance
on how to approach it and probably a pair of eyes to review it. Let me know
if this works.

Thanks!

[we...@googlecode.com]

Comment #5 on issue 238 by pepijn.v...@luciad.com: WebP JNI Wrapper for
Advanced API
https://code.google.com/p/webp/issues/detail?id=238

https://bitbucket.org/luciad/webp-imageio/commits/fa68e79f784b7e1bc6b957cb2ed8d486d31c08d7
splits off the Java SE dependent parts and adds a really basic Android
compatible wrapper. All the libwebp encoder/decoder options are exposed via
the WebPEncoder/DecoderOptions classes. These aren't documented yet, but
the naming and semantics are identical to what you can find in the libwep's
webp.h header.


I haven't had time to create an Android.mk script for the native library
yet, nor for the jar file. Contributions always welcome of course.

The Android code also hasn't been optimized yet at all (there's a lot of
needless memcpy'ing going on) and I haven't had a chance to test this yet
either. Really a work-in-progress in other words intended to solicit
feedback.