<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
great, glad we've come together on this.<br>
<br>
Michael Hanke wrote:
<blockquote cite="mid:20090113191824.GA30883@localhost" type="cite">
<blockquote type="cite">
<pre wrap="">* 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():
</pre>
</blockquote>
<pre wrap=""><!---->Ack, but how should the volume iterator handle images with more than 4
dimensions?
</pre>
</blockquote>
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...<br>
<br>
<blockquote cite="mid:20090113191824.GA30883@localhost" type="cite">
<blockquote type="cite">
<pre wrap="">* (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...
</pre>
</blockquote>
<pre wrap=""><!---->Ack, but that might also be better written as a utility function.
</pre>
</blockquote>
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?<br>
<blockquote cite="mid:20090113191824.GA30883@localhost" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
</body>
</html>