Have the auto-align matrix as a key:value pairs in the JSON file

[Proulx-S]

Hello,

The developers of dcm2niix referred me here for this feature proposal (see rordenlab/dcm2niix#944).

Background on auto-align

This is a process by Siemens where a short full-head scout is acquired before each run (of e.g. BOLD fMRI) and automatically registered to the first of the scouts to track the position of the head. The transformation matrix from that registration is then applied to the slice prescription of the following run so that it follows the changing head pose. The end result is that the brain remains conveniently aligned in image space despite different poses across runs in scanner space. For partial fov acquisitions (e.g. single slice fMRI in my case), this is crucial for stable measurement of the same brain tissue across runs and sessions in the same subject.

Importantly, all this information, i.e. (1) the original slice prescription, (2) the transformation matrix applied to it and (3) and the transformed slice prescription, ends up in the dicom header. In the nifti however, it seems there is only (3).

The problem

Having the brain already aligned in image space is great, but visualization softwares most often display those images using slice prescription in scanner space, so they appear misaligned. The different slice prescription between runs also complexifies registration. I had some success circumventing these issues by rewriting the data from different runs using the header from the first run, but that does not work when e.g. voxel sizes are not the same, and I so far failed to similarly adjust the header with other tools.

Why auto-align information should be in the JSON file

Solving the issue I think involve changing header information so that auto-aligned runs are now pretended to have been acquired using the same scanner-space slice prescription. The cleanest way to achieve that would to, as the very first step of preprocessing, apply the inverse of the auto-align matrix. Right now this is only found in the dicom that often gets discarded after conversion to nifti. Ideally, nifti would preserve that information but that might be too big of a boat to steer. A new key:value pair in the JSON file for the auto-aligned matrix (and maybe also for the original, non-auto-aligned slice prescription) seems the cleanest and most straightforward to me.

I'm not sure how frequently people use auto-align for very limited fov data, but I have been for a few years now and still struggling.

Alternatives for the future

For now, I'll dig the auto-align matrix out of the dicom, but I hope to get it from the JSON in the future. If auto-align and variants become more of a thing, a flag in dcm2niix allowing the user to choose whether the nifti header gets the original or auto-aligned slice prescription would be awesome.

Thanks a lot for your attention and
Keep up the good work!
Sébastien

[mharms]

The "original slice prescription" when using AutoAlign is going to be whatever your specified Position and Orientation settings (e.g, Position = L0.0 P0.0 H6.0 mm; Orientation = T > C-16.0) translate into in scanner space. How is that useful to know? I'm not sure what you've all tried, but if you just want to trick software/viewers into thinking all the runs were acquired in the same space (i.e., some space referenced to the individual's own anatomy), it should indeed be possible to accomplish that by hacking the NIFTI header.

Nonetheless, perhaps you could provide an example of the 3 different sets of information in the DICOM header that you are referring to?

[Proulx-S]

Here are the dicom information I found. I am not sure what is what, but I would bet that the first set is (3) and the second is (1). (2) might be private...

sSliceArray.asSlice[0].dThickness = 1.2
sSliceArray.asSlice[0].dPhaseFOV = 160.0
sSliceArray.asSlice[0].dReadoutFOV = 160.0
sSliceArray.asSlice[0].dInPlaneRot = -0.0111701072128
sSliceArray.asSlice[0].sPosition.dSag = -0.264335381152
sSliceArray.asSlice[0].sPosition.dCor = 44.5102640277
sSliceArray.asSlice[0].sPosition.dTra = -15.5686419485
sSliceArray.asSlice[0].sNormal.dSag = -0.00444521287
sSliceArray.asSlice[0].sNormal.dCor = 0.9281407533
sSliceArray.asSlice[0].sNormal.dTra = -0.3722029497

sAAInitialOffset.Laterality = 0
sAAInitialOffset.SliceInformation.sPosition.dSag = -0.130337218407
sAAInitialOffset.SliceInformation.sPosition.dCor = 44.3457814828
sAAInitialOffset.SliceInformation.sPosition.dTra = -16.6341695851
sAAInitialOffset.SliceInformation.sNormal.dSag = 2.17428072068e-013
sAAInitialOffset.SliceInformation.sNormal.dCor = 0.927183854584
sAAInitialOffset.SliceInformation.sNormal.dTra = -0.374606593373

[mharms]

It sounded like you had already worked out what you wanted to do, using the DICOM header. Is that not the case?

Looking at the DICOM from two different sessions on two different Siemens scanners (one XA30, one VE11), where I know that the Position/Orientation values in the stored protocol (prior to the application of AutoAlign) were Position = L0.0 P0.0 H6.0 mm; Orientation = T > C-16.0, and ignoring very small values representing rounding errors, both of them had (rounding to 4 decimal points):

sAAInitialOffset.SliceInformation.sPosition.dTra	 = 	6.0000
sAAInitialOffset.SliceInformation.sNormal.dCor	 = 	0.2756
sAAInitialOffset.SliceInformation.sNormal.dTra	 = 	0.9613

So, yes, the sAAInitialOffset fields do appear to encode the Position/Orientation offsets stored in the protocol that AutoAlign then subsequently applies at execution.

But it is still unclear to me what you want to do with this information. As far as I can tell, all it is really telling you is what those Position/Orientation values were set to in the saved protocol (albeit, converted to Siemens sPosition and sNormal format for specifying translations and angles).

[mharms]

Also, it is worth mentioning that the above bit of "reverse engineering" doesn't tell us anything about what those sAAInitialOffset values end up representing if the user manually adjusts the FOV returned by AutoAlign. In that situation, they may just continue to reflect the Position/Orientation values originally stored in the protocol, but the application of a subsequent manual adjustment would mean that there is no knowable transform between the AutoAlign parameters and the final FOV in scanner space.

[Proulx-S]

Thanks for your interest @mharms. Part of the issue is worked out indeed. I summarized where I'm at, along with example and code, in this repo (https://github.com/Proulx-S/dcmAAtest). Hopefully the goal will be clearer to you there. Spoiler alert, I kinda can do what I want directly in the dicom but something is off. You are more then welcome to have a look is you can spare the time :-)

You are right about the possibility of someone adjusting the prescription orientation/position after AutoAlign. I can see that happening rarely but not never (I already did that once or twice), so a robust solution would have to account for that and I really don't know how.

Thanks for your attention!

[mharms]

Also, this may be irrelevant, but your description of AutoAlign is not my understanding of how it works. In particular, the AAHScout scan is not "registered to the first of the scouts". Rather, the "AAHScout" scan is used to identify the location of the brain in the scanner space per an algorithm that is controlled by the selected "AutoAlign" setting. Once the position of the brain is known within the scanner space, the requested Position and Orientation offsets can be applied relative to the anatomy. Yes, it can be represented as a composition of transforms, but my understanding is that the process doesn't involve any registration of the AAHScout scan to the "first of the scouts".

[Proulx-S]

Your understanding of AutoAlign sounds better than mine. Mine comes from a hack of AutoAlign (Paul Wighton et al. ISMRM2024 #4676) where we perform registration ourselves and feed the info back to AutoAlign. That may be an extra level of complexity but the details of how the spatial transformation is obtained should indeed not matter. Am I right @pwighton?

[pwighton]

Yes, @Proulx-S and I are essentially hacking AutoRegister to do custom FOV prescription. We have an ICE functor that can receive a 4x4 matrix from a socket and overwrite the AutoAlign matrix on the scanner. You're understanding of AutoAlign is consistent with mine, @mharms.