[Numpy-discussion] VIGRA, NumPy and Fortran-order (again)

Hans Meine meine@informatik.uni-hamburg...
Fri Jul 17 09:54:21 CDT 2009


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,

[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-

More information about the NumPy-Discussion mailing list