FileBasedImage.serialize()

[effigies]

Serializing an image to a bytes object via BytesIO has come up multiple times.

For reference, the following can be done (works for NIFTI; I'd have to check if it works for other images):

from io import BytesIO
import nibabel as nb

# Create an image `img`

bio = BytesIO()
file_map = {'image': nb.FileHolder(fileobj=bio), 'header': nb.FileHolder(fileobj=bio)}
img.to_file_map(file_map)

Would it be worth adding a .serialize() method (or similar) that returns a bytes serialization, rather than forcing users to go through this somewhat convoluted approach?

[raamana]

few clarification questions:

Isn't nibabel.save() one form of serialization already?

could you elaborate on the need for (and advantages of) BytesIO in the neuroimaging context? Is it to help with web-base image serialization via streaming?

[effigies]

Personally, I haven't had much need to serialize images in this way, but I have been asked multiple times, and had to go through the process of figuring out how to do it. I think there might even be some issues in here that addressed this but I was unable to find them.

What specifically prompted this was this addition to NeuroVault:

f = BytesIO()
fmap = {'image': nib.FileHolder(fileobj=f), 'header': nib.FileHolder(fileobj=f)}
img_surf.to_file_map(fmap)

While you could hack something like this by writing to a file on a ramdisk and then reading the file contents, it's also not hard for us to make this easy.

[raamana]

thanks. But I am still missing the high-level motivation, how BytesIO specifically is helping with it etc. Never mind, if this takes too much work to explain, but this sounds like something potentially very useful as we do more and more web-based I/O (if that's not already reliable or good solutions dont exist)

[effigies]

Ah, the only advantage of BytesIO is that it gives us a file-like interface to create a byte string. That allows us to re-use the machinery that writes to files, making this a very cheap addition.

To be clear, this is an implementation detail. In #644 I propose to return a bytes object, not a BytesIO.

I agree that web-based I/O is probably a frequent use case, but really any inter-process communication that depends on streams rather than files seems like a good use case. If I remember correctly, I think there was some discussion at OHBM regarding keeping images in memory rather than saving files. I think it was AFNI-centric... @Shotgunosine @rmarkello was that y'all?

Am I answering your question?

[Shotgunosine]

That was primarily @leej3. Being able to serialize the image would be helpful for web I/O, I think it'd be a great addition.

[raamana]

Yes, we discussed writing to ramdisk as a possible alternative to save some I/O activity while using AFNI in Python. and then the bigger project of developing a seamless python interface via CFFI and pip-installable AFNI was decided on.

[raamana]

thanks Chris, that really helps. I guess I haven't run into any concrete need yet, but reducing I/O activity would speed up many neuroimaging pipelines (think python/matlab scripts making a series of AFNI/FSL calls).

I wonder how portable and reliable this BytesIO (or similar) serialization is across languages (e.g. python to javascript, or C to python)?

[effigies]

Okay, since the general consensus seems to be this could be useful, I would recommend moving this discussion to #644, where we can talk specifics.