[gdal-dev] Tilesize in JPEG2000 and gdalinfo

[Even Rouault]

On mardi 5 septembre 2017 09:20:14 CEST Rahkonen Jukka (MML) wrote:
> This information may be less interesting once we have a released OpenJPEG
> driver that can handle big tiles properly.

Agreed. Sub-tile decoding with much more efficient RAM use is now implemented per
https://github.com/uclouvain/openjpeg/pull/1010 . It is currently under review
and should hopefully be merged into openjpeg master soon. A openjpeg 2.2.1 release
with it should follow. I'll keep the list informed.

In your use case, I see the image has RPCL progression order, which is, in theory,
not so bad for efficient sub-window decoding when using network access (PCRL would
probably be better here if doing only partial decoding at full resolution. RPCL allows
for efficient sub-resolution decoding), but currently openjpeg ingests the whole
codestream for the tiles it must decode totally or partially, so I/O wise,
in a network context, this is not friendly for big single tiled images. I know some
people would be interested in improving this. We'll see.

With openjpeg + above mentionned pull request 1010, I tested

gdal_translate /vsicurl/http://kartat.kapsi.fi/files/orto/etrs-tm35fin/mara_v_25000_50/2013/N53/02m/1/N5144H.jp2 out.tif -srcwin 0 0 1024 1024

Took 1m42 in total, for just 4s of CPU time. So mostly the download time of 150 MB

If you remove the /vsicurl/ prefix, then the image is completely downloaded in a single HTTP
GET request (through the intermediate HTTP driver), which enables generally better throughput
if you know that at the end the file will be entirely downloaded (so only for single
tiled images). Note that this will consume 2 times the file size of RAM (once by the HTTP driver,
and once by openjpeg)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170905/2191ee04/attachment.html>