Automatic naming of first echo in multi-echo data

[mharms]

Currently, in the case of multi-echo data, the automatic "image disambiguation" rules (https://github.com/rordenlab/dcm2niix/blob/master/FILENAMING.md) add an _e? extension only for the 2nd and latter echos. The filename for the first echo does not include _e1.

Would anyone object to changing this so that the filename for the first echo ends in _e1?

[wtclarke]

I would support this change on the condition that single-echo data would not have an additional _e1 added. But I presume this is what is meant!

[neurolabusc]

• I think @captainnova is also in favor of this change. Can those interested in this please test the latest commit - this changes the filenaming behavior so for the latest commit the behavior is _e1..eN echo number for multi-echo sequences.
• The latest commit also includes a filenaming change suggested by @wexeee - in previous versions file names were restricted to characters allowed by the local operating system. This meant that in theory a copy of dcm2niix running on Linux could create a filename with an illegal character for windows (e.g. <). The new behavior is to restrict characters to those allowed by any operating system. This ensures consistent (though more restrictive) file naming for scripts, and ensures files can be easily copied between systems. The new behavior is described in the filenaming page.
• To test these changes, the two compiler directives myMultiEchoFilenameSkipEcho1 and myOsSpecificFilenameMask will revert to the old filenaming behavior.
• I have one question for @chrisfilo, currently dcm2niix only inserts the EchoNumber tag into the BIDS header if EchoNumber is greater than 1 (e.g. if this tag is not listed, the echo number is assumed to be 1). Is this the desired behavior, or should first echo for a multi-echo sequence explicitly report"EchoNumber": 1,?

[chrisgorgo]

I have to say I have no strong opinion on EchoNumber. It has not been yet brought up in context of BIDS or processing of multi-echo data. @emdupre might have more to say.

[emdupre]

Right now we only include echo number in the filename (and I think explicitly including that extension for echo-1 would be a great addition !).

One reason BIDS doesn't yet list EchoNumber in the json is that ensuring the echo with the lowest TE is "echo 1" was pushed off until BIDS 2.0 as a breaking change, so we have to explicitly check the TEs for ordering.

That being said, if you're adding the EchoNumber tag for other echos, it might be nice to also list it for the first echo-- it could be a nice way to select multi-echo data.

[mharms]

I would also advocate that for multi-echo data every json should include the value of (0018,0086) ("EchoNumbers"), which means that the first echo would have a corresponding EchoNumber tag in the json as well.

[captainnova]

We do favor the change here at Mayo, with @wexeee 's specification that this would not affect single echo data. However, we usually use -m to merge files that would be split, so it's a bit academic in our case.

[neurolabusc]

I am closing this issue - the new behavior suggested by @mharms has received consensus support and appears to work as expected based on limited user feedback.

For completeness, it is worth mentioning that the -m y feature used by @captainnova will often but not always give the same result as converting the images with -m n and then merging the resulting volumes. The -m y feature was designed to deal with special situations, for example how some CT sequences are intended to be stacked regardless of x-ray exposure while other centers using the same equipment have sequences where this is the incorrect behavior. In these cases, there is no way to be 100% sure of the users intention, so we need to have an explicit switch. I strongly advise most users to use the default behavior (-m n) unless you carefully validate the results (as @captainnova does). I know for a fact that the -m y feature will not work well some Philips Enhanced MRI datasets.

In general, if you want to safely combine multi-echo MRI files as a single 4D volume, I suggest you use -m n and then stack the files. Alternatively, if anyone wants to create a pull request to handle complex MRI, I am happy to provide edge cases where -m y fails.