<div dir="ltr"><div>Thanks all for your suggestions.<br></div><div><br></div><div>@Rutger and @Damian:</div><div>Thanks for your suggestion about the blocks.</div><div>I had a look at Rutger's links,</div><div>I create the input file myself so I can add 'TILES=YES' but I'm not sure how to change my calculation code.</div><div>I see in this first link <font face="monospace, monospace">xbs, ybs = b1.GetBlockSize()</font> But I don't see when to use the xbs or ybs variables.</div><div>I assume I need to change the reading of the data: <span style="font-family:monospace,monospace;font-size:12.8px">band.ReadRaster(0, line, sizeX, 1, scanline, sizeX, 1, 0, 0);</span> but I'm not sure how.</div><div>And how should I write back the block?</div><div><br></div><div>BTW. The main bottle-neck seems to be in the used formula parser.</div><div>With the formula it takes 68s, without the formule - just setting the pixelvalue takes 3.3s and with the formula written in code <font face="monospace, monospace">pixelValue = (float)Math.Exp(3.1 + 0.9 * f);</font> it only takes 3.4s.</div><div>So not using mathparser has the highest benefits. I will do that first, but I also want to understand the block reading and writing.</div><div><br></div><div>@Jan, thanks for your link to the other parser. I had a quick look and it looks very promising. Sadly I couldn't get their C# example working.</div><div>I will look at as well.</div><div><br></div><div>Just a more general question.</div><div>Doesn't it makes sense if gdal would provide a gdal_calculate tool which also is librified like VectorTranslate?</div><div>It seems lots of people are implementing it on their own.</div><div><br></div><div class="gmail_extra">Thanks,<div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<br>
Paul</div></div><div dir="ltr"><br></div><div dir="ltr"><br></div></div></div></div></div></div></div></div><div class="gmail_quote">2017-06-14 9:29 GMT+02:00 Rutger <span dir="ltr"><<a href="mailto:kassies@gmail.com" target="_blank">kassies@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Damian Dixon wrote<br>
<span class="">> It is usually better to process the pixels in a block rather than walking<br>
> across each row especially if you are processing a TIFF as these are<br>
> usually stored as tiles (blocks).<br>
<br>
</span>Other layouts are common as well. For example, the Landsat TIFF's provided<br>
by the USGS have a row based-layout.  If you can choose it yourself, bocks<br>
are prefered in my opinion, since GDAL VRT's have a fixed blocksize<br>
of128*128. So when writing TIFF's, setting "TILED=YES" is a good default.<br>
<br>
I think your spot on by mentioning the blocks. Don't assume the layout at<br>
all, look at the blocksize of the file and use it. If the blocks are<br>
relatively small (memoy-wise), using a multiple of the size can increase<br>
performance a bit more. So if its row-based and you have plenty of memory to<br>
spare, why not read blocks of (xsize, 128). Or if the blocksize is 128x128,<br>
use blocks of 256x256 etc.<br>
<br>
If the volume of data is really large, increasing GDAL's block cache can be<br>
helpful. Although its best to avoid relying on the cache (if possible) by<br>
specifying an appropriate blocksize.<br>
<br>
Here are a few mini-benchmarks:<br>
<a href="http://nbviewer.jupyter.org/gist/RutgerK/4faa43873ee6389873dd4de85de7c450" rel="noreferrer" target="_blank">http://nbviewer.jupyter.org/<wbr>gist/RutgerK/<wbr>4faa43873ee6389873dd4de85de7c4<wbr>50</a><br>
<br>
<a href="https://stackoverflow.com/questions/41742162/gdal-readasarray-for-vrt-extremely-slow/41853759#41853759" rel="noreferrer" target="_blank">https://stackoverflow.com/<wbr>questions/41742162/gdal-<wbr>readasarray-for-vrt-extremely-<wbr>slow/41853759#41853759</a><br>
<br>
Regards,<br>
Rutger<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1560.x6.nabble.com/gdal-dev-Raster-calculation-optimalisation-tp5324014p5324120.html" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.<wbr>nabble.com/gdal-dev-Raster-<wbr>calculation-optimalisation-<wbr>tp5324014p5324120.html</a><br>
Sent from the GDAL - Dev mailing list archive at Nabble.com.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a></div></div></blockquote></div><br></div></div>