Wrap around is a conversion issue? to3d Dimon

AFNI Message Board
1

Hi there,

I have some nifti files that have the back of the brain cut off and wrapping around to the front of the image. It gets worse over runs, as it looks like the head moves back in the frame more over time.

https://ibb.co/Y2rPHZ8

I have the suspicion that this is caused by the FOV for the scanner not being positioned correctly - and then motion of the head backwards over runs making that worse. But I thought this would just lead to the brain being cut off at the back, not wrapping around to the front.

My other thought was maybe it was something to do with converting the file from dicom to nifti - as I have been getting some image position type warnings (see below). Could you let me know if you think that image conversion could have anything to do with this wrap issue?

And if so, whether you think it is better to a) just run pre-processing with the files the way they are? b) cut off the wrapped bit from the front and pre-process? c) try glue the wrap back on to the back and pre-process. We are looking at the hand knob, so missing some occipital should be ok.

Note: the output from all conversion attempts look the same

Thank you for your help,

Harriet

Conversion attempts and warnings

  1. dcm2niix

"slices stacked despite varying acquisition numbers (if this is not desired recompile with ‘mySegmentByAcq’)Warning: ParallelReductionFactorInPlane reported in DICOM [0051,1011] (4) does not match CSA series value 2”

I tried running the below to account for this but it did not work
dcm2niix_afni mySegmentByAcq [path]

  1. Dimon

Dimon -infile_prefix 00
-gert_create_dataset
-gert_write_as_nifti
-gert_to3d_prefix to3d_run6
-gert_outdir …
-dicom_org
-use_last_elem
-save_details Dimon.details
-gert_quit_on_err

I get some warnings along the lines of

  • Image positions do not lie in the same position as the cross-product vector
  • Slice based centre is different from mosaic centre
  • Origin computation of obliquity may be incorrect

Also, it appears to be ordered in the reverse order e.g., 2 is midline, where other conversion 244 was midline. Which is weird

I have tried Dicom with the unique list function, with same results

  1. mrconvert

for some background, I also tried converting using mrconvert and got this warning

[WARNING] Number of entries in mosaic slice timing (0) does not match number of images in mosaic (48); omitting

2

Sorry, here is link to the image, I cant get the embed to work

https://photos.app.goo.gl/eocAdgDYrkAvexD3A

3

Hi Harriet,

You are likely correct that the FOV was not well centered.

One clear point to make is that in your trio of images, the square one shows the issue, and the square one should be the actual acquisition image. The DICOM to NIFTI conversion programs should preserve those individual images (though dcm2niix reorients them by default), so part of such an image should not be moved around.

What to do about it (besides trying normal processing) is not clear. Moving/gluing the one part seems challenging, as it moves over time. Even if it did not move, I might not advise it.

Dimon and dcm2niix might produce different orientations for the volumes since Dimon leaves the data as is, while dcm2niix reorients to RPI by default. That difference should not be an issue.

  • rick
4

Thank you Rick - normal processing seems to work fine, the wrapped bit of brain just disappears in the alignment step as we are aligning our epi to our anatomical

5

That’s great, thanks for the update.

  • rick