Print

Print


hi craig and guillaume,

you might want to check the output of that field as different sequences may not write out that information properly.

guillaume: also on our multislice data the spm_dicom_headers interprets that field as 520 integers instead of 65 doubles. it treats 1byte as 1 number, when it should be 8 bytes == 1 number.

cheers,

satra

On Tue, Feb 10, 2015 at 9:04 AM, Guillaume Flandin <[log in to unmask]> wrote:
Dear Craig,

I cannot comment on dcm2nii and I am not too familiar with private DICOM
tags but, yes, this should correspond to the slice times in ms to enter
in the 'Slice order' entry of SPM12 slice timing correction.

See the help for that option:
> You can enter the slice timing in ms for each slice individually. For
> Siemens scanners, this can be acquired in MATLAB from the dicom
> header as follows (use any volume after the first one):
>   hdr = spm_dicom_headers('dicom.ima');
>   slice_times = hdr{1}.Private_0019_1029
> Note that slice ordering is assumed to be from foot to head. If it is
> not, enter instead: TR - INTRASCAN_TIME - SLICE_TIMING_VECTOR

(MosaicRefAcqTimes is private tag (0019, 1029))

Best regards,
Guillaume.


On 09/02/15 22:51, Craig Peters wrote:
> Using dcm2nii on Ubuntu to turn DICOM images into 4D NIFTI's, dcm2nii outputs a matrix for every scan sequence called MosaicRefAcqTimes. Is it appropriate to use these as the inputs for SliceOrder in the new spm_slic_timing.m script?
>

--
Guillaume Flandin, PhD
Wellcome Trust Centre for Neuroimaging
University College London
12 Queen Square
London WC1N 3BG