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

[Matthew Brett]

Hi, again,

> IMHO the underlying question of most aspects we are talking about is:
> Where is the thin red line between pynifti/vimages (or even shorter 'vi' ;-)
> and the nipy image representation. I hope I am not the last person on
> the list that still is not 100% sure about the destiny of pynifti/....

You are certainly not the last person with that concern!

> 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).

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...

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.

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 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.

For example, for those of you interested, it wasn't that hard to add
MINC reading with the current interface.  Current mb/brifti code does:

import nifti.minc as minc
img = minc.load('avg152T1.mnc')

Comments?

See y'all,

Matthew