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

[Alexis Roche]

Hi,

So it seems that an agreement is still to be found regarding the
codebase organization of vimages. I'm not worried about that because I
think there is plenty of time and obviously some of us have a lot of
experience and ideas on the topic.

What would give me a stronger taste of emergency, at least if we want
to quickly "launch" nipy (make the current codebase more homogeneous,
run fully nipy-based image analyses, attract new users /
contributors,...) is the nipy end-user image API, in other words, the
tip of the iceberg.

My impression is that we're getting very close to such an API, but
it's not completely there yet. Correct? For instance, will the
following piece of code work to load an image (it doesn't at the
moment)?

import nipy
img = nipy.load('file.nii')

This is probably the first thing whoever downloads nipy will try... If
yes, it doesn't really matter in which package the "load" function is
actually implemented (scipy.io.vimages, nipy-base, nifti, ...). If no,
one really has to type:

import otherpackage
img = otherpackage.load('file.nii')

so we better decide pretty soon what otherpackage is in this case.

Needless to say, my preference goes to the first option. Now, assuming
that nipy exposes "load", is img an instance of (a subclass of)
nipy.Image or a class defined in  otherpackage? Again, if the second
option is chosen, we better be aware of otherpackage to do type
checking.

I know those questions have been mostly addressed in the discussion
and they may sound trivial at this point. But, until we completely
freeze the API, the whole nipy codebase will be unstable, which will
slow down the whole project. So it seems to me that we should consider
the high-level API our current *top one* priority.

What's your opinion?

Best,

Alexis

-- 
Alexis Roche, PhD
Researcher, CEA, Neurospin, Paris, France
Academic Guest, ETHZ, Computer Vision Lab, Zurich, Switzerland
http://alexis.roche.googlepages.com