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

[Matthew Brett]

> Me again,

Me again too.

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

Well, for now, I think we wanted to go for an object that encapsulates
a regularly sample data block that is at least 3D.  That seemed like a
modest but useful start.  We could go on to try and deal with meshes
and so on, but that could be another class or class hierarchy.

>  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() ??

Hoho - that was exactly the discussion that we were having during the
Neurospin sprint.

We are able to encapsulate arbitrary transformations, with the
'CoordinateMap', and the current NIPY model for an Image is the
association of the image data array with a CoordinateMap object of
arbitrary transformation complexity.  We found then that we often
wanted to ask for an affine from the coordinate map, and then we asked
whether there was really any use-case for an Image with a non-affine
transformation, as opposed to images with always-affine
transformations, and separate Transformation objects that can be used
in resampling images.  I must say, I now lean towards this last
option.

See y'all,

Matthew