Rick,

Thanks for the help.

I think I've got things worked out for these data: sorting the DICOM files by volume and then slice location, putting them through dimon without -dicom_org, and then running the to3d call created by dimon.

One final question (I hope):
As a check, I tried running the file sorting on some data that play nicely with the -dicom_org option and found that two BRIKs created from the data, one using -dicom_org and one NOT using -dicom_org, looked identical in the AFNI viewer. After converting them to NIFTI I opened them up with FSL (just to make sure they looked the same there, too) and found that the two images were swapped in the left-right direction. Upon further inspection it turns out that -dicom_org was reordering the slices for each volume (after my sorting) so one of the BRIKs went left-to-right and the other went right-to-left. But, this switch was properly reflected in the orientation code of each BRIK (which I'm assuming allowed AFNI to display them identically) and I just had to use 3dresample -orient to get them in the same orientation. After that, they looked the same in the FSL viewer as well.
Does using 3dresample in this way effect the timing information related to 3dTshift you mentioned in your previous post?

Thanks again,
-John