[sldev] Optimizing OpenJPEG (oprofile kicks ass)

Francois-Olivier Devaux fodprolux at gmail.com
Thu Mar 29 23:37:03 PDT 2007


Hi,

At OpenJPEG, we're following quite closely the optimizations suggested here
at sldev, and including the ones that respect the standard (and thus the
patents).

Indeed, some optimizations might work quite well with the (current) format
of the SL JPEG 2000 codestreams, but might not be as great for more
complicated codestreams use in other applications like medical, geospatial,
... imaging or DCinema.
But don't worry, we're checking all that.

We'll release new versions as soon as we fell that the optimizations are
significant (or useful; remember that v 1.1.1 was released to include
partial decoding useful directly for SL - and indirectly for all OpenJPEG
users). That will hopefully be more often that every 15 month !

As in the OpenJPEG team, we are mostly "signal processing engineers" (we
work in a Signal Processing laboratory) and not "computer engineers", we're
very happy to receive all these suggestions of optimizations.

The most efficient way of working is to wait until you have a stable version
of your optimizations, and then submit patches to the OpenJPEG discussion
group (http://groups.google.com/group/openjpeg ), or on the SL wiki
dedicated to this https://wiki.secondlife.com/wiki/Openjpeg_improvements.

Like Jesse Nesbitt just said "Anything that helps SL with OpenJPEG will help
other people with openjpeg".

Cheers,

François-Olivier

Note: A new version of OpenJPEG will be released in a couple of weeks to
include stuff related to Digital Cinema we've been working on... and
hopefully including that memset() optimization suggested here, and more if
you're good at patching ;-)

On 3/29/07, Jesse Nesbitt <mindtriggerz at gmail.com> wrote:
>
>
> And bonus points to OpenSL for upstream contributions.
> Anything that helps SL with OpenJPEG will help other people with openjpeg
>
> On 3/29/07, Callum Lerwick <seg at haxxed.com> wrote:
>
> >  On Thu, 2007-03-29 at 12:29 -0700, John Hurliman wrote:
> > > Jason Giglio wrote:
> > > > Stefan Westerfeld wrote:
> > > >>> doing my math right. Christ. So, I'm looking in to making them
> > > >>> dynamically allocated, I don't see slviewer ever using more than
> > 64x64
> > > >>> (33kb!).
> > > >
> > > > Be careful.  There's two good reasons not to code SL specific
> > > > optimizations into openjpeg.
> > > >
> > > > 1.  They won't be accepted upstream.  That means constant
> > > > merging/backporting.
> >
> > This isn't at all SL specific. This is simply straightforward cleanup of
> > some awful code...
> >
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> > /index.html
> >
> >
> >
>
>
> --
> --Jesse
>
> --
> --Jesse
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070330/a98a632a/attachment-0001.htm


More information about the SLDev mailing list