<div dir="ltr"><div>Frank, Even or anyone with experience with jp2k block sizes,</div><div><br></div><div>Any chance you could comment on the change I proposed here?</div><div><br></div><div><a href="https://trac.osgeo.org/gdal/ticket/6764">https://trac.osgeo.org/gdal/ticket/6764</a><br></div><div><br></div><div>Is it reasonable to change this:</div><div><br></div><div><div>    if( nRasterXSize >= 2048 )</div><div>        nBlockXSize = 2048;</div><div>    else</div><div>        nBlockXSize = nRasterXSize;</div><div><br></div><div>    if( nRasterYSize >= 256 )  // <- 256</div><div>        nBlockYSize = 128;       // <- 128 ???</div><div>    else</div><div>        nBlockYSize = nRasterYSize;</div></div><div><br></div><div>Into:</div><div><br></div><div><div>         nBlockXSize = std::min(nRasterXSize, 2048);</div><div>         nBlockYSize = std::min(nRasterYSize, 128)</div></div><div><br></div><div>or</div><div><br></div><div><div>         nBlockXSize = std::min(nRasterXSize, 2048);</div><div>         nBlockYSize = std::min(nRasterYSize, 256)</div></div><div><br></div><div>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.</div><div class="gmail_signature"></div>
</div>