Rick,

<<<
How did you do the sorting, or were the files already sorted
by volume and then slice location?
>>>

I'm sorting the files using a python script and pydicom. The script first sorts by the "Temporal Position Identifier" header tag and then by increasing distance along slice location normal to the 2D image plane (calculated from information in the header). The original "problematic" files are from a Philips scanner and come off the scanner ordered in slice and then volume rather than volume and then slice. This is the data that I have not been able to get dimon to work with except while excluding the -dicom_org option.

<<<
It is a little strange that you needed to use 3dresample to
fix the -dicom_org dataset, which suggests there is some
obliquity matrix that is inverted against the -dicom_org
slice ordering. But that suggests that the ordering from
the header is not actually correct, but the alphabetical
one is.
>>>

Sorry, my application of 3dresample was not very well-described in the last post and I left out some details about the data. The data I referred to in my last post, that dimon with -dicom_org has no problem reading, are from a GE scanner. I don't usually need to sort the GE files before putting them through dimon, but I wanted to check to see how the python file-sorting script was working relative to dimon with -dicom_org. The inclusion of 3dresample was to make the output of [my sorting script and dimon without -dicom_org] match the output of [dimon with -dicom_org] (I was using 3dresample on the data produced by [my sorting script and dimon without -dicom_org]). It now occurs to me that it might be a better idea to simply switch the order in which the within-volume sorting occurs (from increasing distance to decreasing distance) in my sorting script to match dimon's sorting rather than using 3dresample after-the-fact.

<<<
In any case, it sounds like the scanner is saving the files in
the correct order, though the DICOM fields are not populated
for correct sorting by Dimon.
>>>

I agree, it sounds like this is what's going on. I would still like to use dimon on the Philips data to generate a call to to3d but just need to make sure I'm accurately reorganizing the files into the correct volume/slice order from the slice/volume order in which the scanner writes them (which is what led me to test the output of [my script and dimon without -dicom_org] against the output of [dimon with -dicom_org] for the GE data).

Thanks,
-John