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

[Vincent Schut]

On 02/03/2010 01:48 AM, Ivan wrote:
> 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
Some years ago I've created something similar, I still use it from time 
to time. See attached python script (if that survives the list. we'll 
see...). As far as I'm concerned the code is public (it's not that fancy 
:)). I'm not willing to maintain this actively as part of gdal, but feel 
free to adapt/adopt/use/mix'n'match it.
O by the way, it does more or less the same as Ivan's (apply a formula 
or formula's on pixels on input bands/sources), but is pretty flexible 
as you have all of numpy & python available in your formula. Furthermore 
it evaluates per line, so no neighbourhood functions possible, but also 
no memory limits :-)

Vincent.
>
> 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
>>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdal_calc.py
Type: text/x-python
Size: 13673 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100203/41287761/gdal_calc-0001.py