Not sure if this is the best place to ask, but I was hoping for some feedback since I can’t find any obvious solutions elsewhere! (plus you’re all such friendly people anyway )
We’re trying to get a new set of scanner sequences running, and the plan was to basically copy-paste them from another study which has been running for awhile now. We collected anatomical MRI data from a test subject, popped the data into a viewing program, clicked the “origin” button (in world-coordinate space), and it placed the cursor right around the AC/PC line.
We went to collect test data again, used a slightly different sequence, and when we clicked the “origin” button it placed the cursor in the frontal sinus…We collected more data today, and it’s the same thing - origin is in the frontal sinus, at least as far as I can tell. I even watched the scan tech place the bounding box, and the middle appeared to be right around the AC/PC region. I added an image showing the location of the (0,0,0) cursor below (I used fsleyes, and had it set to display the image in “world space”).
As I understand it, this is a big deal! At least with SPM, the normalization routine basically requires that the origin be set around the AC/PC line. I tried looking up info for other software (e.g., fsl/afni) and was only able to find that it might matter for those programs, but it wasn’t clear to what degree that was true.
Any advice on how to handle this (or if it even matters) is appreciated! Feeling totally stumped by this…
TLDR; It depends on the tools you use. Most modern tools are very robust to starting estimate. You can always use a script to set the position (only adjusting the origin, not reslicing the data which requires interpolation).
For a MRI image saved in DICOM format, the origin is the magnet isocenter. When you convert your DICOM to NIfTI with a tool like dcm2niix it losslessly converts this origin. Therefore, the initial position of the origin depends on how the participant was loaded into the scanner. On our Siemens system, some operators use the laser to set the position of the isocenter near the eye-brows, and for most head coils this results in isocenter being near the anterior commissure. On the other hand, other operators use the default isocenter, which for a head-neck coil tends to place the isocenter further in the foot direction, as shown in your image.
The origin for typical neuroimaging templates is the anterior commissure. Some normalization and coregistration tools use the origin as a starting estimate, and if they are very different the image will get trapped in a local minima. My historical experience (which might be biased or out of date is):
- FSL’s FLIRT uses the
center of brightness as a starting estimate, so it is not perturbed by the NIfTI origin unless the user specifies the
- SPM8’s 3-tissue unified normalization segmentation was very sensitive to the origin. You should either manually set the origin or use a lossless automated method like my nii_setOrigin
- SPM12’s 6 tissue unified normalization (which adds models for bone, air, and non-brain soft tissue) is quite robust for origin.
- ANTS appears to use a mutual information cost function for the first alignment, and is also very robust. Be aware that VTK-based tools like ANTs use the Q-Form for the origin, while SPM and most other tools give precedence to the S-Form. If you do reset the origin manually or with a script, make sure it changes BOTH spatial transforms.
My advice to you is to have a simple quality assurance stage that ensures your normalization works. If your starting estimate is near-enough, the iterative normalization transform will enjoy a virtuous cycle of converging closer and closer to the correct solution. When normalization fails due to a bad starting estimate, it will converge on a very incorrect solution. The image below shows my own method for checking normalization, where I mask the T1 scan with the gray and white matter tissue probability maps. Since segmentation and normalization are a virtuous cycle (good normalization improves segmentation, good segmentation improves normalization, repeat both steps to converge on better solution), a good solution will look like a brain to the human eye, while a poor solution will include non-brain features like the optic nerve.
Thank you for such a helpful response! This community is the absolute best
I didn’t realize conversion tools adjusted the origin, and it’s interesting that how a participant is loaded into the scanner affects the initial origin (although, in hindsight, I guess that makes sense!). I was most used to the SPM8 minima issue, and didn’t know how other software worked, so I really appreciate you explaining the differences.
We just started collecting pilot data, and were a little unsure if we should be concerned or not about the origin issue (or if we should do anything before we collected anymore data), so your reply definitely clears up a lot of the mystery - once again, thank you so much!!
On a related note, since FSL uses the
center of brightness as its starting estimate, it can be very sensitive to brightness outside the brain, in particular if your field of view includes the neck and shoulders (especially for T1 scans with participants who have thick fat layers in their neck and shoulder). These scans can also trip up other tools as well. One option is to use the dcm2niix
-x y option, which attempts to crop excess neck from a T1 scan. This explains why my set origin script provides an option to crop the bounding box (removing excess neck/shoulders). Alternatively, you could add logic into a defacing script if you use one.
Ah, thank you for the clarification, and additionally, for your scripts! It’s always helpful to have more options for data processing. As I’ve been learning more and more about neuroimaging, it seems pretty common that there will be specific circumstances which you must adapt to regarding your data…