Castor-users Digest, Vol 36, Issue 17

General Discussions
1

Hello Thibaut,

I understand your explanation, but it seems to me that the correction is applied in a different way in respiratory motion correction than in involuntary motion correction.

I have one dataset (PET list mode) of a Nema phantom that ‘moves’ in the x-y direction. The phantom is always in one position for 300s and then it moves in one moment to another position where it is 300s. This in total for three positions. (The translation of the phantom is 2 cm in x- and y-direction).

I reconstructed this dataset in two ways:

    1. reconstruction with involuntary motion correction (-im) where the splitting of the data is done by timestamps (motion triggers), motion triggers on 0s, 300s and 600s.
    1. Reconstruction with respiratory motion correction (-rm) where the splitting of the data is done by gates (respiratory triggers), the data is split based on how many events belonged to each phantom position.

In this way, the splitting should take place on exact the same moment and I used the exact same deformation file. Furthermore, I used the exact same attenuation correction map.

But I get different images after reconstruction (see attached image). The image of the -im reconstruction differs from the image of the -rm reconstruction in the places where the density of the tissue changes when the phantom moves (outside of phantom and in the middle cilinder). That is why I suspect that something else happens with the attenuation correction (sensitivity images) between these two methods of motion correction.

I can imagine this is quite an extensive story, but I wanted to explain it well. Hopefully this makes it a little bit more clear.

Kind regards,

Inge

Image_Nema_phantom.png

2

Hi Inge,

Thank you for detailing the issue. The difference should come from the sensitivity image weighing, as for -im case the weighing depends (among other things) on the duration between two motion triggers. Using -rm, the sensitivity images for each gate are simply averaged so it would work only if the motion triggers are evenly spaced during the acquisition, which is actually the case with your setup. What I don’t understand is why do you get these artifacts using -im, which should be the proper way to go… Did you get this problem with the v3.0 version as well ? Or is it just with the v3.1 version ? If you could upload the data somewhere, I will have a look.

Best regards,

Thibaut