I have a 12-slice, 16-echo T2 dataset which is currently ordered as: TE0(slice0…slice11), TE1(slice0…slice11),…, TE15(slice0…slice11). We need to reorder it to slice0(TE0, TE1,…, TE15), slice1(TE0, TE1,…, TE15),…, slice11(TE0, TE1,…, TE15). Is there an AFNI utility that can do this efficiently?
I’m a bit rusty with AFNI, so although I know I can “address” the TE dimension as [0], [1], …, [15], I don’t know how to “address” the slice dimension or how to “glue” everything back together – 3dTcat? 3dbucket? 3dcalc? Any advice you could provide would be greatly appreciated!
Is this in DICOM format or NIFTI (or AFNI)? It seems like you are starting with a 4D dataset that needs to have the slices transposed. Is that right? Or do you want a set of individual slice files?
Thanks for the response, Rick. This data is already in a NIfTI format, and you’re correct in that it’s a 4D dataset in need of transposition. I could manage it if the output were slice files – I can always “reassemble” them in a BASH script – but was hoping there might be a way to avoid the steps of (1) generating (16 echoes x 12 slices = )192 image files and (2) “gluing” them back together.
Just wanted to check back in with you to see if you’d had any ideas. I’ve been trying to figure it out myself but without much luck, and although I’ve located the original DICOMs, dealing with them has proven to be even more painful as the slice-echo order I get from to3d is incorrect, no matter what “tpattern” I try.
My vote would be to use 3dTcat to break them into individual TR files, and then 3dZcutup to slice up the individual slices. Then reassemble with 3dZcat and 3dTcat. You can also use 3dTsplit4D in place of the initial 3dTcat.
If you have the original DICOM files, then Dimon has different options for sorting via -dicom_org.
If you try that, start by including “-save_details DET”, and feel free to send me the DET* text files via email.
But I don’t actually see why you would want the files in the order slice0(TE0, TE1,…, TE15), slice1(TE0, TE1,…, TE15),…
To be sure, currently the first apparent “volume” (in the afni GUI, say) is all slice 0, is that right? That would seem like the thing to fix. But the wording has me a little confused.
Agreed, this is not the “natural” way I’d expect a multi-echo to be structured. The request comes from a physician-researcher colleague who’s interested in expediting manual ROI drawing across multiple subjects in OsiriX. I believe she wants to select the same slice in each subject (the acquisitions are carefully aligned with anatomical landmarks) and iterate her ROI placement over each subject. But yes, CURRENTLY the first apparent “volume” is slice 0, first echo, so selecting the next index/“‘time’ coordinate” in AFNI stays on slice 0 but goes to the second echo. I think the issue is how the 4D dataset gets “stacked” when converted back to DICOM in XMedCon and pulled into OsiriX, but there doesn’t seem to be any easy way to change that in XMedCon.
Confusing and odd, I know. I’m going to try Peter’s suggestion and touch base with you if I have any further questions. Thanks again!
Okay, I hope it works out well. Please feel free to send me the Dimon “details” files.
rick
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.