[gdal-dev] JPEG2000 read performance with OpenJPEG

Simon Shak skunkmyrddyn at gmail.com
Thu Dec 19 10:15:41 PST 2013


I've worked with jp2 for a while and have found that the specifics of each
source was different and had different timings when reading. Overall I
found the erdas ecw/j2k driver had the best read performance. The read only
driver is available freely.
On Dec 19, 2013 2:50 AM, "Jo Meder" <jomeder at ihug.co.nz> wrote:

> Hi,
>
> Just to follow up, once I got GDAL built with OpenJPEG support on Windows
> I found the performance was terrible there as well. So I tried reading in
> blocks and that was obviously the way to do it. The way I was doing it was
> to read a scanline from each rasterband, perhaps 4 different bands for an
> RGBA image, and process all the pixels for a scanline at once. Now I read
> blocks from each rasterband in turn. It completes in a minute or so instead
> of taking 10 minutes without completing one scanline!
>
> It's interesting because it kind of makes having a codepath based on
> GDALRasterBand::RasterIO() redundant, for my purposes anyway. Originally I
> thought I would have two codepaths based on reading scanlines (especially
> considering I'd written it all before trying JPEG 2000!) and reading blocks
> which were switched between depending on block size. That ends up being a
> chunk of code though, and with the risk of major performance issues it
> seems better just to go with reading blocks. All RasterIO() seems to get
> you, on the surface at least, is the data type conversion. However I found
> GDALCopyWords() which seems to handle that.
>
> Thanks to whoever wrote the sample code in the ReadBlock() docs, very
> helpful as a start :-).
>
> Regards,
>
> Jo Meder
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20131219/0cddbdab/attachment-0001.html>


More information about the gdal-dev mailing list