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

[Ivan]

Even,

That was a little thing that I start years ago. Here is the usage:

{{{
# =============================================================================
# Usage Message
# =============================================================================

def Usage():
     print 'Usage: mathbox.py [-formula "formula"] [outfile] [infile*]'
     print
     print '  -formula      Formula to be applied on input pixels values'
     print '                assigning the results to the output.'
     print '                Use letters "a" to "j" as variables to refers'
     print '                to the list of infiles in alphabetic order'
     print '  outfifile     Name of the output file'
     print '  infile        Name of the input file(s)'
     print
     print '  Notes: Images will be identified by the order of file name as "a,b,c...'
     print
     print 'Examples:'
     print
     print '  mathbox.py -formula "a+b/2" result.tif dist_roads.tif slope.tif'
     print '  mathbox.py -formula "a-255" correct.tif original.tif'
     print
     sys.exit(1)
}}}

It is based on the "eval()" Python function, so it will actually execute the formula as it was
entered by the user. Please let me know if that would be of any interest.

Regards,

Ivan

Even Rouault wrote:
> 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>