[sldev] OpenJPEG usuable now

Rob Lanphier robla at lindenlab.com
Fri Feb 9 17:27:14 PST 2007


Wow, very cool!  We're really looking forward to seeing this work progress.

Rob

On 2/8/07 11:35 PM, David Fries wrote:
> I'm a bit excited.
>
> I have some patches that I'm working on, but I was just able to fly a
> loop around a three region area just now with them and it seemed
> comparable to the binary client.  This is with OpenJPEG and the first
> look source client on a Linux dual core 64 bit AMD machine.  Good
> enough that I'm going to have to fly around it again with the binary
> version and compare.  Any suggestions on how to compare the
> performance between them?  My qualitative experience tonight says that
> it is good enough to run with.  Up until tonight it was like pulling
> teeth using OpenJPEG, so bad, now it looks good.
>
> I hacked OpenJPEG to have an opj_meta_decode that would only decode
> enough to get the size and number of channels.  That's all getMetadata
> used anyway.  That patch needs to be cleaned up and submitted to
> OpenJPEG.  But here are the results.
>
> A full decode can take anywhere on the order of .015 to .5 seconds
> (though I've seen 1.5 seconds before).  Currently Second Life does a
> full decode, saves the image size and channels, then tosses the image.
> This OpenJPEG meta decode just gets enough header decoded to get at
> the image sizes, and it AVERAGED at .000076 seconds that's with 6200
> samples and all but two under 1 millisecond.  That's a total of .474
> seconds spent in OpenJPEG getMetadata decode, or about the time it
> takes to decode a large image.
>
> There is a function, LLImageJ2C::validate that calls
> mImpl->getMetadata in llimage/llimagej2c.cpp, my question is how much
> validation is required to be done to the image?  I only see that
> function being called by LLViewerImageList::createUploadFile.
> Seriously though, does it just need to find out if it has a jpeg
> header without looking at any data?  In that case the meta decode
> should work.
>
> The last piece of the puzzle was based on a patch on jira by Hiro
> Sommambulist, VWR-66.  Without that patch textures decoded at say a
> 1/8 resolution would only take up 1/8 of the size leaving the rest
> blank and grow from there until it was fully decoded.  Some of his
> math didn't make sense to me, but it was enough to point me in the
> right direction.  I have some cleanup work to do on that patch as
> well.
>
> Of course it wouldn't have been possible without the first look viewer
> FL-1.13.3.57679 doing the actual jpeg2000 decoding in another thread.
> I wasn't going to go as far as time slicing the decoding like the
> proprietary decoder does.
>
> In my previous e-mail where things were still gray after an hour at
> the International Spaceflight Museum?  It was good in under a minute.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev
>   


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070209/b3ebff9a/signature.pgp


More information about the SLDev mailing list