4D conversion issue about dcm2niix HOT 6 CLOSED

Without a sample image this will be hard for me to trouble shoot. An orthogonal slice would also help (e.g. is this really a 56 slice volume or are there two echo, where the volume should be 512x512x56x25x2). The challenge here is that different vendors use different approaches to encoding this information. In any case I have added a stub for handling DICOM tag,element 0x0020, 0x0105 to nii_dicom.cpp that should give you a good starting point
https://github.com/neurolabusc/dcm2niix/blob/master/console/nii_dicom.cpp

from dcm2niix.

Thanks for the comments. I will follow up and see if I can provide data or debug it myself.

This is a single volume with 56 axial slices. dcm2niix cuts off the top half of the volume and adds these images to every second temporal position.

The sagittal view using the (old) dcm2nii conversion

The sagittal view using the dcm2niix conversion

Let me investigate further and follow up later.

from dcm2niix.

OK it seems that for our data kLocationsInAcquisitionGE is getting a value from (0021, 104f) that is half the value of the actual number of axial slices. I assume this is an error in the dicom header.

from dcm2niix.

Nice work! That would explain it. Since 0021,104f is a private tag I think a good solution would be to give the public 0020,0105 precedence.

I have a guess as to what is happening. I think this sequence has GE’s interpolation function switched on, so it is generating twice as many slices as there are locations. Therefore the DICOM is reported the number of slices acquired, but not the number stored.

If my hunch is correct, I would like to think we have evidence of it in one of the tag, perhaps check

0043, 1079 'US' LocationsInAcquisition
2001, 1018 'SL' LocationsInAcquisition
2001, 102D 'SS' StackNumberOfSlices

-c

Chris Rorden, PhD
Endowed Chair of Neuroimaging
Department of Psychology
University of South Carolina
Columbia, SC 29208, USA
phone +1 803 404 2573
email [email protected]:[email protected]
web www.mricro.comhttp://www.mricro.com

On Feb 18, 2016, at 11:15 AM, Benjamin Irving <[email protected]mailto:[email protected]> wrote:

OK it seems that for our data kLocationsInAcquisitionGE is getting a value from (0021, 104f) that is half the value of the actual number of axial slices. I assume this is an error in the dicom header.

—
Reply to this email directly or view it on GitHubhttps://github.com/neurolabusc/dcm2niix/issues/11#issuecomment-185796601.

from dcm2niix.

Thanks for testing my fix and for your detective work. I have now committed this to the main branch and I am closing this issue. To summarize, the GE tag 0021,104f is not always reliable (presumably due to interpolation), so giving priority to 0020,0105 is a suitable work-around.

from dcm2niix.

Great. Happy to help.

from dcm2niix.