[gdal-dev] Question on block size in the kakadu driver

[Even Rouault]

On jeudi 5 janvier 2017 07:18:45 CET Kurt Schwehr wrote:
> 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 code is a bit weird indeed. But the block size of smallish datasets has no real importance, 
so if you find it more reasable, switching the condition to if ( nRasterYSize >= 128 ) (or the 
equivalent std::min()) should have no adverse consequences.

Block size in the case of JPEG 2000 is really hard to come with. A smarter block size logic 
would depend on JPEG 2000 tiling, presence of precincts, etc... This also could depend on the 
read pattern. Would deserve extensive testing to come out with the ideal formula... In the 
case of JP2KAK, there's also a IRasterIO() implementation that causes the block size to not 
be used at all in typical read scenarios.


> 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.

FWIIW, JPEG2000 doesn't support double (at least not in the base standard)


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