Read JP2 with Jasper driver excrutiatingly slow

[kyngchaos@…]

Reading a JP2 with the JasPer driver is extremely slow. Wrting JP2 with JasPer works fine. A 5000x5000 pixel color JP2 (lossless) takes over 5 minutes to tick over the progress meter.

As a comparison, reading the same JP2 with the MrSID JP2 driver takes 1.3 minutes for the full image. Outsides of GDAL, with the jasper program (same jasper libraries that GDAL uses), it takes 30 sec to read the full image.

There is nothing in the console log to indicate a problem. It passes the gdalautotests, but those are small files so the speed problem is not noticable.

GDAL 1.3.2

[arturr]

can jasper be exchanged into geojasper(much faster and uses less memory)?

[warmerdam]

Andrey,

Any thoughts? I'm not clear on why geojasper would be any faster - perhaps arturr can expand on this.

[dron]

Actually I have no idea how to improve this driver without improving JasPer library. Regarding the original report I think that the problem is in block reading interface: we are reading 256x256 blocks from the image (I have no idea how to choose most optimal block size, so it is 256x256) and jasper application encodes/decodes the whole image using internal representation without any additional segmentation and type conversion. So it is faster, but we can't go this way, because we need access to image data. I don't know how to improve this using current JasPer interface.

Also I don't know how geojasper can help with that. It seems to be the plain JasPer with my UUID patch applied and few more improvements/fixes, but I do not see any serious changes in the codec and changes in API which are most important for GDAL. Also the recent Geojasper seems to be based on JasPer 1.700, which is not supported by GDAL driver any more, so it can't even be a drop-in replacement for JasPer. If it will be upgraded to 1.900.1 it will be possible simply link GDAL to Geojasper instead of JasPer and make tests.

I am leaving this issue opened, though poor performance is a known problem of this driver and I don't know how I can fix it.

Best regards, Andrey

[kyngchaos]

Strange - (now using GDAL 1.4.1 + Jasper 1.900.1) - now it's happening in JP2MrSID, and not JasPer. gdalinfo on the JP2 (using GDAL_SKIP to disable the other drivers):

JP2KAK: 1 sec to get full info.

JPEG2000: 5 sec for bounding box info, 40 sec to finish with full info.

JP2MrSID: I let it process for a few minutes (more than what it took originally), then gave up. It never even identified the driver used.

JPEG2000 is built into GDAL, KAK and MrSID are built as plugins. I'm not sure if I had updated to the MrSID DSDK 6 at the time, since I reported this only a few days after it was released, but I am using the most recent DSDK 6 now.

As for geojasper, it may be a speedup patch that arturr is talking about - some kind of caching/memory usage improvement. I had applied that to my 1.700-based JasPer builds, but not 1.900, since there were supposedly other speed improvements and I didn't want to mess around trying to port the patch to 1.900.

[arturr]

I tested jasper with big jpeg files - it's very slow and consumes lots of memory - that's not good for GIS solutions. I found an extension called geojasper:

​http://www.dimin.net/software/geojasper/

that was optimized for GIS. There is also additional site:

​http://homepage.mac.com/gregcoats/jp2.html

where you can find performance evaluations and Mac binaries. I hope that this is the solution to improve JPEG 2000 performance in GDAL we are looking for.

I didn't test building geojasper with GDAL but I hope nothing must be changed to make it work.

[Even Rouault]

Nothing to expect from Jasper side. OpenJpeg v2 branch is planned to be merged into openjpeg trunk, so hopefully this will be a more viable solution