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

[Michael Hanke]

Me again,

On Sat, May 09, 2009 at 09:34:00PM -0700, Matthew Brett wrote:
> On Fri, May 8, 2009 at 8:45 PM, Yaroslav Halchenko <lists at onerussian.com> wrote:
> > naming/ideology:
> > Probably not very constructive, and not very useful, but is Nifti1Image
> > is a class to deal with NIfTI or everything possible (DICOMs) else
> 
> Yes, that's a good point.  At the moment, the code only deals with
> Analyze and NIFTI, but the image framework, and maybe the header
> definition, is designed to be more general.  I don't think it can
> accommodate DICOMS (that was just a bad example I gave, when you have
> made a new .hdr file that allows you read the data directly out of the
> DICOM, but not read the DICOM format).  But, for example, we are
> starting to think about ECAT format, and maybe MINC.  Should that go
> in a package called 'nifti'?  Probably not...
> 
> Should we change the name or split the package somehow?

Hoho! Heading for world-domination?

At first I thought: ok, let it be 'volumeimages' then (think I heard
that one before ;-)

But is it really just volumes? If the actual goal is a general purpose
image abstraction, why should it be limited to (or assume) volumes. The
data we deal with is a blob plus some meta data. I cannot see a
difference to a JPEG with an EXIF header...

... but we assume an affine transformation. If we follow the path to a
neuroimaging based operating system ;-) we should also think about that
affine. Currently there is get_affine(), but shouldn't the API reflect
to possiblity of non-affine transformations. On the weekend I talked to
a CS-guy working on image registration. They are using something like
this:

  http://ieeexplore.ieee.org/iel1/34/938/00024792.pdf?arnumber=24792

but it is really just attaching a transformation to an image. So:

  get_affine() -> get_transformation() ??

at least for the base-class and and (additional) get_affine() only where
it makes sense, e.g. for NIfTI and friends?

The underlying question might be, whether we want to limit the scope of
this lib anyhow. I have virtually no preference or requirements
regarding the name -- although I need to mention that 'everything but
the kitchen sink' is already taken ;-)

But I don't see the need for, nor the use of splitting it into multiple
packages.

Michael


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