For the record, I had started some time ago to work on something pretty close to Frank's ideas. It was based on a "generic" expression evaluator that could accept C-like expressions ( arithmetic operators, boolean operators, numeric constants, a few predefined maths functions, user variables, user functions, ...). It could be specialized for pixel operations : the specialization consists in providing the necessary code to evaluate the variables and function calls. I'll give more details once I find where it is burried right now ;-).
It could potentially do more complex operations than just operations on pixels at same location in different images. If my memory are corrects, it could do things like : * "pixel[ysize-1-y][x]" : to make an horizontal flip of an image * "0.30 * source[0].pixel[y][x] + 0.59 * source[1].pixel[y][x] + 0.11 * source[2].pixel[y][x]" : to compute a grey level from RGB * "sum(j,-1,1,sum(i,-1,1,abs(pixel[y+j][x+i] - pixel[y][x]))) / 8" : equivalent of the TPI algorithm of gdaldem * "abs(source[0].pixel[y][x] - source[1].pixel[y][x])" : for the example discussed in the previous post in this thread ;-) This worked pretty well but of course the performance of an interpretator is way much slower than the equivalent compiled code. Best regards, Even Le Tuesday 02 February 2010 17:13:54 Frank Warmerdam, vous avez écrit : > Antonio Valentino wrote: > > Anyway, IMHO the point here is not to decide if we have to > > *modify* the diff function so that it returns abs(b1-b2). > > Greg asked to add a new one ( abs(b1-b2) ) to the *base set* of pixel > > functions. > > Stated that there is no technical difficulty to do this I'm wondering > > what is the Frank's mind about the question. > > Antonio, > > I think including abs(b1-b2) just demonstrates that we haven't come > up with a convenient way of stacking more basic operations (difference > and abs). > > Honestly, I'm a bit ambivalent about fleshing out the use of > pixel operations in VRT files and I've never used them myself. > I think I would prefer to wait for a more generalized expression > evaluation mechanism for VRT or possibly as a distinct driver. > > However, if there are other GDAL developers keen on this functionality, > and willing to take responsibility for integration, documentation and > support then I'm willing to let them proceed. > > Best regards, _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
