I’m in the process of writing a script to sort & rename lots of dicom files based on information in the dicom header. Ideally I wanted to include the series description (dicom field “0008,103e”) as part of the output directory name (with spaces replaced with underscores, using sed). However, dicom_hinfo only returns the first word of the series description. I could use dcmdump from DCMTK, but dicom_hinfo is a lot faster. I could use dicom_hdr & grep, but I’m not sure how I’d grep for multiple elements (instance number, series description, etc.) without reading in the header multiple times. I need to read through tens of thousands of dicom files, so speed is an issue.
Is there a way for dicom_hinfo to output the entire field for series description, rather than just the first word?
In my testing, I find that dcmdump is slightly faster than dicom_hinfo.
I ran 10,000 dicoms with:
dicom_hinfo -tag 0008,103e 00001.dcm
dcmdump --print-short --search 0008,103e 00001.dcm
dicom_hinfo = 183 seconds
dcmdump = 145 seconds
But we should look into updating dicom_hinfo for the entire field and not just the first word.
Thanks for the info.
On my system, dicom_hinfo was a bit faster than dcmdump when run in a “foreach” loop in c-shell. However, I just discovered that dcmdump can read multiple dicom files at once, so that will speed things up a bit.
We updated dicom_hinfo to output the full entry (with spaces).
After updating afni, just add -full_entry like this:
dicom_hinfo -full_entry -tag 0008,0081 00001.dcm
Let me know if you run into any issues with it.
Happy New Year A-Team!
Following up on Rasmus’ request.
Would it be possible to add a -separator option to dicom_hinfo so that one could reliably split multi tag output into columns? Using space as a separator would not work when fields have spaces in them. Alternately, or additionally, one could request that space characters within a field value be replaced with ‘_’, say. That would make parsing columns with space as delimiter work fine.
There is now a -sepstr option to dicom_hinfo. That is in the
current set of binaries, version AFNI_19.0.00.
Please let me know if you have any questions about it.
You rock, as usual, RickR!
My version check tells me I am at AFNI_18.1.18 and that the latest is AFNI_19.0.01. However when I run @update.afni.binaries -d, I get a ++ no update needed message.
Oh, hey Z!
It seems likely you are running a 10.7 package, which we no longer have a build system for. Try the macos_10.12_local (which is currently the ONLY mac package we have, but which seems to work on even earlier mac systems, if you have one).
Maybe I will stick a warning for out of date packages, that would probably be more polite…
@update.afni.binaries -defaults -package macos_10.12_local
Please let me know if you run into trouble with that.
The recommendation worked, thanks!