Skip to content

SPM's conflict with .nii.gz files - Should SPM gunzip input files automatically? #2420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
miykael opened this issue Feb 1, 2018 · 7 comments
Labels

Comments

@miykael
Copy link
Collaborator

miykael commented Feb 1, 2018

The great thing about Nipype is that we can easily switch between different interfaces. For my fMRI workflows I often switch between FSL and SPM routines and from time to time run into the issue that SPM cannot take .nii.gz files as inputs.

Most (all?) FSL routines allow to specify which filetype to output, but I run into problem with the TSNR routine, where output type cannot be specified as easily.

There's always the option to create an additonal Gunzip node or find another workaround. But I'm wondering if it would make sense to change all SPM interfaces in such a way, that they just gunzip input files if they are compressed (or put them into Analyze format if <=SPM8 is used).

What does the community think of this?

@effigies
Copy link
Member

effigies commented Feb 6, 2018

This seems reasonable to me. (I also think this has come up before, but a quick search couldn't find it.)

One approach I can think of would be to add it to the ImageFile (or even File) trait metadata, such as unzip=True which would be like the copyfile attribute, but calling gunzip instead of cp/ln. This could be set true by default in ImageFileSPM.

This would be SPM-agnostic and broadly usable, I think. Converting back to Analyze seems like it would need more SPM-specific code, but perhaps it wouldn't be much extra work once the unzip part was done.

Also as a quick aside, for TSNR, I'd think you can set file type by using tsnr_file='tsnr.nii'. Does this not work, or is it more that there isn't a global setting that can be switched?

@satra
Copy link
Member

satra commented Feb 6, 2018

@miykael - as of spm5, spm supports nifti img/hdr pair and 4-D nifti images and we do not support spm2. so i would be ok with conversion to img/hdr pairs if necessary, but prefer to simply stay in nifti type.

@effigies
Copy link
Member

Ah, #454 is the relevant PR. It's orphaned, in case someone wants to dust it off, merge master and prepare it for inclusion.

@yarikoptic
Copy link
Member

Sorry for a somewhat offtopic -- is it still the case that in 2019 SPM still doesn't support .nii.gz?

@effigies
Copy link
Member

It should: https://www.mathworks.com/help/images/ref/niftiread.html

But I don't know.

@complexbrains
Copy link

Just wanted to update the thread here, I am on the latest version of SPM12 (v7771) that came with the 14th Jan 2020 update, it still does not support/recognize the .gz files.

@Remi-Gau
Copy link

SPM users tend to automatically unzip images before anything else because SPM "batches" are finicky with .nii.gz.

For context and future reference.

Tried with 'SPM12 (7487)'

Reading '.nii.gz' works fine with the base function of SPM despite a warning.

% get header content
>> vol = spm_vol(fullfile(pwd, 'ds000001', 'raw', 'sub-01', 'anat', 'sub-01_T1w.nii.gz'))
Compressed NIfTI files are not supported.

vol = 

  struct with fields:

      fname: '/home/remi/openneuro/ds000001/raw/sub-01/anat/sub-01_T1w.nii.gz'
        dim: [160 192 192]
         dt: [64 0]
      pinfo: [3×1 double]
        mat: [4×4 double]
          n: [1 1]
    descrip: 'FSL5.0'
    private: [1×1 nifti]
        dat: [160×192×192 double]

% The following works fine and the content of the image is loaded
img = spm_read_vols(vol); 

Problem comes when using the SPM batches.

Simple example with realign with unzip files works fine:

file_to_realign = fullfile(pwd, 'ds000001', 'raw', 'sub-01', 'func', ...
                                'sub-01_task-balloonanalogrisktask_run-01_bold.nii');

matlabbatch{1}.spm.spatial.realign.estimate.data = {{file_to_realign}};
matlabbatch{1}.spm.spatial.realign.estimate.eoptions.quality = 0.9;
matlabbatch{1}.spm.spatial.realign.estimate.eoptions.sep = 4;
matlabbatch{1}.spm.spatial.realign.estimate.eoptions.fwhm = 5;
matlabbatch{1}.spm.spatial.realign.estimate.eoptions.rtm = 1;
matlabbatch{1}.spm.spatial.realign.estimate.eoptions.interp = 2;
matlabbatch{1}.spm.spatial.realign.estimate.eoptions.wrap = [0 0 0];
matlabbatch{1}.spm.spatial.realign.estimate.eoptions.weight = '';

spm('defaults', 'FMRI');
spm_jobman('run', matlabbatch);

Same but with zipped input crashes:

file_to_realign = fullfile(pwd, 'ds000001', 'raw', 'sub-01', 'func', ...
                                'sub-01_task-balloonanalogrisktask_run-01_bold.nii.gz');

% ...

spm('defaults', 'FMRI');
spm_jobman('run', matlabbatch);

>> Item 'Session', field 'val': Number of matching files (0) less than required (1).
Error using spm_jobman>fill_run_job (line 472)
No executable modules, but still unresolved dependencies or incomplete module inputs.

Error in spm_jobman (line 247)
        sts = fill_run_job('run', cjob, varargin{3:end});

Error in tmp_job (line 15)
spm_jobman('run', matlabbatch);

So @yarikoptic... It is now 2021 and it is still (somewhat) the case that SPM doesn't support .nii.gz? 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants