Hello Guillaume,
We may have found the problem with our processing - we had originally
been splitting the 4D into multiple 3D volumes during processing and it
looks like the values in the SPM.mat file ended up inconsistent with
what we had on-disk. Reprocessing without splitting up the 4D gives the
consistent results you'd expect.
Thanks for taking the time to look at this.
Bill
On 04/10/2017 10:37 AM, Guillaume Flandin wrote:
> Dear Bill,
>
> Thank you for the feedback. Could you provide more details about the
> exact error message you obtained as well as the version of SPM you
> were using (and possibly the list of installed SPM toolboxes)?
>
> I can't reproduce the error: the 'V' structure (obtained from
> spm_vol) should not have a volume number in the 'fname' field as this
> is stored in the 'n' field so I do not understand how your change
> could fix the issue. This part of the code is only meant to run if
> you have modified the location of the input data (compared to their
> initial location as stored in the SPM.mat file), do you confirm this
> was the case?
>
> Best regards, Guillaume.
>
>
> On 05/04/17 18:54, Bill Ulrich wrote:
>> Hello Pritha (et al.),
>>
>> I just now ran into the same error message and stumbled across your
>> email while looking for hints. I found what I _think_ is a solution
>> for my case and was curious to see if my fix is misguided.
>>
>> I'm using 4D NIFTI files throughout my pipeline, and it seemed that
>> the spm_get_data() function was failing because the 'fname'
>> parameter was including the trailing volume number (e.g.
>> 'foo.nii,5'). Switching line 37 in spm_get_data.m from
>>
>> [p,n,e] = fileparts(V(i).fname);
>>
>> to
>>
>> [p,n,e] = spm_fileparts(V(i).fname);
>>
>> fixed the issue. Is this a bug, or am I missing something about the
>> way I should be handling the NIFTI files? TIA for any help or
>> advice.
>>
>> Cheers,
>>
>> Bill
>>
>
|