[Nipy-devel] AFNI code

[Tim Leslie]

Hi Jonathan,

Based on the details you gave below, I put together a Format interface
which will work with the Image class. This interface defines the
methods and attributes which a file format reader must provide to be
used with Image.

This class will hopefully make it easier for people working on both
the Image code and the individual formats. From the Image side, there
is a well defined set of methods and attributes which can be accessed,
which saves having to dig through all the formats code to try to
decide what can and can't be used. From the formats side, it provides
a minimal set of requirements which need to be met for the format to
work as part of nipy.

The attached format.py and test.txt give the Format interface itself,
a simple example of a class which implements the interface
(TextFormat) and a test data file to demonstrate the proof of concept.

If we want to incorporate this interface I would suggest putting it in
formats__init__.py. The getreader() function would need to be changed
sligtly. Having the Format.valid method will let us clean up the
(IMHO) ugly reader = Classname in each of the format modules.
.
I'm happy to go through and make these changes as required, but I
obviously wanted to discuss the idea here first before making these
kind of structural changes.

Cheers,

Tim

On 7/1/06, Jonathan Taylor <jonathan.taylor at stanford.edu> wrote:
> Hi Tim,
>
> I agree. My (personal, internal) documentation is that the key methods a
> return object from a "reader" should implement are
>
> __getitem__(self, slice)
> __setitem__(self, slice, data)
>
> where slice is either a slice or a list of slices.
>
> As for attributes, the minimum is that "image" has an instance of
>
> grid = Instance(SamplingGrid)
>
> Further, if "image" has something that can act as an array, either a
> memmap or an ndarray then this attribute should be called "memmap" (see
> the __init__ method of Image).
>
> I think most of the code respects this basic minimum, but it would be
> worth documenting.
>
> For the ANALYZE, NIFTI-1, I tried to remove as much redundancy as I
> could (look at BinaryImage in neuroimaging.image.formats.__init__). This
> code would not be directly usable for minc2 because the way of accessing
> the header is different and not as direct.
>
> To my understanding, the other problem/issue with minc2 is that there
> will be times when some attributes are present and others when they
> might not be there. So, we would have to decide which attributes are
> necessary....
>
> -- Jonathan
>
> P.S. Do you know how to fix these exceptions for test_write{1,2} in
> test_nifti1.py? (Run test neuroimaging.image.formats to see the ones I
> mean).
>
> Tim Leslie wrote:
> > On 7/1/06, Jarrod Millman <millman at berkeley.edu> wrote:
> >> I am not sure if it will be of any help, but the imaging tools
> >> codebase has some code for supporting nifti1 as well:
> >> https://cirl.berkeley.edu/trac/browser/bic/trunk/imaging-tools/root/imaging/nifti.py
> >>
> >
> > I'll leave that for Jonathan to play with, I'm working on getting the
> > minc code in order. While we're all playing with file format code, I
> > was wondering if it might be a good time to look at a general
> > interface for each of these. Presumably the code for each file format
> > wants to be able to read a file, write to a file, maybe specify valid
> > file extensions, etc. I think that if we specify a minimum interface
> > which each class must implement, it will make life easier in the short
> > term, by giving a target to aim for for each of the formats currently
> > handled, and also in the future when new file formats are added. What
> > do people think?
> >
> > Cheers,
> >
> > Tim
> >
> >>
>
> --
>
> ------------------------------------------------------------------------
> Jonathan Taylor                           Tel:   650.723.9230
> Dept. of Statistics                       Fax:   650.725.8977
> Sequoia Hall, 137                         www-stat.stanford.edu/~jtaylo
> 390 Serra Mall
> Stanford, CA 94305
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: format.py
Type: text/x-python
Size: 2046 bytes
Desc: not available
Url : http://projects.scipy.org/pipermail/nipy-devel/attachments/20060703/6f213632/attachment.py 
-------------- next part --------------
3 3 3
1 2 3
4 5 6
7 8 9
10 11 12
13 14 15
16 17 18
19 20 21
22 23 24
25 26 27