I added the BIDS suffixes in the last release after another request on this board. Actually what happened here is that you have two recognized strings ("T1w" and "MPRAGE") in the same filename, and I didn't code it to understand that some strings are aliases of the same type, i.e. not in conflict with each other. I tried to help people by adding more strings, and it bit me by not accounting for some inputs having >1 string (even though MPRAGE and _T1w together would be a pretty common name from dcm2niix). I agree that recognizing BIDS names is a worthy goal, but BIDS suffixes aren't detailed enough to handle everything (e.g. PET types you listed). Maybe the best answer is to prioritize BIDS suffixes when they exist and fall back to the rest when they don't. I think that would work, but I'll test some examples and think on it. That seems easier than building an "aliases" logic. Either way, thanks for reporting this. It's new to me, and I agree it's a bug.
That said, if you're planning this at large scale, I'd suggest your wrapper-scripts make use of the -imType option rather than rely on the guessing. The taxonomy of image types and common names in the wild is just too complicated to rely on it entirely. PET tracers have multiple names. Sometimes MR sequences have different vendor names too. Most of the time we assume "FLAIR" means T2-FLAIR, but "T1 FLAIR" exist and should be de-faced like a T1. It's complex. I will try to improve things because your example is definitely a common case that should work, but it'll never be perfect.
Chris
Threaded View
| Title | Author | Date |
|---|---|---|
| Paul Wright | Apr 20, 2026 | |
| Christopher Schwarz | 3 hours ago | |
