Le jeudi 05 mars 2015 21:54:57, Jukka Rahkonen a écrit : > Norman Barker <norman <at> cloudant.com> writes: > > Even, Jukka, > > > > the NPJE end EPJE specifications are both good for understanding > > progression order in JP2. It all depends on what you are trying to do, so a > default is just that, something that can be changed. > > > A JP2 file with PLT markers (packet markers) in my experience removes > > most > > of the overhead of accessing packets as the header decoding doesn't have to > be performed. > > > I fear that only few people understand really JP2 and I do not count me in. > It is our responsibility to try to offer reasonable defaults for we
I bet very few people can understand the whole complexity of the standard (and I do not count me either!). There are so many parameters that you can tune... > consider as standard geospatial image, let's say 15000 by 15000 pixels, RGB I've done a few tests encoding a RGB BMNG tile (21600x21600) with the JP2OpenJPEG driver with different block size (1024, 4096, 16384), with precincts, and with the PCRL, LRCP and RPCL progression orders. Using a 16384 large tile requires a huge amount of RAM with openjpeg (at least 16384*16384*3 = 800 MB, but perhaps twice or third times that when counting temporary buffers) When reading with an efficient JPEG2000 decoder, for the same block size, I can't see any really noticeable difference between the 3 profiles, either when reading a single pixel, random regions at full resolution, or a downsampled region. I presume the difference between the organizations would appear in network streaming contexts rather than with an efficient storage and reader. Note that the L factor doesn't count much as the driver only outputs one layer (that is something potentially tunable by the openjpeg lib, but not exposed by the driver) Other findings are : - The larger the block size is, the more efficient downsampled reads are (because that tends to reduce the number of requests that span over several tiles). - The smaller the block size, the more efficient non-scaled reads are (with the size of regions of the order of the block size or less). Those findings do not apply when using openjpeg as a reader because, as far as I tested, it doesn't seem to use precincts or other optimizations for intra- tile reading at full resolution, so 1024x1024 tiles is a reasonable setting for it. Larger tiles will require a lot of memory for decoding too and will be slow. The main drawback is that getting the overviews will be slower than if a single tile would have been used. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
