Support for partial read/write access

[mih]

This is closely related to issue #9, but asking for more general support of partial access to image data. Algorithms processing huge files might only need to have access to one slice/volume/voxel at a time. It would allow for implementing leaner tools if NiBabel would support partial read from images and partial write to images, i.e. either incrementally writing to a file (e.g. appending volumes), or iterating over a file and modifying its content in-place.

[davclark]

+1

[matthew-brett]

We can (finally) do this using the array proxy slicing. So:

In [1]: import nibabel as nib
In [2]: img = nib.load('my_image.nii')
In [3]: vol = img.dataobj[..., 2]
In [4]: vol.shape
Out[4]: (2, 3, 4)

This used the array proxy slicing interface, and so only loaded one single volume into memory.

Leaving this issue open to remind me to add docs before the release.

[larsoner]

Excellent, this should probably be exploited by #251. The viewer could be made smarter to deal with having a SpatialImage class passed directly to it instead of needing to take a ndarray as img.get_data().

Also, WDYT about adding img.__getitem__ support for that more or less just wraps to img.dataobj? It seems pretty natural/straightforward/expected to do img[..., 2] directly -- I was a bit surprised / disappointed I couldn't use that syntax originally.

[matthew-brett]

Actually you can do that with nipy images.

We had a bit of a discussion about that a long while ago, in a meeting, and we ended up feeling that slicing an image should return an image. That is what happens with nipy, and that can be very useful, for dropping volumes, or slicing slabs off the bottom of the image, while preserving the affine. The problem is that you need to also slice the header and the affine, which nipy does, for the affine at least.

For nibabel, that seemed a little too fancy. So the alternative is to return an array from slicing an image, as you suggest. But I think this would make an image more like an array, and I wanted to keep that distinction, that an image is the association of (array, affine, metadata).

[larsoner]

Fair enough. Maybe it would be worth adding a __getitem__ that just throws an error suggesting that a user should use img.dataobj[...] or img.get_data() to explicitly access the image data array.

[matthew-brett]

That's not a bad idea.

[matthew-brett]

#271

[effigies]

Looks like these docs exist. Good to close?