Free jpeg2000 libraries? #14
Comments
|
Hello ruven, You said here ( http://iipimage.sourceforge.net/2011/04/iipimage-0-9-9-server-release/ ) than "a fully open source implementation based on openJPEG will be included in the next server release". Is it still your goal ? |
Thanks!
I'm afraid it won't make it into this coming version 1.0, but will definitely be in version 1.1. |
|
Ok. Thanks for your reply. :-) |
|
If someone can point me to the right part of the codebase to integrate these libraries, I would be happy to begin working on a branch to support this goal for the 1.1 release. I also know a number of others who would be interested in this as a technical challenge, both simply integrating the components, and in improving the components themselves (adding gpu support to openJpeg for instance) to bring them up to a superior level when compared with Kakadu. |
|
It seems that @boskar might have some specific ideas as to where to start. |
|
There are efforts underway by the Wellcome Library to get openJPEG up to par with Kakadu. See: |
|
Well, We should obviously start here: https://github.com/moravianlibrary/iipsrv-openjpeg and see how good it is at the moment. I suppose there is no other way that reading the code referencing to kakadu and finding equivalents in chosen library... http://apps.man.poznan.pl/trac/jpeg2k/wiki does not seem to have library as is, although the encoder/decoder works (tested today). Maybe we should cooperate with the authors about integration? cuj2k - site does not work due to SF being down. On the other hand: there seems to be another alternative (paid): |
|
I haven't tested it myself, but the openjpeg branch you cite is reportedly around 1000x slower than Kakadu. However, as pointed out by @ahankinson there's work under way to optimize openjpeg, so it may become competitive speed-wise in the not too distant future. So, if you're looking for a technical challenge, helping to add SIMD or GPU support to openjpeg could be both very interesting and very useful! |
|
https://github.com/stweil/iipsrv/tree/openjpeg-api-fixed is based on https://github.com/moravianlibrary/iipsrv-openjpeg, but fixed for latest OpenJPEG. I could process a JP2 file with it, but also observed program crashes. https://github.com/stweil/iipsrv/tree/openjpeg is a branch which merged latest iipsrv. It still needs some API fixes. |
|
https://github.com/stweil/iipsrv/tree/openjpeg now works with OpenJPEG. It takes a lot of time: PalaisDuLouvre.jp2 (made from PalaisDuLouvre.tif) needs 27 s on my Intel Core i7 notebook. iipsrv calculates 63 tiles, each of them taking about 0.4 s. If it would use all CPU cores of my notebook (as Kakadu does), the total time could be reduced from 27 s to 7 s. With Kakadu, iipsrv does not calculate any tiles at all and delivers the same PalaisDuLouvre.jp2 as a JPEG image in 0.26 s. That is about 100 times as fast as OpenJPEG (not 1000 as it was reported by others). For PalaisDuLouvre.tif, iipsrv calculates 223 tiles in 0.125 s. |
|
Have You tried using multiple instances of iipsrv? It could be a way to parallelize the work... |
|
@boskar: IMHO that would parallelize the work if there are several parallel requests, but not for each individual request... |
|
@stweil Sure, You're right. But who needs a single tile? I suppose the client does not download them in row. |
|
@ruven, are you interested in pull requests to get the OpenJPEG support added? The new code is clearly separated from the Kakadu code and could be disabled by default, so the risk would be low. |
|
I'm preparing things for the 1.0 release, so let's wait until that's out of the way, then I'll be happy to accept a pull request. |
|
Would it be useful to open a pull request with the understanding that it won't be merged until after 1.0? |
|
You could do, but any pull will probably be easier if it's based on the final 1.0 code |
|
It's possible to keep a PR up to date with frequent merges from master, so that the accepted PR applies cleanly to the latest revisions. That depends, of course, on the maintainer of the PR staying on top of it. :) |
|
I just provided PR #61 for anybody interested in trying OpenJPEG support. This PR will be rebased and updated as needed. |
|
The bad performance of iipsrv with OpenJPEG is mainly caused by the missing support for regionDecoding in the current code: while Kakadu requests the region directly from the JP2 image, OpenJPEG uses the TileManager to calculate a lot of tiles (several hundreds or more for large images), so the time factor of 100 or 1000 is not surprising – the factor will increase with the image size. |
|
Not sure what the current state of openjpeg support is with IIP master, but I am retrofitting IIP to embed ICC profiles from the source files into the JPEGs that IIP generates. However, it seems that only one region from the source image is currently being extracted. See the screenshot below. This was found using one of the Wellcome Library's JP2 images and IIP on RedHat EL6 with openjpeg2-2.1.0-7.el6.x86_64 and openjpeg2-devel-2.1.0-7.el6.x86_64 from the EPEL repository and with IIP compiled using configure --enable-openjpeg.
|
|
I think that the status is still experimental. Nevertheless the effect which you observe looks strange. Perhaps you can try to debug it, for example have a look into the server log output. |
|
Yeah, maybe in my free time :) For now, I'm going to ensure the ICC gets embedded in the resulting image and move on. |
|
Is this issue still open, or can it be closed? |
Kakadu - yeah, it's probably nice, but it's non-free. We've got some free jpeg2000 libraries.
Some of them are GPU based - as iipsrv is oriented for performance ( comparing to python or java-based image servers ) It'd be very nice to support them as an option.
We've got:
CUDA: http://apps.man.poznan.pl/trac/jpeg2k/wiki
CUDA: http://cuj2k.sourceforge.net/
CPU: http://www.openjpeg.org/
The text was updated successfully, but these errors were encountered: