[sldev] OpenJPEG usuable now
david at fries.net
Thu Feb 8 23:35:01 PST 2007
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
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
Of course it wouldn't have been possible without the first look viewer
FL-184.108.40.206679 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.
David Fries <david at fries.net>
http://fries.net/~david/ (PGP encryption key available)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070209/8453d14f/attachment.pgp
More information about the SLDev