SPM SliceTiming must accept either Int or float for ref_slice and sli…

[servoz]

#3254

[codecov]

Codecov Report

Merging #3255 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3255   +/-   ##
=======================================
  Coverage   65.05%   65.05%           
=======================================
  Files         302      302           
  Lines       39949    39949           
  Branches     5282     5282           
=======================================
  Hits        25988    25988           
  Misses      12890    12890           
  Partials     1071     1071           

Flag	Coverage Δ
#unittests	65.05% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
nipype/interfaces/spm/preprocess.py	50.44% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 929de35...3e2f458. Read the comment docs.

[effigies]

This doesn't make much sense to me on its face, but if SPM accepts these values, that seems fine. Do you have a reference? I don't see indications of this behavior in https://en.wikibooks.org/wiki/SPM/Slice_Timing.

[servoz]

In the spm12 manual, it is stated that slice_order and ref_slice can be provided in slice time instead of slice indices. In this case TA is set to zero. It is true that we (I) generally use slice indices, but in some cases (multi-band accelerated EPI data) slice times are appropriate.

[servoz]

If the spm documentation is not enough, there is another way to convince yourself:
In the Slice Timing module of spm (Batch Editor > SPM > Temporal> Slice Timing) use for example :
nslices = 10 ;
tr= 2.95 ;
ta= 0 ;
so= [0:1:9]*2.95/10 ;
refslice = 11.8 ;
all these parameters are accepted by SPM. This is a direct proof that refslice can be a float and so can be a list of floats.

[effigies]

Ah, no sorry, I've just been very busy. I'll look again today.

[effigies]

Yup, this looks good. Looks like the trait documentation actually already included these options, but the types didn't permit. Thanks for this!