Hi Chris,

Phillips, latest update.
dcm2niiX version v1.0.20181125

I'm doing BOLD imaging using a dual-echo sequence. I collected a short scan with 10 dynamics in L->R fat shift direction, and another 10 in R->L.

The 2 echoes are separated into two 4D files correctly, but dcm2niiX stacks the packages with opposing fat-shift on top of eachother in the z-axis (see attached).

Is there a quick fix for this? 

Cheers

Richard

Richard

Thanks for the sample dataset. I would suggest you forward this dataset to your Philips Research Collaboration Manager. This is a problem with your DICOM data - not dcm2niix. The dataset specifically lists that it has 62 locations and does not differentiate between the L>R and R>L encoding. The two datasets are stacked based on 2001,100a which ranges from 1..62. I realize that you were expecting two volumes each with 31 slices. However, this is not disambiguated in the DICOM header. I would be happy to help once you can get the headers to reflect the unique properties of the scans (just like dcm2niix is already able to disambiguate the different echoes in this sequence). We are at the mercy of the vendors with this - if they tell us that these images belong in a stack of 62 slices, that is what the software will produce. A simple script should help you rescue the exisitng data. I wonder if there is a simple method to ensure future data saves the phase encodings as two different series (ideally with two protocol names). That would solve your issue.
Slices report
(2001,1018) SL 62 //LocationsInAcquisition' % 'NumberOfSlicesMR
Different slices report positions 1..62
(2001,100a) IS [1] SliceNumberMR
...
(2001,100a) IS [62]