[Insight-users] Got NaN from WrapITK registration

[Gaëtan Lehmann]

Le 11 janv. 10 à 12:34, Julien Lamy a écrit :

> Le 10/01/2010 22:39, Benjamin M. Schwartz a écrit :
>> I tried to port the simplest python registration example
>> (ImageRegistration3.py) to wrapitk.  The ported script is attached,
>> including a trivial test case.  When the test case runs, the  
>> resampling
>> appears to introduce a NaN value.  It also introduces non-zero  
>> values,
>> despite the fact that the entire input image is zero.  These values  
>> vary
>> from run to run, suggesting that the resampler is reading  
>> uninitialized
>> memory.
>>
>> Is this a bug, as I suspect?  Do you see the same behavior?  I am  
>> using
>> itk, WrapITK, and PyBuffer compiled from the 3.16.0 tarball.
>
> I had a similar problem, and it seems to be indeed a memory problem :
> PyBuffer.GetArrayFromImage does not transfer the ownership of the
> container from the ITK image to the ndarray. Inside the function,
> everything works fine, but when it returns, the itk.Image is  
> destroyed,
> frees its container, and the numpy array points to unallocated memory.
> This causes weird results with small images, and segfaults with larger
> images.
>
> I wrote two functions to set the data ownership, one for the ITK  
> image,
> the other for the numpy.ndarray. I did not find a way to do that on  
> the
> Python level, so they must be wrapped before use, or best,  
> integrated in
> PyBuffer. After calling GetArrayFromImage, you will have to call
> set_pixel_container_ownership(movedImage, False)
> set_array_ownership(a2_mod, True)
>
> Here's the code for the functions:
>
> void
> set_array_ownership(PyObject* array, bool value)
> {
>
> 	PyArrayObject* pyArray = reinterpret_cast<PyArrayObject*>(array);
>
> 	if(value)
> 	{
> 		pyArray->flags |= NPY_OWNDATA;
> 	}
> 	else
> 	{
> 		pyArray->flags &= ~NPY_OWNDATA;
> 	}
> }
>
> void
> set_pixel_container_ownership(itk::Image<float, 3>::Pointer image,  
> bool
> value)
> {
>    image->GetPixelContainer()->SetContainerManageMemory(value);
> }


I think there are several use cases there, and that PyBuffer can't be  
simply fixed, because the user may want to convert an itk image to a  
numpy array (and reverse) and then:

* access the data only in the numpy array -> transfer the buffer and  
the ownership to the numpy array.
   that's what your trying to do.

* use both object to access the same data -> shared buffer.
   that what PyBuffer is doing now. Ownership is kept by the image  
currently, but it may also be relevant to transfer it the numpy array.

* be able to change the data in the image/array without changing it in  
the array/image -> the buffer must be copied. Both objects own their  
buffer.
   that would be the safer but less efficient approach.

PyBuffer should be able to manage all those cases.
Fill free to file a bug report on ITK bugtracker!

Gaëtan



-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100111/08e8b0ab/attachment.pgp>