[Pkg-exppsy-pynifti] [pynifti] NiftiDatatset bug?

[Scott]

great, glad we've come together on this.

Michael Hanke wrote:
>> * perhaps a volume iterator across all non-space dims, or a single given  
>> non-space dim (default time) which always yields a 3d vol regardless of  
>> the original dimensionality. like, for vol in nim.timepoints():
>>     
> Ack, but how should the volume iterator handle images with more than 4
> dimensions?
>
>   
not sure there's a perfect solution - one way would be to iterate over 
EVERY dimension, possibly returning coordinates if requested. one way 
would be to require a single index value for all non-spatial dimensions 
other than the iterated one, default to 0 if not provided. and one way 
would be to just not do it :). after all, 90% of ideas are bad ones...

>> * (unrelated but fun) perhaps overload basic arithmetic operations that  
>> just expose the data array. for instance, often i need an example  
>> functional image from a timeseries. there are many ways to do this, but  
>> a really nice one would be NiftiImage(myfile).mean().save('exf.nii').  
>> Also a nice way to mask an image would be (NiftiImage(myfile) *  
>> NiftiImage(mymask)).save(output). These are just conveniences though...
>>     
> Ack, but that might also be better written as a utility function.
>
>   
this may be a matter of taste. i prefer utilitity functions to transform 
my data in a way i infrequently use, or to translate between different 
types of objects, etc. to me these seem more inherent to the object 
itself, like i could imagine niftiimage.data being a private __attribute 
and these would be the tools to use. but, i have more experience in 
matlab/java, perhaps there is a more pythonic reason to use utility 
functions?
>> plus, if these types of things are implemented in the class, the header  
>> can be updated as necessary when the data shape changes. i believe (not  
>> double checking ;)) this is currently possible only if the data array is  
>> extracted, manipulated, then passed into a new niftiimage. so, again,  
>> not a big deal, but doing it this way feels more elegant to me, and is a  
>> bit more convenient and object-oriented.
>>     
> The problem with in-place modification of the data is that the Python
> object is merely a slim wrapper around the C data structure. Just
> checking pre and post conditions during creation of images and export of
> data is _way_ easier than keeping all that structural integrity during
> in-place modifications. I fear that the added level of convenience is
> eaten up but the potential for bugs.
>
>
>   
hmm..... well, the only attributes that would need to be tracked 
in-place would be the array shape and perhaps the data type, no? does 
that simplify things enough? i haven't considered this issue.

or what if, internally, any of these modifications simply created a new 
image and returned that? if the data is a numpy view, performance 
shouldn't be hit too much, right? then you never have to modify inplace 
the header.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/pkg-exppsy-pynifti/attachments/20090113/329451d2/attachment.htm