>-----Original Message----- >From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari >Jolma >Sent: 12 April 2016 07:10 >To: gdal-dev@lists.osgeo.org >Subject: Re: [gdal-dev] Map algebra > > >11.04.2016, 19:30, alex kirjoitti: >> >> The curse of dimensionality comes in at the point, where the above >> function is called. The method callback is a template function and it >> needs the datatype of each band that is given to it as an argument. (I >> see now that I have made also the above function a template function, >> which may not be needed). >> >> In the end, all you need to do that is type specific is to apply the >> function on >the pixel (at least in many cases). Would it be an option to only make the >pixel >level function a template, rather than the block level function? > >The block-level function is repeated for all methods mainly because >there are a couple of things that would cause an unnecessary overhead if >called at each pixel. First, the method return value, if any, is >initialized at the first call. Second, if the method needs to iterate >over the whole band several times, that requires initialization etc. >which is best done at block level (at the beginning of a first and at >the end of a last block).
I wasn't trying to suggest to do away with the block level stuff, I can see how it makes your code efficient (and more efficient than the row-by-row iteration that I am using). However, I did notice that for many functions this part of the code is generic and does not rely on the template type. >Also the pixel level operation should be as fast as possible and thus a >function call in itself would cause overhead - however, using inline >function might help. Ok, if pixel-level functions are off the table then I give up. To me one of the major aims of a Map Algebra library would be to make it easy to apply pixel-level functions on raster data (along with other aims to support focal, zonal and global operations). >Ari > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
