Hello,
>> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
>> images, after a short test with openjpeg2000 from EPFL we have tested
>> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
>> of work too, but this is a lil question... anybody here around never
>> tried it as alternative to OpenJPEG/KDU in a viewer?
>I'm not aware of anyone publishing results for such a test, but if you
>have the time it would be interesting reading.
You might be interested in:
http://bitbucket.org/NickyD/viewer-development/changeset/027bf44c5582
I made a rather quick hack to try Jasper instead of OpenJpeg to decode
images.
The patch has some very rough edges. In fact is the decoding into the
LLImageRaw buffer not correct.
I did not fix this (yet) because the results so far are not very promising.
Jasper can only decode around 20% of the jpeg, for the other 80% it will
create an error and then my code falls back to OpenJpeg.
This fallback makes the whole decoding rather slow, so it is hard to say
if Jasper would really be any faster.
Right now I am not sure if it would be reasonable to invest more time
looking at Jasper. First the code would need to fixed upstream, so all
images can be properly decoded. As this project looks rather dead, one
with JPEG2000 knowledge might have to step up for this.
On another note, you might like to try:
http://bitbucket.org/NickyD/viewer-development/changeset/e4eff3e2af39
This will at least skip the step of calling OpenJpeg in
LImageJ2COJ::getMetadata (if possible, it will do sanity checks first).
>Some things to keep in
>mind. OpenJpeg has patches floating around on its ML against 1.3 that
>reports have claimed up to 40% speed increase in places due to
>unrolling the inner loops so finding them and testing would be good.
I did not find any of those, but then again maybe I did not look hard
enough.
There is certainly some potential in OpenJpeg.
There are some loops in t1_dec_sigpass and t1_dec_refpass that can be
easily rewritten. But there is some pretty tricky stuff in t1_dec_clnpass
that would need some cleaning and mqc decoder (mqc_decode) burns a lot
of time. But that one is especially hairy as it has side effects on its
input parameter.
I am not sure if anyone without enough deep knowledge of OpenJpeg (and
the dedication to recode a good part of it) would be able to improve
much of it.
Cheers,
Nicky
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
