[sldev] Jpeg2000 codec optimization

[bushing Spatula]

On Thu, 18 Jan 2007 03:48:05 +0100, "Stefan Westerfeld"
<stefan at space.twc.de> said:

> I wanted to have a look into the jpeg2000 thing. Now, my first thoughts
> were something along the lines that I could identify one or two
> functions in the image decoder that produce the main performance issues,
> understand what they do, and replace them (possibly using special multi
> media instructions like SSE). It should have been a small fun hacking
> thing, which could be completed in a reasonable time frame... but so far
> I failed, because it is not that simple.

Unfortunately, you're right. :(

Analysis on OSX/PPC showed:

- 27.1% dwt_decode_1_real (OpenJPEG)
- 22.9% tcd_decode_tile (OpenJPEG)
- 5.6% t1_dec_sigpass_step (OpenJPEG)
- 5.4% t1_decode_cblks (OpenJPEG)
- 5.4% t1_dec_refpass_step (OpenJPEG)
- 4.7% mqc_decode (OpenJPEG)

tcd_decode_tile is really just a call to dwt_decode_real, so half of the
time is spent in dwt_decode_real and dwt_decode_1_real. *(but see below)

 
> So here is what I did figure out so far:
> 
> * SIMD could be helpful

Kakadu uses hand-coded asm routines for its transforms, yup.

> * the Jpeg2000 standard is huge, so I suggest optimizing a special case
> 
> I read some of the "official" Jpeg2000 info, and that thing can do a
> lot. My opinion is that it is probably impossible to just speed things
> up by optimizing "the library that decodes". Rather it will only be
> possible to take those cases that typically occur, and optimize these.

Perhaps -- we have to make sure to maintain compatibility with all of
the textures that have already been uploaded to SL.  

> What would be ideal is a if there would be two things:
>  - one (or a few) sample image that are typical for what needs to be
>    decoded

I can provide as many as you'd like, that part's easy! :)  I attached a
small one, to get you started.

>  - a standalone test app that decodes, measures performance and compares
>    the expected result with the actual result (this would help to see
>    if a certain optimiyation step messed up the decoder)

The first part is fairly easy.  Each of the libraries comes with a
sample encoder / decoder program.
OpenJPEG: http://www.openjpeg.org/index.php?menu=download
GeoJasPer: http://www.dimin.net/software/geojasper/    (Development has
stagnated on JasPer; GeoJasPer is the currently active fork.)
Kakadu: There are some OSX binaries here, as well as a very exhaustive
comparison between GeoJasPer and Kakadu.
http://homepage.mac.com/gregcoats/jp2.html

Here's how to run each program: (note that you have to rename the input
file)
OpenJPEG: openjpeg-dec -i foo.j2k -o foo.bmp  (0.051 sec)
GeoJasPer: geojasper -f foo.jp2 -F foo.bmp (0.074 sec)
Kakadu:  kdu_expand -i foo.j2c -o foo.bmp (0.025 sec)

This is not the world's most scientific comparison -- one image at a
time, and who knows if it's representative.  I ran each program over 129
images, and got these numbers on my 2GHz PPC G5:

OpenJpeg: 1 min 25 sec
GeoJasPer: 1 min 34 sec
Kakadu: 19 sec (!)

... your results may vary, especially on an Intel box.

(Did I mention that OS X 10.4+ comes with a licensed version of Kakadu
inside CoreGraphics?  see
http://wilshipley.com/blog/2005/09/jpeg2000-cool-but-slow.html and
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_images/chapter_12_section_3.html)

-b

-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.j2c
Type: application/octet-stream
Size: 24398 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070118/767c53c3/foo-0001.obj