splitting 4D too much

[lamaresh]

I report a bug similar to #355

when I try to convert a GE 3D phase-contrast brain venography made by anatomical + angiographic images, each volume is split in 2, resulting in a 4D nii made by 4 volumes instead of 2.
I'm using last development build.

[neurolabusc]

I believe this is a replication of issue 336 and 365. You are using the new GE multi-band (hyper-band) sequences.

On MacOS and Linux you can build the developmental branch with these commands:

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix

Windows users should be able to get a compiled version from AppVeyor.

Please use the developmental branch until the next stable release. Vendors are continually tweaking their interpretation of DICOM, so we need to constantly update our conversion to support their latest features.

[lamaresh]

I'm already using last development build and the bug still happens, but only with 3D phase contrast venography

[neurolabusc]

Can you send me a link to a sample dataset via Box, DropBox or GoogleDrive (use the email in my avatar).

[halfSpinDoctor]

This may be related: I have the same issue (that is, instead of a single volume with matirx 256x256x120x1, the image is being split into into 256x256x60x2) with 3D fat/water series that have slice zero pad interpolation enabled (ZIP2). This is a big impact for me since the GE PET/MR system uses this protocol for MR-based attenuation correction (MRAC).

In this case, d.locationsInAcquisition = 480 and imagesInAcquisition = 480, because the series outputs 120 slices x 4 images (Water, Fat, InPhase, OutPhase), but these four contrasts are split into separate DICOM series.

Furthermore, locationsInAcqusitionGE = 60 (0020,1002), because 60 slices were acquired, even though 120 per DICOM series are reconstructed. This check does not work, because neither 60 nor 480 are the correct number of slices:

dcm2niix/console/nii_dicom.cpp

Line 6153 in f54be46

if (isVerbose) printMessage("Check number of slices, discrepancy between tags (0020,1002; 0021,104F; 0054,0081) (%d vs %d) %s\n", locationsInAcquisitionGE, d.locationsInAcquisition, fname);

The check for interpolated slices does not work, because both d.locationsInAcquisition and imagesInAcquisition are incorrectly set to 480:

dcm2niix/console/nii_dicom.cpp

Line 6151 in f54be46

d.locationsInAcquisition = imagesInAcquisition; //e.g. if 72 slices acquired but interpolated as 144

d.locationsInAcquisition: 480
imagesInAcquisition: 480

[halfSpinDoctor]

I have a MATLAB based converter that I use as a test bed for replicating problems. In this code, I compare SliceThickness to SpacingBetweenSlices as a test to see if ZIP2 is enabled. I have re-implemented this in nii_dicom.cpp and verified that it works for my test data. The check goes within the if statement block for checking locationsInAcqusition for GE:

    if ((d.manufacturer == kMANUFACTURER_GE) && (d.locationsInAcquisition > 0)  &&  (locationsInAcquisitionGE > 0) && (d.locationsInAcquisition != locationsInAcquisitionGE) ) {
    	if (isVerbose)
    		printMessage("Check number of slices, discrepancy between tags (0020,1002; 0021,104F; 0054,0081) (%d vs %d) %s\n", locationsInAcquisitionGE, d.locationsInAcquisition, fname);
    	/* SAH.start: Fix for ZIP2 */
    	int zipFactor = (int) roundf(d.xyzMM[3] / d.zSpacing);
    	if (zipFactor > 1) {
    		printMessage("Check for ZIP2: SliceThickness+SliceGap: %f, SpacingBetweenSlices: %f \n", d.xyzMM[3], d.zSpacing);
    		printMessage("Slice ZIP factor: %d  \n", zipFactor);
    		locationsInAcquisitionGE *= zipFactor; // Multiply number of slices by ZIP factor. Do this prior to checking for conflict below (?).
    	}
    	/* SAH.end */
    	if (locationsInAcquisitionGE < d.locationsInAcquisition) {
    		d.locationsInAcquisitionConflict = d.locationsInAcquisition;
    		d.locationsInAcquisition = locationsInAcquisitionGE;
    	} else
    		d.locationsInAcquisitionConflict = locationsInAcquisitionGE;
    }

[neurolabusc]

@halfSpinDoctor that looks like an elegant solution, and a clear explanation of the issue. I have committed it to the developmental branch. Hopefully GE users can validate this patch for unintended consequences.

@lamaresh does this resolve your issue?

[lamaresh]

Yes, it works properly now.