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

Matthew Brett matthew.brett at gmail.com
Wed May 13 19:25:14 UTC 2009


Ouch.  I find I am having to think, and smoke is coming from the top of my head.

>> No...  I suppose it could, via PIL or something, but that would only
>> make sense if the TIFF was a volume.
>
> Thanks Matthew. If this were to make it's way to scipy, I think it would be
> good for it to read stacked tiff's. That's the format that's used by
> molecular biologists and neuroscientists to store confocal microscopy and
> other imaging data.

Yes...   The thought that that brings up - is the same thought as you
bring up here:

> I forgot to ask if we are insisting on a volume as having a transform. Then
> it's not an arbitrary medical image volume.

For NIPY, yes, the image needs a transform.  But, several formats
don't have transforms - basic Analyze for example.  You can make an
implicit one, but maybe that should be 'explicit rather than
implicit'.  TIFFs, I suppose, do not have a transform.

Perhaps the interface could return transforms, such that:

img.affine

would raise an attribute error if there was no explicit transform.

> A 2D image is a volume with the 3rd dimension set to 1. So if I extracted
> slices from a volume would I have to do:
>
> someotherpackage.save(my2Dslice,'canIbea3dvol.dcm')
>
> instead of
>
> medvol.save(my2Dslice,'iama3dvol.dcm')

Er ...  I can imagine saving slices of images, but - as far as the
format would allow - we'd preserve the information out the position of
that slice in 3D space.   If the format can't store it, then - we save
and anticipate having problems with the affine when we load.

Seem OK?

Matthew



More information about the Pkg-exppsy-pynifti mailing list