[gdal-dev] Re: Proposal: gdal_muladd.py

[Even Rouault]

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,