[Pkg-exppsy-pynifti] [Nipy-devel] Image, design, usecases

[Michael Hanke]

On Tue, May 12, 2009 at 12:42:05PM -0700, Matthew Brett wrote:
> > I will try to outline the two extremes in this continuum and we could
> > try to converge on something in-between or exactly on one of them:
> 
> > Scenario one -- the is no difference to the NiPy image class
> > ------------------------------------------------------------
> 
> > Scenario two -- low-level image IO
> > ----------------------------------
> 
> Right.  So, what we have at the moment, is in between those two.  I
> think that's where we need to be, because I don't think 2) is useful
> as a building block for 1).

Yes, currently we are in between, but I do not necessarily agree that 2)
cannot be a building block for 1).

> I'll call 2) "very_basic" and 1) "very_complicated".  Both pynifti
> vanilla and volumeimages are "fairly_complicated".
> 
> For example, we often want to be able to look at an image, without
> necessarily loading the data.  Now we've got a problem, because:
> 
> import very_basic
> data, meta = very_basic.load('some_image.nii')
> 
> will always load the data, unless it can be memmapped, which is rare.
> So we can't afford to use 'very_basic' for 'very_complicated', and
> then we're not sharing code...

Fair enough, but I don't think the proposal could not be changed in a
way that would allow for this functionality. scipy.io.vimages could also
expose load_meta(filename) and load_data(filename) (or whatever name you
prefer that would allow for this behavior -- with load() becoming
essentially:

def load(...):
    load_meta()
    load_image()

and probably some sugar to prevent unnecessary duplication.

[Adding after reading this morning's replies]

  I have not preference about the underlying implementation. I kind of
  like the approach suggested by Thorsten in another message that reuses
  the current implementation (summary: basically expose data and meta
  via a function interface but from an image class.

  However, currently get_meta() doesn't return a simple dict -- which it
  should in the context of SciPy (IMHO). Instead it return a dict-like
  things that can do a lot more. If we turn that into a pure dict that
  would be more of what I am thinking about, but see below ....

I am not saying that vimages should not be made with NiPy in mind, but I
nevertheless consider a more generic module worth thinking about.
Otherwise, I cannot really imagine how we could export this stuff into
SciPy. I never aimed for that with PyNIfTI since it had too much stuff
under the hood, but now I can really see the potential ...

> Also, consider getting the affine. For all the formats we know, we
> have to calculate the affine somehow.  So, now, with your metadata,
> you've got lots of functions dumping things into the metadata that
> might be useful, but aren't directly in the header, like affines.
> Then it seems to me you are trying implicitly to create a common
> interface to the header, and that's the concern of very_complicated.

Well, you are right. That is somewhat fuzzy. But still, doing a few
transformations of header content into more 'useable' formats would
nevertheless lead to something very close to 'very_basic', whereas a
change in the data representation with the invention of any kind of
'image class' is close to 'very_complicated'. I simply cannot see the
latter solution to go into SciPy.

So maybe let us focus on a simpler question: Do we aim for SciPy at all?

> So, it seems to me that very_basic will be a broken and unsatisfactory
> version of what we have (fairly_complicated), with no advantages,
> except that we don't need to design an interface, and that's been done
> already, at least mostly.
> 
> There's a reason that pynifti and volumeimages are both
> fairly_complicated, and that's because you need fairly_complicated to
> be able to do useful generic work with more than one format, even if
> the formats are just Analyze and NIFTI.

I don't agree. I think there is an intermediate layer that is useful --
maybe not for interactive use, but surely as low-level building blocks.

If, in the scope of a very_basic vimages, we cannot agree on things like
turning the quaternion representation of the qform into a proper 4x4
matrix upon meta data load, we could at least simply dump the raw header
content into a Python dict, and expand all content into very very very
basic datatypes (i.e. the multiplexed xyzt_units field into two separate
values). The content of that header dict might even be very closely
bound to the respective format, i.e. we do not label anything as
'affine', but instead follow the C headers and keep 'qfac' ...
All logic to compute or simply return an affine would move downstream.

Of course this would require some streamlining to not bloat the
format-specific code in NiPy too much, but I suspect such in interface
would serve a significant proportion of users/modules. For example
PyMVPA could currently interface at this level, since the only thing we
need is access to the raw data array (even unscaled!) and the pixdim
vector. Everything else is just needed to reconstruct a NiftiImage while
preserving all unchanged header values.


> I don't think that pynifti or whatever replaces it should be in NIPY,
> because what it does is separable from the more specific parts of
> NIPY.   I'd like people who are afraid of a lapack dependency and a
> currently rather sprawling code-base to have an obvious place to go
> to, to do stuff with images.  Then, if they think that NIPY is doing
> useful things, they'll pick it up.   Meanwhile we don't tie pyMVPA to
> NIPY, for example.
>
> So, I vote for - make fairly_complicated as simple and well-thought
> out as we can.  Document and clarify the interface so it's obvious how
> to add formats.  Make it a separate package from NIPY.

Here is my vote: Split the current PyNIfTI/brifti/volumeimages mix into
something very basic that goes into SciPy. The rest that is classified
as fairly_complicated goes into NiPy. But not into
'nipy-mydepsscarethehelloutofyou'.  Instead we do as Gael suggested and
come up with 'nipy-base/core/...' which contains the 'complicated'
datatypes useful or necessary to interact with NiPy as a whole. This
would have to be very well thought through and API stable. Such
interface module would be even beneficial to develop software that is
compatible with NiPy without having to depend on (and therefore inherit)
all of its deps forever.


Cheers,


Michael


PS: I don't think that we would loose/waste much of the efforts that
already went into the new code, i.e. I hope and believe that we aren't
yet past the event horizon... ;-)

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050