[Nipy-devel] Zip problems with the _open function

[Matthieu Brucher]

2008/4/18, Jonathan Taylor <jetaylor74@gmail.com>:
>
> Hi,
>
> >
> > So is there a way to get around the stripzipext() function ? Is it
> > really mandatory for all the formats to work ?
> >
> No. It was there more for convenience, so something like this would work.
>
> open("http://somesite.edu/image.nii.gz")
>
> This would download the .gz and try to unzip it. If pynifti unzips it
> itself, then the stripzipext call could be moved to the BinaryFormat
> class...



That would be a nice thing ;) pynifti does not unzip the file in a new fly,
it reads pieces and unzips them on the fly. It may even be faster than the
current way of doing things. What it is really annoying is the loss of
compression information when using custom readers/savers.


Shouldn't each format handle how it uses the filename ?
> >
> I would think so. For instance, if I recall correctly, AFNI's naming
> scheme is such that
> you can have multiple .HEAD files for one .BRIK with an 4x4 transformation
> needed to get the other .BRIK data.
>
> Have you found a work around? If so, let's try it out....
>

We didn't tamper with the current nipy trunk, as we don't have afni images,
only nifti and our own format. For the moment, we have a deadline for the
application we are developing, but when this is over, we should be able to
check what can be done and add appropriate tests before doing a refactoring
of the function.

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.neuroimaging.scipy.org/pipermail/nipy-devel/attachments/20080418/6a35232e/attachment.html