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