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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
