[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