Issues about the List-mode normalization

Dear CASToR developers and users,

I am trying to apply normalization to a simulated PET scanner but meet some issues, any help is highly appreciated!

First I successfully applied the normalization by feeding the normalization file (all LORs with norm&attenuation factors) into the CASToR for the computation of the sensitivity image. The CASToR gives me artefact free images in this way.

However, the normalization doesn’t work when I embed the factors into the List-mode binary datafile:

  1. When I feed the list-mode data (with normalization factors and flag on) to CASToR, it give me the following error:
    oSensitivityGenerator::InitializeNormalizationFiles() → Normalization correction is included in the data file while it is not in the sensitivity computation!
    In order to bypass this error, I use -sens to provide a precomputed sensitivity image (Not normalized) to CASToR. Is this the proper way to do it? If not, what should I feed to CASToR instead?

  2. After feeding precomputed sensitivity image, the CASToR can run reconstruction with no issues, but the image with embedded LM normalization factors is identical to the image without normalization factors. Then I assign all the events with the same normalization factor of 0.1,1,10, respectively. But the reconstructed images have the same pixel intensities, which means I did something wrong and the LM normalization factors is not doing its job at all in my case.

The version I am using is CASToR v 3.0.1.

Here is one of the header files:
Data filename: PET_Sim_LMNorm.Cdf
Number of events: 13755984
Data mode: list-mode
Data type: PET
Start time (s): 0
Normalization correction flag: 1
Duration (s): 1500
Scanner name: D04_sim_1ring
Calibration factor: 1
Isotope: unknown

Here is some examples of the I generated list-mode data: (I assgin all the time frames to 0 and norm factors to 1)
0000 0000 0000 803f ba22 0000 c005 0000
0000 0000 0000 803f 9a15 0000 9e19 0000
0000 0000 0000 803f e20e 0000 fa0b 0000
0000 0000 0000 803f f51f 0000 6a05 0000
0000 0000 0000 803f 971a 0000 1203 0000
0000 0000 0000 803f e91f 0000 d719 0000
0000 0000 0000 803f 211d 0000 3721 0000
0000 0000 0000 803f f906 0000 7105 0000
0000 0000 0000 803f 4c20 0000 f014 0000
0000 0000 0000 803f 8e1e 0000 a607 0000
0000 0000 0000 803f a821 0000 1a19 0000
0000 0000 0000 803f e81a 0000 8514 0000

0000 0000 0000 803f 6913 0000 e525 0000

Thank you very much!

Hi Zipai,

You will get the error described in 1. when you try to reconstruct the list-mode with a datafile containing normalization correction factors without providing a normalization datafile containing these factors. The normalization correction factors must be included in both the regular datafile (using -df option) and the normalization datafile (using -norm option). Is it what you did ?

Regarding 2., the factors in your normalization datafile will contribute to the correction in the image (through the sensitivity image which is generated before the reconstruction itself), while the correction factors in the datafile are used to normalize the additive background (scatter/random) during reconstruction. As your data does not contain scatter or random correction factors (and as you use a precomputed sensitivity image), there will be no difference in the resulting image.

Hope this helps!

Best regards,
Thibaut

Zipai Wang <zipai.wang@stonybrook.edu> a écrit :

Dear Zipai,

I will answer to the mailing-list as well as it is an interesting question and other users could have similar interrogations.
There is unfortunately no way to do that with CASToR. However I do think the optimal approach would be to rebin the LORs before reconstruction and directly provide to castor-recon a list-mode with the repositioned LORs and adjusted normalization factors. I believe the main interest to integrate even-by-event motion correction during reconstruction would be to perform non-rigid deformation as in the approach developed by Yale group (https://doi.org/10.1109/TMI.2017.2761756 ). However implementing this approach in CASToR would require substantial changes to optimize the code performance, at the expense of genericity.

Many thanks for the kind words about the workshop, always good to know it was useful to you and other attendees :slight_smile:

Best regards,
Thibaut

Thank you Dr. Merlin for your answers!

Best regards,