[gdal-dev] Issue with GDAL - JP2KAK driver
BORISF at rnd-hub.com
Sun Jun 28 05:36:47 PDT 2020
Thanks for the response,
the image is indeed RPCL,
doesn't that mean that the bits for the overview are not scattered through the file?
From: Even Rouault <even.rouault at spatialys.com>
Sent: Sunday, June 28, 2020 1:20 PM
To: gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
Cc: Boris Forzun <BORISF at rnd-hub.com>; MICHAEL FLASH <MICHAFL at rnd-hub.com>; YOSSI PARIENTE <YOSSIPA at rnd-hub.com>
Subject: Re: [gdal-dev] Issue with GDAL - JP2KAK driver
> JP2KAK: DirectRasterIO() for 0,0,8192,8192 -> 512x512 (no intermediate)
This traces is probably a bit confusing, but it means that it reads from the overview you specified.
> CPLSetConfigOption("CPL_VSIL_CURL_CHUNK_SIZE", "1000000");
This is probably the reason for the behaviour you observe. JPEG2000 files aren't necessarily all optimized for efficient overview retrieval. You should check the "progression order" of that file. If it is not RPCL or RLCP, the bits for overviews are scattered through the file, and so with a large chunk size you'll read a lot of the file. If you reduced it, the total amount of bytes read would be smaller, but you'd get a lot more GET requests.
But... with RPCL or RLCP progression order, reading a window at full resolution could become less efficient than with PCRL
I don't think you can get with JPEG2000 something equivalent to TIFF + overviews, because in TIFF + overviews you have redundancy of information (each resolution includes information already found in lower resolution), whereas JPEG2000 is optimized to avoid that redundancy, which also means that information is scattered through the file.
> The higher the overview, the bigger the request from S3, as if GDAL reads
> the best resolution and resamples the results.
Yes, that's "expected" given the above.
Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev