[gdal-dev] Question on block size in the kakadu driver
Kurt Schwehr
schwehr at gmail.com
Thu Jan 5 07:18:45 PST 2017
Frank, Even or anyone with experience with jp2k block sizes,
Any chance you could comment on the change I proposed here?
https://trac.osgeo.org/gdal/ticket/6764
Is it reasonable to change this:
if( nRasterXSize >= 2048 )
nBlockXSize = 2048;
else
nBlockXSize = nRasterXSize;
if( nRasterYSize >= 256 ) // <- 256
nBlockYSize = 128; // <- 128 ???
else
nBlockYSize = nRasterYSize;
Into:
nBlockXSize = std::min(nRasterXSize, 2048);
nBlockYSize = std::min(nRasterYSize, 128)
or
nBlockXSize = std::min(nRasterXSize, 2048);
nBlockYSize = std::min(nRasterYSize, 256)
Neither of those is the same behavior and the the jump from 256 back to 128
is not explained in the revision log. Which behavior will have better
performance for a average case or will it matter? The difference will be
between 262K cells or 524K cells. With doubles, that will be 2 or 4 MB for
a single block from one band. I'm thinking 128 is likely going to work
better with RAM caches.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170105/4ee6f15e/attachment.html>
More information about the gdal-dev
mailing list