this means, that your folder contains DICOM images belonging to more than one DICOM series (in your case there are 3 distinct series). The prompt requires you to specify which one you want to convert to newDTI.mif.
I’ve been wondering a slightly different question: instead of interactively telling mrconvert which DICOM series to use, are there any switches or arguments that I can pass to mrconvert to pick out the series I want?
For instance, in my PET studies there is one particular series that I want to extract from the entire study, which I know will always contain the text, “BR_CTAC”. Can I tell mrconvert to pick out the first (or second, or nth, or some other attribute like smallest or largest image size, etc.) study with a particular text string in it?
I find it really annoying when dealing with images from different scanners and departments - it feels a bit like being at Bletchley Park every time you need to spend 10 minutes trying to decipher the near-random study description fields!
While something like this is certainly technically possible, there’s nothing currently implemented. The series selection actually occurs in the back-end of the code when a DICOM directory is loaded by anyMRtrix3 command, and isn’t actually a component of mrconvert specifically; this makes building an appropriate interface for this mechanism a little trickier.
This could be listed as a wishlist item on GitHub if you’d like; but I doubt it’s something that would be addressed in the immediate future.
Just to echo @rsmith’s comments here: I’ve often wondered about such functionality, and how that might be implemented - and invariably ended up with the same conclusion as @rsmith… However, have you looked at the documentation around scripting DICOM imports? It might already address a lot of your issues.
Otherwise, it is actually pretty simple to script this up, even as a one-liner - I’ll take you through this. Note this will only work if you have more than one series in the folder (so you actually get a listing), but only a single patient or study (so there is only one level of interaction). It should be possible to improve on this to handle these situations, but that’ll require a smarter script…
you can run mrinfo on your DICOM folder and get it abort immediately after printing out the listing by feeding in a non-numeric value to its input (using e.g. echo q |):
$ echo q | mrinfo data/DICOM
mrinfo: [done] scanning DICOM folder "data/DICOM"
Select series ('q' to abort):
0 - 45 MR images 09:55:43 AX T1 (?) [402] ORIGINAL PRIMARY PROJECTION IMAGE M FFE
1 - 40 MR images 09:55:43 COR T1 (?) [403] ORIGINAL PRIMARY PROJECTION IMAGE M FFE
2 - 40 MR images 09:55:43 SAG T1 (?) [404] ORIGINAL PRIMARY PROJECTION IMAGE M FFE
3 - 1 MR images 10:02:14 256DTI_high_iso20 SENSE (?) [501] ORIGINAL PRIMARY M_SE M SE
4 - 1 MR images 10:02:14 Reg - DTI_high_iso20 SENSE (?) [502] ORIGINAL PRIMARY M_SE M SE
5 - 180 MR images 10:08:49 COR T2 multi-eco (?) [601] ORIGINAL PRIMARY M_SE M SE
6 - 36 MR images 10:08:49 COR T2 multi-eco (?) [601] ORIGINAL PRIMARY T2 MAP T2 UNSPECIFIED
? mrinfo: [ERROR] no DICOM series selected
mrinfo: [ERROR] error opening image "data/DICOM"
You can catch the output by merging the standard error stream with the standard output stream (using 2>&1), then piping that to grep to print out the line with the relevant substring:
$ echo q | mrinfo data/DICOM 2>&1 | grep 256DTI_
3 - 1 MR images 10:02:14 256DTI_high_iso20 SENSE (?) [501] ORIGINAL PRIMARY M_SE M SE
you want to isolate the first number of the line, which you can do with awk:
Thank you - that script is excellent! I’m very grateful.
To add a twist, our nuc med department has recently replaced their SPECT scanner, with a brand new GE unit (running the Xeleris 4 platform).
It’s DICOM output is horrible, to put it simply. I had one dataset with [Slice thickness] = 8, and [Slice spacing] = -2. The actual voxels were 2 x 2 x 2. Not surprisingly this gives an incredibly distorted brain - it looked like the result of a steamroller accident. Or at least, a steamroller that only acts in the Z plane…
I’ve resorted back to using ITK-snap to make sure I’m getting legitimate images, as so far it’s the only thing that can reliably read them!
Still your script will solve my MRI and PET problems. Thank you!
Just to update, and possibly save people out there who may be dealing with functional data from wasting time, I have found out what was wrong with our new SPECT data.
It turns out there was nothing wrong with the new scanner itself. By pure coincidence, the department had also purchased a software package for statistical SPECT analysis that had been planned for a long time. This application (Q.Brain) performs a warp (affine or possibly higher level) of the raw SPECT data, into a template space. The template is one provided by GE, a mean template from 66 normal subjects.
The department was only exporting the warped, transformed SPECT data to our central PACS. Thus all of the brains I had access to were pre-warped, and my attempts to re-coregister them to an MRI template failed badly. This is not surprising.
The lesson I learnt is: make sure you’re getting the raw, unprocessed data!