Hi All,

I have done some benchmarking on OMAP4  running Ubuntu for various versions of libjpegs. Benchmarks were collected with modified version of djpeg that prints out ms time taken for decoding. Sample used for benchmarking is a 12MP image downloaded from a photography website. Here are the results:

Non Optimized libjpeg-turbo(5 runs):
     Decoding Time for Run 1: 2022 ms
     Decoding Time for Run 2: 2029 ms
     Decoding Time for Run 3: 2165 ms
     Decoding Time for Run 4: 2027 ms
     Decoding Time for Run 5: 2150 ms
Median Decoding Time: 2029 ms

Linaro's NEON Optimized libjpeg-turbo done in last cycle (5 runs) http://git.linaro.org/gitweb?p=people/mandeep-ti/libjpeg-turbo-1.1.0_linaro.git;a=summary
     Decoding Time for Run 1: 1634 ms
     Decoding Time for Run 2: 1634 ms
     Decoding Time for Run 3: 1636 ms
     Decoding Time for Run 4: 1739 ms
     Decoding Time for Run 5: 1738 ms
Median Decoding Time: 1636 ms

Mans Rullgard's libjpeg based of libjpeg 6b (5 runs) http://git.mansr.com/?p=libjpeg;a=summary
     Decoding Time for Run 1: 1101 ms
     Decoding Time for Run 2: 1081 ms
     Decoding Time for Run 3: 1081 ms
     Decoding Time for Run 4: 1125 ms
     Decoding Time for Run 5: 1089 ms
Median Decoding Time: 1089 ms

libjpeg-turbo trunk version that has NEON patches (5 runs). http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/
     Decoding Time for Run 1: 1068 ms
     Decoding Time for Run 2: 1065 ms
     Decoding Time for Run 3: 1093 ms
     Decoding Time for Run 4: 1066 ms
     Decoding Time for Run 5: 1067 ms
Median Decoding Time: 1067 ms

So basically libjpeg-turbo as of now is pretty much as optimized as anything out there. As a part of my last cycle work I also produced additional color conversion routines that I will submit to libjpeg-turbo project after that libjpeg-turbo should be best library to go (given that it is also highly optimized for Intel processors).

Thanks & Regards,
Mandeep




On 24 June 2011 17:09, Zach Pfeffer <zach.pfeffer@linaro.org> wrote:
We've got a BP for this:

https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-try-libjpeg-turbo

On 23 June 2011 03:30, Alexander Sack <asac@linaro.org> wrote:
> On Thu, Jun 23, 2011 at 3:30 AM, Christian Robottom Reis
> <kiko@linaro.org> wrote:
>> Hi there,
>>
>>    I took a look at the AOSP libjpeg code which is included in
>>
>>         git://android.git.kernel.org/platform/external/jpeg
>>
>> during my flight back home (which incidentally had been diverted and
>> landed me in Rio de Janeiro; not sure if I celebrate or cry) and noted
>> the following things:
>>
>>    - There is a v6 implementation of the fast IDCT algorithm which
>>      lives in armv6_idct.S.
>>
>>    - The commit which adds this implementation was added October 2010,
>>      and there haven't been any changes since.
>>
>>    - The code that selects the decoder IDCT implementation in
>>      jddctmgr.c always uses that implementation if ANDROID_ARMV6_IDCT
>>      is defined.
>>
>>    - Google have an "ashmem" backing store implementation, and have
>>      code to enable tile-based mode. It's a fairly non-intrusive change
>>      to use ashmem since it just replaces jpeg_open_backing_store.
>>
>>    - The code is pretty much standard libjpeg without any structural
>>      changes to it.
>>
>>    - There isn't any NEON code in this branch.
>>
>>    - Mans has an optimized version here:
>>
>>        http://git.mansr.com/?p=libjpeg;a=summary
>>
>>      I don't know if he's submitted this to AOSP or not.
>>
>> This suggests to me that a simple drop-in of libjpeg-turbo might be
>> actually easy to do, and that there is probably a significant
>> performance benefit to be achieved. One thing to keep in mind is that
>> this code still supports armv6, so we'd probably want to preserve that.
>
> sounds good. Seems like a great starter project for MM WG to get their
> hands dirty on android.
>
> They could have three builds:
>
>  1. plain LEB
>  2. LEB with mans optimized libjpeg
>  3. LEB with libjpeg-turbo
>
> Then benchmark all three and keep AOSP community posted on our intent,
> progress and results.
>
> --
>
>  - Alexander
>