understanding RandomMotion

[romainVala]

Hello
I would like to understand what is the rational behind the demean of the affine transforms.

If I understand correctly you divide each affine by the weighted mean of the affine.
(where the weighted correspond to the time duration the object is in the possition given by the affine)

thanks

[ricshaw]

Hello,

The rationale behind demeaning the affine transforms is that we want the position of the brain to be in roughly the same position as the segmentation label, i.e. we don't want the brain to move when applying the motion artefact. Therefore, when applying a random sequence of motions, we have to undo the geometric mean by dividing by the weighted average transform.

However, the weight should not only depend on the time duration the object is in each position, but also the frequencies acquired at each position. For example, if the brain moves in the outer k-space region, this corresponds to high frequencies, and therefore the contribution of that position to the final image is less. But if the motion happens close to the k-space center, this corresponds to low frequencies which have a greater impact on the final position of the brain. In this implementation, the weighting is simply the time spent in each position, and the effect of acquiring different frequencies is mitigated by replacing the center of the k-space with the original k-space - essentially ignoring very low frequencies to keep most of the brain signal in the same position.

[romainVala]

Thanks for the explanation.
but as you point, it is not clear what should be the right weight. (taking into account the frequencies), and I am not sure there are some theoretical explanation ...

I did a simple experience with adding only one motion at different moment of the k space (with a simplified code that do not include neither demean nor sort_spectra).
for instance with variing position 0.2 0.4 0.6 0.8. I observe that the symetric positions of the kspace (0.2 / 0.8) are very similar (in term of artefacts) expect a global motion : after 0.5 there is a global motion in the output volume. My understanding is the the affine position present at the center of the kspace will drive the main position of the image.
So the simple way to avoid it is to just to "substract" to all affine the affine in the kspace. ie we want identidy in the center of the kspace
( *"substract" would mean to multiply all affine by the inverse of the affine at the center of kspace )

In other word we want the identity matrix in the center of the kspace, this is what is done, if I understand correctly, with the funciton sort_spectra no

[romainVala]

I still do not fully understand, but to make thing more concrete here is an example
of one translation happening at 0.48 (ie just before kspace)
here is the result

there is no global motion
if I remove the sort

if I remove the deman (but keep the sort)

In all case I get the same translation :
[-5.1, 42.7, 23.8]

so if I do not performe the demean the first part of the fourier plane is acquier with
(0.0, -0.0, -0.0, 0.0, 0.0, 0.0)
and the second with
(0.0, -0.0, -0.0, -5.1077880859375, 42.71876525878906, 23.807273864746094)

if I do the demean
the first part is performed with
(0.0, -0.0, -0.0, 2.6419533130792843, -22.09586253526004, -12.314079011131753)
and the second with
(0.0, -0.0, -0.0, -2.4658347728582157, 20.622902723529023, 11.493194853614341)

but I do not understand there should be a global shift (even with the sort)

[ricshaw]

I'm not sure I quite follow. If you use the sort_spectra function, then there will be no global shift because as you say it is identity matrix in the center of the k-space - which looks correct in your first and third images.

[romainVala]

Sorry for my bad english, and my confusion. But I know better understand what the code is doing.
My point is that the demean does not avoid a global shift. (it can even add one ...)

In my example, I ask for one sudden translation, this gives 2 affines, as precise previously. (Note that the affine are express as 3 rotations and 3 translations: so the first affine (0.0, -0.0, -0.0, 0.0, 0.0, 0.0) is the identity)
After demean I get 2 almost opposite translation ( almost because of the weightening taking into account the position in the kspace in this example 0.48)

The fact that there is no global motion is due to those 2 lines

torchio/torchio/transforms/augmentation/intensity/random_motion.py

Line 188 in 1671cbe

transforms = transforms[1:] # first is identity

Although after demean I should apply 2 affine (both different from identity), the code is skipping the first one and take the identity instead. This is why I do observe a half translation when comparing image 1 and image 3.

Indeed I ask for (0.0, -0.0, -0.0, -5.1077880859375, 42.71876525878906, 23.807273864746094) and due to the demean and those 2 lines it will only take the second affine :
(0.0, -0.0, -0.0, -2.4658347728582157, 20.622902723529023, 11.493194853614341)
(which is almost half)

If now I comment those 2 line (ie I do take the 2 affine obtained after the demean) i get the following :

I do obtain now the same motion as in figure 3, but with a global shift.

I hope it is clear

[ricshaw]

Okay I think I understand you. There may be some issues in the code currently. I think doing both demeaning and replacing the center of the k-space using the sort_spectra function are working against each other. I think in the meantime you should not use demeaning and just use the sort_spectra function to strop any global moiton. Note that in my original paper, the weighting is much more complicated, but this is not implemented in this code yet. The weighting must take into account the frequencies acquired at each position. This will be implemented in the near future.

[romainVala]

can you give me the reference of the paper, I'll try to understand.
thanks

I do not understand how a more complex weighting will solve the issue,
My point is that to avoid global motion we only need to be sure, the center has an identity affine, which will not be the case with the demean (even with more complex weighting ) no ?
(this is what I understand from playing with simple sudden affine)

[fepegar]

can you give me the reference of the paper, I'll try to understand.

torchio/torchio/transforms/augmentation/intensity/random_motion.py

Lines 1 to 8 in 1671cbe

	"""
	Custom implementation of
	Shaw et al., 2019
	MRI k-Space Motion Artefact Augmentation:
	Model Robustness and Task-Specific Uncertainty
	"""

[fepegar]

@romainVala what do you need? I thought that's the paper you were asking for.

[romainVala]

yes, thanks,
the emoicon, was meant, just because I could have find it myself ....

[fepegar]

Oh, ok.

[romainVala]

I did find the precision on the exact weighting, but I am not convince at all it will help to remove global motion ...
Anyway I will check in the near future
Many thanks

[fepegar]

I'll remove the demeaning for now. We can reopen this issue and take a look at the implementation after MICCAI.