<div dir="ltr">Hi Even,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 31, 2014 at 1:01 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> * Favouring dataset.RasterIO() over band.RasterIO() to prevent up to 4x<br>
> raster reads<br>
<br></span>If the size of the image (or your requested window) is below the GDAL block<br>
cache maximum size (default is 40 MB), then most drivers should cache the data<br>
for other bands when reading one band (particularly if decompression is<br>
involved), if the storage on disk is pixel interleaved (i.e R1,G1,B1,R2,G2,B2,<br>
etc...), which is generally the case for GeoTIFF. So reading in one call or 4<br>
calls will probably not make a lot of difference.<br></blockquote><div><br></div><div>Good, that's what I suspected.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But if you know that you have to read the 4 bands, there's no reason not to<br>
use dataset.RasterIO() in all situations. GDAL, either in its generic<br>
implementation or in the driver specific one, will look at the declared<br>
interleaving and will/should select the most appropriate reading strategy, ie.<br>
potentially operating block by block if the data is pixel interleaved, or band<br>
by band otherwise.<br></blockquote><div><br></div><div>Okay, thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> * Use of GetBlockSize() to read on block boundaries, then cropping data<br>
> later.<br>
<br>
</span>I've not looked closely at the code you point to, but that depends on what you<br>
do. If you have allocated a big buffer to contain the whole requested window,<br>
then just issue a single RasterIO() and let GDAL do its job to filling it the<br>
best way.<br>
If you just allocate small chunks of memory and process chunk by chunk, then<br>
it is indeed better to call RasterIO() on the block boundaries (or multiple of<br>
block boundaries).<br></blockquote><div><br></div><div>In this case it's the former, so I guess GetBlockSize isn't relevant.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> * Use GetMaskBand()/GetMaskFlags() to simplify nodata/alpha handling<br>
> (probably won't impact performance but might get rid of a bunch of code)<br>
<br>
</span>Yes that can be convenient to avoid having to deal both with nodata and alpha<br>
band in a unified way. Plus some formats can really have a mask band that is<br>
neither of the two. For example you can create a JPEG-compressed YCbCr TIFF<br>
and use an internal mask band to encode transparency (although this is<br>
admitedly quite an exotic TIFF formulation because most readers will ignore<br>
the transparency mask)<br></blockquote><div><br></div><div>That's what I thought (currently I use VRTs to re-alpha-ize mask bands if necessary)</div><div><br></div><div><br></div><div>Thanks for your guidance,</div><div><br></div><div>Rob :)</div><div><br></div></div><div class="gmail_signature"></div>
</div></div>