[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