MRTRIX3 is a wonderful tool, so useful that I would like to use it as an integral part of a pipeline for several different modalities. In particular, the mrinfo command is useful to automate the exploration and extraction of DICOM files.
However, I cannot find how to use mrinfo to 1- print the list of dicoms and return ; 2- select the dicom modality we want to convert/process as a commandline argument without going through the interactive selection menu.
Is there any way to do that? If not, how can I edit the sourcecode (where should I look at, I tried to look inside mrinfo.cpp but I cannot find how to do any of these).
Hi, when you say print the list of the dicoms, do you mean the *.dcm files? or the list of acquisitions inside a single dicom folder or tree?
Have you also seen dcminfo and dcmedit?
It depends on what you want to do, but maybe you could write an interactive bash script to solve the problem.
Good to hear all this time spent coding up the DICOM import hasn’t been wasted
You’ll find all the DICOM handling code in
image.cpp file is probably most relevant to you here. Bear in mind that DICOM handling on MRtrix differs substantially from most other utilities I’m aware of, in that it only parses the bits we’re interested in - we don’t form the full tree of DICOM tags like other libraries might. See this recent post for some related information.
One way to kind of do what you’re asking in your first question is a trick I use in scripts when I already know what answers I need to provide to select the right series: feed your ready-made answers through
stdin. For example:
echo "1 5" | mrinfo DICOM/
would select study/patient 1, then series 5 - depending on what’s actually in the folder. But this assumes you already know what’s in the folder. In your case, you can feed in “q” to abort straight away, in which case you’d get a dump of the first level of hierarchy that
mrinfo came across. The problem there is that if there’s only one patient in there, then it’ll look at the study level, and if there’s only one study, it’ll look at the series level, and if there’s only one series, it’ll just run with that. So it’s not necessarily going to give you a full breakdown of the contents, which is what you’re after.
My guess is, you’ll want to write a small app using the
DICOM::QuickScan class, which is designed to do a quick, but thorough scan through the full folder hierarchy and build the contents tree. You’d then be able to iterate through the list and print out whatever info you’re after. It’s not difficult, but understandably a lot easier if you’re familiar with the MRtrix codebase… I’m happy to give you a hand with that if you want to pursue it.
As to the second question, selection by modality is a very unusual use case… My guess is if you can write an app to dump the contents, you can probably script something up to select the series you’re interested by whatever criterion you’re interested in. I think that would be the path of least resistance… I’ve often thought about allowing for DICOM selection at the command-line, but given how integrated DICOM handling within the MRtrix backend, it’s hard to see how to do this cleanly - i.e. without adding options to all MRtrix apps in the process, etc…
Thank you for your fast replies guys!
That’s great, exactly what i needed!
The feeding to stdin is enough for me to work with, and with your indications @jdtournier i can check the output to detect in what mode we are in (quickscan, subject, session info, etc).
But indeed if I could use the API QUICKSCAN, it would be more reliable. However I am using Python, do you think it’s possible to access the API (without Cython)?
And I understand that it would be complicated to change basically the whole input selection to implement usual batch scripting, but the stdin technic works great and is simple, maybe you can add it to the online documentation (in a section “batch scripting” or “batch processing” or “integration in scripts” ?).
No, I’m afraid not. It might be possible to achieve this in future using e.g. swig to create a python module, but this is definitely not something I would have the time to do. Maybe someone with experience in producing pre-compiled python plugins might be able to help…
Good suggestion. I’ll try to do this when I find the time… Alternatively, feel free to add it to the docs yourself (in the
docs folder, in restructured text format) and create a pull request for it, that would be a huge help…