[Numpy-discussion] VIGRA, NumPy and Fortran-order (again)
Hans Meine
meine@informatik.uni-hamburg...
Fri Jul 17 09:54:21 CDT 2009
Hi,
as I mentioned in the past [1], we considered refactoring our VIGRA (an image
analysis library [2]) python bindings to be based on NumPy [3].
However, we have the problem that VIGRA uses Fortran-order indexing (i.e.
there's operator()(x, y) in C++), and this should of course be the same in
Python. (It is more important to us to have the same indexing in VIGRA's
python bindings and in VIGRA itself, than to have the same indexing as in e.g.
MPL or PIL.)
As discussing in-depth in [1], numpy does not support Fortran order very well.
First, there are performance issues, but even more important: the order is not
preserved when performing simple operations. :-(
In [8]: numpy.isfortran(a)
Out[8]: True
In [9]: numpy.isfortran(a + 4)
Out[9]: False
In [10]: numpy.isfortran(a.copy())
Out[10]: False
In the worst case, this means that VIGRA functions exported to python only for
unstrided images cannot be called on the results of any numpy function call.
Do you agree that this is a bug^H^H^Hmissing feature and how difficult would
it be to implement that?
The specs would be: preserve the *ordering* of the strides (i.e. we're using
mixed-order for RGB images to be able to write image[x, y] = (r, g, b)), and
in the case of multiple input arguments, use the same rules (i.e. array
priority) as for the output type determination.
If I understood Travis' comments in the above-mentioned thread [1] correctly,
this would already fix some of the performance issues along the way (since it
would suddenly allow the use of special, optimized code paths).
Have a nice day,
Hans
[1] http://mail.scipy.org/pipermail/numpy-discussion/2007-November/029837.html
[2] http://hci.iwr.uni-heidelberg.de/vigra/
[3] https://mailhost.informatik.uni-hamburg.de/pipermail/vigra/2009-
May/000610.html
More information about the NumPy-Discussion
mailing list