dcm2niix appending an extra _t4582 to my filenames for multiband epi scans

[njvack]

Hi folks,

I'm trying to convert some EPI images for a new study with dcm2niix. To my surprise, it's appending some extra characters to my filename, which I don't really want:

$ dcm2niix -b y -o . -f mytest /tmp/tmp.7bQpiqOdz8
Chris Rorden's dcm2niiX version v1.0.20190902  (JP2:OpenJPEG) GCC4.8.2 (64-bit Linux)
Found 24000 DICOM file(s)
Convert 24000 DICOM as ./mytest_t4582 (96x96x64x375)

In my BIDS sidecar, we have "TriggerDelayTime": 4582 so that's probably where this is coming from, but I haven't asked for trigger delay time in my filename. Is there a way I can not get it?

[neurolabusc]

This is the intended behavior with disambiguation preventing file naming conflicts. You can always create a fork that behaves differently (at the risk of overwriting data). Alternatively, you can write a script in your favorite language to handle this.

[njvack]

Thanks, that kind of makes sense. But! In my dataset, it looks like every slice has its own trigger time (0018,1060) value. How am I getting a single .nii file out? How is it choosing 4582? That's not the value from either the first or last dicom in the series; in fact, I don't think it appears in any of the dicoms, which is... surprising? I have a 4581. shrug

Also I'm pretty sure we aren't using cardiac gating here, so I don't know what that trigger time is supposed to be indicating. Sigh.

[neurolabusc]

The methods dcm2niix uses are described here. The validation datasets used for the various forms of slice timing are provided here.

Since I do not have access to any GE hardware, support depends on the community. I would suggest three ways forward (which are not mutually exclusive):

• Provide public datasets that illustrate where the currently formula fails or could be extended.
• Generate a fork of dcm2niix that resolves these issues (and updates the /GE/README.md). When this is robust, generate a pull request to share your enhancements with the community.
• Lobby your GE Research Collaboration Manager to support public DICOM tags for preserving parameters that are useful for post processing (slice timing, readout time, etc).

[njvack]

I aplogize; I'm super confused. That document says (0018,1060) is used for slice timing information (which is present and looks slice-timing-ish but is probably not doing the right thing; I'll work on getting some phantom data and digging further) but I think that's totally different from TriggerDelayTime and a _t suffix for file naming?

[njvack]

Also! I know we're running a weird GE scanner with a weird headcoil; if the answer is just "this is what dcm2niix does, rename yo' files" that is totally okay, and I appreciate how well this program works given what it has to work with. Seriously: Thank you!

[njvack]

Delightfully, it looks like we're also using a research sequence, so 'just hack around stuff' is probably the correct procedure for us. I'm still not sure where it's getting this particular suffix for this particular series, but... eh, it's fine, we can work around it in postprocessing.

[neurolabusc]

The filenaming page provides general guidelines. See the Philips multiple cardiac phases dataset for an example for standard usage of trigger times (eliciting the '_t***' postfix).

The GE page describes vendor-specific kludges that attempt to extract relevant data. A major issue is that each vendor interprets DICOM differently.

If your sequences and hardware are very unusual, your issues might be specific to your center. If not, many others may experience the same problems as you. I am unable to evaluate this. Many users have contributed public validation datasets. Our tools are only as robust as the available datasets.

You can always use dcmdump or gdcmdump to view the DICOM headers. For GE this suffix should be elicited by 0018,1060 which the vendor seems to use for cardiac trigger times for some sequences and EPI acquisition times for others.

[neurolabusc]

Closing as this is a custom research sequence. Once GE supports multi-band images in their product sequences, it would be great to have validation datasets so we can understand how GE encodes these properties into DICOM and support retaining this information during NIfTI conversion.

[neurolabusc]

@njvack can you please test the latest developmental commit (v1.0.20190926). Thanks to Paul Morgan (Nottingham) for help on this. The private GE Protocol Data Block (0025,101B) is scanned for the field 'MBACCEL', with the resulting value inserted into the BIDS "MultibandAccelerationFactor" tag. There are two related changes:

1. If the manufacturer is GE, the value for Trigger Time (0018,1060) is not appended to file names. While Philips scans must be segmented based on trigger time, with GE this tag is used by some sequences for slice timing. This change means that the developmental branch will fail some regression tests until those tests are updated (as we are intentionally changing the file naming scheme).
2. While Trigger Time (0018,1060) is the only way to detect slice timing for some GE sequences, the values stored in this field clearly incorrect for GE multi band sequences (at least with GE software 27_LX_MR_Software_release:RX27.0_R02_1831.a). Specifically, the values report the timings of a single-band image acquired with the multi-band TR (i.e. each slice reports a unique trigger time, where for multi-band 2 one would expect pairs of spatially distant slices to share identical slice times). This is clearly a limitation of the GE DICOM data, and not dcm2niix. However, rather than report values that are known to be incorrect, dcm2niix will omit the slice timing field from multi-band GE sequences. Instead, it will generate a warning to the console Warning: Unabled to compute slice times for GE multi-band. SliceOrder=-1 (seq=0, int=1). The user will have to know the GE multi-band acquisition patterns (which I do not know) to infer slice times (though note that multi-band lends itself to very short TRs, where slice time correction has little impact).

[njvack]

Thanks for this! We'll give it a try.

Yeah, the reported slice times are completely wrong, it's funny because you're right, we don't slice-time correct when processing multiband. Still irks me though.

[mrgrist]

If its helpful, I can provide GE multiband data from the latest software release. Let me know.

[neurolabusc]

@mrgrist since this issue was closed, @mr-jaemin provided a validation dataset and we also provide C code for deriving timings.

[mr-jaemin]

@mrgrist Thanks. Please let me know if you don't get SliceTiming information from your GE multiband data using dcm2niix.

[mrgrist]

@mr-jaemin nothing comes through for slice timing with either the development branch or the current release in the json file. I'm running MR29.1. I've had a look at the C++ code, but i'm not really sure how to use it...

[mr-jaemin]

@mr-jaemin nothing comes through for slice timing with either the development branch or the current release in the json file. I'm running MR29.1. I've had a look at the C++ code, but i'm not really sure how to use it...

Could you please upload a sample DICOM (series as a tar/zip file)?https://gehealthcare.ent.box.com/f/3e5433ace5184a82850c6d00f8ca0d14