Oblique EPI with Dimon

AFNI Message Board
1

Hi, it is my very first time with afni and I am having problems with the creation of the afni dataset from dicom images.

I runned:


Dimon -infile_prefix IM -gert_create_dataset

and I got this error:


Dimon version 4.18 (November 9, 2016) running, use <ctrl-c> to quit...

-- scanning for first volume
++ Data detected to be oblique
** cannot find a volume in 4400 image files
   (max allowable = 3000, see -max_images)

As I want to keep my EPI dataset oblique I added the -use_obl_origin option running:


Dimon -infile_prefix IM -gert_create_dataset -use_obl_origin

but I still get the same error. How can I deal with this issue?

Thanks,
Marta

2

Hi Marta,

That probably means the alphabetical ordering given to
Dimon is not the correct one. Try adding -dicom_org.
If that does not work, we can get more information.

  • rick
3

Hello,

I have a question about using Dimon to convert dcm images to epi BRIK files. I have been looking for threads on the following error message pasted below, and was doing the troubleshooting as recommended by Rick in this prior thread. I did actually add -use_obl_origin and added -dicom_org to my command line as well, but I’m still getting the error below my signature with the following command:

Dimon -infile_pattern ‘*.dcm’ -gert_create_dataset -gert_to3d_prefix epi -use_obl_origin -dicom_org -quit

Any thoughts?

Thanks in advance for any assistance that you might be able to provide.

Best,
Aviva Olsavsky

++ Data detected to be oblique
*+ WARNING: Slice-based center is different from mosaic center
*+ WARNING: Origin computation of obliquity may be incorrect
Mosaic Center : -3.15875 -6.77804 13.7164
Slice-based Center: -1.65876 -5.27847 13.6798

rick reynolds Wrote:

Hi Marta,

That probably means the alphabetical ordering
given to
Dimon is not the correct one. Try adding
-dicom_org.
If that does not work, we can get more
information.

  • rick
4

That’s just a warning message saying there’s some inconsistency between origins computed two different ways. Very often, these two coordinates are the same, but scanner manufacturers may supply these differently in their DICOM headers. With the “-use_obl_origin”, you choose the origin computed a more complicated way for the oblique origin, but it is very often the more useful.

5

Some more explanation and details…
Usually it won’t matter either way. It can matter though if the two kinds of origins are in very different locations. If the data is oblique and the origins are far apart, then the data may be tilted too much out of its grid during alignment. If the data is not oblique, it might matter too because one or the other kind of origin may not be correct relative to another scan during the same session. The only way I can think to be sure which origin is correct for cardinal (non-oblique) data is to use the overlay and show the two datasets over each other. The difference in your example is probably about half a voxel in two directions, unlikely to affect too much of the processing.

For oblique data, the transformations use whichever origins are actually in the headers of the AFNI or NIFTI datasets. You can’t visualize two differently oblique datasets in AFNI, but you can use 3dWarp -card2oblique to match one to the other and then view that. For NIFTI datasets, you will use only the equivalent of the oblique origin. There is no separate cardinal origin defined for the NIFTI header, only for the AFNI header. In general, we find the oblique origin to be more often the more accurate number, but the method to compute the oblique information is completely reverse engineered from the scanner manufacturers’ DICOM files and varies from one scanner to another. It’s fairly complicated (particularly for Siemens mosaic data, as in your case), so I’m not completely sure either will work on your scanner. It’s best to try. Besides our Dimon and to3d programs, we now also supply dcm2niix with AFNI. You can also evaluate origins using other software that reads DICOM files like mri_convert from the FreeSurfer package and a number of other software packages. Each will likely give you at least slightly different results.