I have a question about running Dimon. I have two scans from a GE scanner, the first was collected sequentially, the second collected interleaved. No matter what I try with Dimon, it instructs to3d to run with “alt+z” tpattern. In the directory with the DICOM files, I’ve ran the following:
Dimon -infile_pattern “*.dcm”
I’ve tried using both:
It chokes using the “-sp” call. Sorting by acq time has zero effect. I tried digging into the source code on github and it looks like it’s using “0008,0032” (ID Acquisition Time) for the time, but that field is exactly the same in every DICOM in the series. Further, field “0021,105E” (RTIA_timer) would be a great second-check on the slice time but it often isn’t set, or is set to 0, withing a run (a GE problem?).
Given that I have sequential and interleaved data, I would have thought Dimon would prescribe seq+z and alt+z respectively, but it looks to treat every file as interleaved. Is there a way (or a flag) to force Dimon to respect the slice timing?
Thank you for taking the time to read this.
There is no option to force Dimon “to respect the slice timing”
(except for “-sp FROM_IMAGE”), because one cannot generally
rely on DICOM files to contain reliable slice timing information.
The FROM_IMAGE method for to3d really only applies to Siemens
You were very close though, using -sp. See the Dimon help on that.
You can specify whatever pattern is appropriate with that option,
e.g. “-sp seq” or “-sp alt+z”.
But the basic point is that you cannot expect it to come from the
GE DICOM files.
Thank you for your response. As a follow-up, If I want to use Dimon or to3d, I’ll need to set the tpattern and I have a few questions about this.
With our data we pull out the following:
slice instance (DICOM field 0020,0013 (REL Instance Number))
slice location (DICOM field 0020,1041 (REL Slice Location))
If I have two sets of data, both axial collection, both sequential, with the following information:
slice instance slice location (descending)
slice instance slice location (ascending)
How would I set the corresponding tpattern? Would the descending example be seq-z (sequential in the minus direction) and the ascending example be seq+z (sequential in the plus direction)? Is the z-direction referring to increasing or decreasing z-values (slice location values)? I’m confused because the slice number layout in the man page shows slice number and inter-slice time (0-800 and 800-0) which I would interpret as slice 1-5 and 5-1.
This plus or minus is a subtle point of confusion. That
does not refer to the sign of the direction of z-coordinates,
but whether the timing matches the order of slices on disk.
So for axial slices, seq-z would be appropriate in either
of 2 cases: where slices are I->S but aquisition times were
actually S->I or the reverse, where slices are S->I but the
aquisition times were I->S. The seq+z case is for when they
Does that seem reasonable?
Why would anyone want to collect with a “-z” option? That seems really counter-intuitive.
For the sake of argument… let’s say we have a mystery DICOM set collected elsewhere and don’t have access to the original protocol or access to the techs or machine that acquired said data. If we can’t reliably gather slice timing info from GE DICOM, how can we tell if we need, say, seq+z or seq-z?
If you cannot tell, use simult, for simultaneous.
That means not doing any slice timing correction.