<div dir="ltr"><div class="gmail_default"><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Personally I would agree with your approach at looking at the cost of running the</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">formula first.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">However if you do change your code to read/write blocks than there are additional</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">opportunities for speeding the processing up.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Once you have the block size reading working consider using multiple threads.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">You will need to use a GDALDataset for each thread.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">You will however need to consider how you write the results out again</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">as you will not be able to write to a single output. You will have to write to</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">a separate raster for each thread.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">This is the approach I have taken. </div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I can't help you with writing the block back as once I've got the raster data I</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">processes it into a format that allows me to load and display the data a lot</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">quicker than going back to GDAL for the data.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">You need to find the equivalent to:</div><div class="gmail_default"><font face="trebuchet ms, sans-serif">  <a href="http://www.gdal.org/classGDALRasterBand.html#a30786c81246455321e96d73047b8edf1">http://www.gdal.org/classGDALRasterBand.html#a30786c81246455321e96d73047b8edf1</a></font><br></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">Also these may help...</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">  <a href="http://www.gdal.org/classGDALRasterBand.html#ad80cecc562fd48f5783677de625360ac">http://www.gdal.org/classGDALRasterBand.html#ad80cecc562fd48f5783677de625360ac</a><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">  <a href="http://www.gdal.org/classGDALRasterBand.html#a457ae6645dd2680289734aed0afce357">http://www.gdal.org/classGDALRasterBand.html#a457ae6645dd2680289734aed0afce357</a><br></font></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 June 2017 at 14:04, Paul Meems <span dir="ltr"><<a href="mailto:bontepaarden@gmail.com" target="_blank">bontepaarden@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="m_2413006295843777982gmail_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><div class="h5"><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>> 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/gi<wbr>st/RutgerK/4faa43873ee6389873d<wbr>d4de85de7c450</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/ques<wbr>tions/41742162/gdal-readasarra<wbr>y-for-vrt-extremely-slow/<wbr>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.nabbl<wbr>e.com/gdal-dev-Raster-calculat<wbr>ion-optimalisation-tp5324014p5<wbr>324120.html</a><br>
Sent from the GDAL - Dev mailing list archive at Nabble.com.<br>
<div class="m_2413006295843777982HOEnZb"><div class="m_2413006295843777982h5">______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">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/mailma<wbr>n/listinfo/gdal-dev</a></div></div></blockquote></div><br></div></div></div></div>
<br>______________________________<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><br></blockquote></div><br></div>