[Neuroimaging] Using nibabel to merge 3D image pairs into single-file 4D Nifti1

[Dav Clark]

Yo!

On Tue, Mar 28, 2017 at 4:47 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> On Tue, Mar 28, 2017 at 7:45 PM, Dav Clark <davclark at gmail.com> wrote:
>


> I'm sure you know, but you can always save directly to whatever format
> the extension implies, as in:
>
> converted = nib.concat_images(fnames)
> nib.save(converted, 'my_filename.nii')
>

I'm sure I could've figured that out. I appreciate your efforts to save me
typing.


> > This version, upon saving with .to_filename() comes up in fslview as
> totally
> > black (the range is not calibrated for some reason - maybe there's an
> errant
> > bright voxel somewhere?). Compared to the results from `fslmerge -t
> fnames`,
> > setting the range the same for voxel intensities, I get the same images,
> and
> > the same time-series shape. However, intensities are slightly off (even
> in
> > the same TR) by values ranging from hundreds to thousands (the raw
> > intensities are in 100,000's). So, usually < 1% I suspect.
> >
> > Is this worth getting to the bottom of? Happy to share some EPIs with you
> > somewhere... by default I would use JHU Box.
>
> Just to clarify - the result of `fslmerge` does not look totally black
> in fslview?
>

That's correct. Looks real pretty-like, from the deepest black to the
whitest white my monitor can display.


> Do the images from fslmerge and `nib.concat_images` have the same data
> range?  What range do they have, when you load them into nibabel and
> do:
>
> data = img.get_data()
> print(data.min(), data.max())
>

This was the ticket, I think. Min values are both 0. But max are
1253294.0009593964
for nib merged version, and 1253294.0 for the FSL-merged version. Turns out
the dtypes are '<i2' and '<f4' respectively. dtype on initial images also
'<i2'. So, FSL is type-converting to float, which would explain why the nib
file is smaller (75MB vs 90MB). Neither of the concatenated images has the
exact same max in the first slice as the first original image either.

Anyway, I'm happy to leave it at that - I think I prefer the floating point
option, as it makes the image simpler to work with and compression makes
the size difference not so huge. My guess is that keeping the image in
integer format also limits accuracy, as I'm pretty sure Nifti1 implements a
single scaling constant for the whole image - 3D or 4D, and I guess we're
round-tripping through float64 already.

D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170328/3552e9a6/attachment.html>