PyBuffer build fails due to integer type mismatch (int vs npy_intp)

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Successfully build and install ITK with WrapITK for Python on Mac OS X (see 
below for version details).
2. Configure the PyBuffer external project with CMake.
3. `make' fails.

What is the expected output? What do you see instead?

After ensuring that CMake finds all the necessary Python and NumPy includes and 
libraries, here is the error that `make' chokes on:

$ make
[ 12%] Generating wrap_BufferConversionPython.xml
[ 25%] Generating wrap_BufferConversionPython.idx
[ 37%] Generating wrap_itkPyBuffer.xml
[ 50%] Generating wrap_itkPyBuffer.idx
[ 62%] Generating wrap_BufferConversionPythonPython.cxx
create swig package BufferConversionPython
  init module: itkPyBuffer
[ 75%] Generating wrap_itkPyBufferPython.cxx
[ 87%] Building CXX object 
CMakeFiles/_BufferConversionPython.dir/wrap_BufferConversionPythonPython.o
[100%] Building CXX object 
CMakeFiles/_BufferConversionPython.dir/wrap_itkPyBufferPython.o
/Users/mark/src/build/InsightToolkit-3.20.0/Wrapping/WrapITK/ExternalProjects/Py
Buffer/itkPyBuffer.txx: In static member function ‘static PyObject* 
itk::PyBuffer<TImage>::GetArrayFromImage(TImage*) [with TImage = 
itk::Image<float, 3u>]’:
/Users/mark/src/build/InsightToolkit-3.20.0/Wrapping/WrapITK/ExternalProjects/Py
Buffer/build/wrap_itkPyBufferPython.cxx:1383:   instantiated from here
/Users/mark/src/build/InsightToolkit-3.20.0/Wrapping/WrapITK/ExternalProjects/Py
Buffer/itkPyBuffer.txx:64: error: cannot convert ‘int*’ to ‘npy_intp*’ 
in argument passing

... (the same error is repeated for each template instantiation) ...

make[2]: *** [CMakeFiles/_BufferConversionPython.dir/wrap_itkPyBufferPython.o] 
Error 1
make[1]: *** [CMakeFiles/_BufferConversionPython.dir/all] Error 2
make: *** [all] Error 2

What version of the product are you using? On what operating system?

ITK 3.20.0 (WrapITK r539). Mac OS X 10.6. Python 2.6.5. NumPy 1.6.1.
(I suspect the same error can occur on other platforms where int is 32-bit and 
npy_intp is 64-bit, as C++ does not allow implicit conversion between pointers 
to different integer types.)

Please provide any additional information below.

Here's a patch that should fix this issue.

--- a/itkPyBuffer.txx     2009-06-23 21:53:24.000000000 +0000
+++ b/itkPyBuffer.txx     2011-08-31 01:21:04.000000000 +0000
@@ -49,7 +49,7 @@

   char * data = (char *)( buffer );

-  int dimensions[ ImageDimension ];
+  npy_intp dimensions[ ImageDimension ];

   SizeType size = image->GetBufferedRegion().GetSize();

Original issue reported on code.google.com by marktsuc...@gmail.com on 31 Aug 2011 at 1:48

[GoogleCodeExporter]

I have noticed that this has already been reported elsewhere, e.g., in 
http://stackoverflow.com/questions/4038500/going-from-numpy-array-to-itk-image 
and pages linked therefrom.

Original comment by marktsuc...@gmail.com on 10 Sep 2011 at 12:22

[GoogleCodeExporter]

The fix above (int -> npy_intp) is needed only for the version of PyBuffer in 
the ITK repository between ITK git commits 
22c8a02323d482edc1b1508b88690a8c670f5909 (2009-05-22) and 
0248e8fa1cb8b547cc04f84e708011c696518c23 (2011-01-23), not to the version here 
(SVN r539) on Google Code.

ITK commit 22c8a023 (among other things) removed the use (12 lines down in the 
same function) of PyArray_FromDimsAndData() (a deprecated function from the old 
NumArray API) and replaced it with a call to PyArray_SimpleNewFromData() (the 
equivalent modern NumPy API function), but forgot to change the type for the 
second argument (from int* to npy_intp*), hence this bug. But this change has 
not been merged into the Google Code SVN repository (as of r539).

ITK commit 0248e8fa imported WrapITK r539 from Google Code, thereby effectively 
reverting the unmerged change (and perhaps others?). So this bug does not 
manifest itself when compiling the version of PyBuffer that comes with, e.g., 
ITK 4.2. (But ITK 4.x's PyBuffer therefore continues to call the deprecated 
function.)

Original comment by marktsuc...@gmail.com on 10 Aug 2012 at 1:29