[Castor-users] Reconstructing with normalization

Fri Oct 23 23:21:28 CEST 2020

Hi,

thank you for your response Simon, and I am sorry for such a delayed reply.

I was not aware that you needed to provide the attenuation map *and*
include acf in the data file when using the -atn option, which would
explain the difference in my images when using -atn as oppose to -norm.

In the attached image (atn-norm.png) I have reconstructed embedding the acf
in the CASToR data file and passing the attenuation map using -atn (upper
row). I have also reconstructed embedding the acf in the data file and a
passing a normalization file with acf embedded using -norm (bottom row).
The images are labeled accordingly: no correction (No corr), with only
attenuation correction (a corr), and with scatter-, random-, and
attenuation corrections embedded in the data file (a+s+r corr). The
streaking pattern becomes obvious (all images have been summed) when
including scatter and/or random correction regardless of which attenuation
correction option was chosen (-atn or -norm). This seems strange, should
not these patterns appear already when reconstructing without any
correction factors? Bear in mind, at this point I had still not accounted
for the axial compression.

So, regarding the axial compression, you are correct, for the DMI as for
the SIGNA there is an axial span of 3 for the first segment which I had not
taken into consideration before. However, when trying to handle the
compression in the CASToR data file the results still look strange(r). To
account for the span of indirect slices of segment 0 (as the axial
compression is the same for the SIGNA and DMI), I construct the data file
according to table 3 (and the normalization file according to table 4) in
the general documentation by providing the "list" of crystal pairs for each
event where nb_lines is greater than 1, and filling with "garbage" bytes
otherwise. The reconstructed images can be seen in the second attached
image (recon.png). In recon.png I have included reconstructed images when
*1)* not accounting for axial compression (top row), *2)* including axial
compression (middle row), and *3) *when reconstructing with the PET Toolbox
just as reference (bottom row). In recon.png I also included a
reconstructed imaged with normalization correction included in addition to
scatter-, random-, and attenuation (a+s+r+n). As can be seen, the images
still contain these streaking patterns (corresponding to every other slice)
when including random- and scatter correction (regardless of including
compression). When including normalization correction factors, these
patterns are enhanced (and in the case of including compression, completely
distorted).

Again, I am asking for some help; is this something that you have seen
before and/or know how to remedy. Any tips or guidance that could point me
in another direction would be helpful.

Additionally, may I perhaps ask, how is this handled in the v.3
listmode-benchmark? I am asking as the maximum number of lines per event is
not specified in the header (i.e. should be set to the default of 1), yet I
would assume that this compression is somehow accounted for. It would be
additionally interesting to know as the distance driven projector is not
compatible with compression in the data file.

Also, for your information, when trying to access the benchmarks from the
website, a* "page not found" *is returned.

I am very grateful for any guidance in this matter.

Best regards,
*Philip*

On Mon, Sep 28, 2020 at 12:24 PM STUTE Simon <simon.stute at chu-nantes.fr>
wrote:

> Hi Philip,
>
>
> In (2), you said that you provide an attenuation image but no attenuation
> factor in the CASToR datafile.
>
> Does it means that you input the pifa using -attn option, that you do not
> input a normalization file and that in the list-mode file, there is no
> attenuation factor ?
>
> If yes, then the corrections for scatters and randoms are severely
> underestimated.
>
>
> Could you compare (1) with the following case: the attenuation map
> provided with -attn, no normalization file at all, attenuation correction
> factors included in the list-mode file ?
>
>
> In the SIGNA, there is span 3 (indirect planes between rings are summed)
> for the first segment (copolar angle 0).
>
> Is there any span in the acquired sinograms ?
>
> I think there is some, from the image (4).
>
> So it may be that you do not take this axial compression into account.
>
>
> Simon
>
>
> ------------------------------
> *De :* Castor-users <castor-users-bounces at lists.castor-project.org> de la
> part de Philip Kalaitzidis <kalaitzidis.philip at gmail.com>
> *Envoyé :* vendredi 25 septembre 2020 19:07
> *À :* castor-users at lists.castor-project.org
> *Objet :* [Castor-users] Reconstructing with normalization
>
> Dear CASToR developers and users,
>
> I have been facing an issue when trying to reconstruct PET data (a 18F
> measurement with the NEMA IQ Body Phantom) acquired on a G.E. Discovery MI
> with CASToR, in particular when reconstructing with normalization
> correction factors embedded in the file. The correction terms (attenuation,
> scatter, random, normalization, dead-time, and pile-up) that I am using
> when reconstructing with CASToR have been extracted with the G.E. PET
> Toolbox. I am converting the G.E. PET list-file to a CASToR list-file,
> embedding all aforementioned correction terms in that file. Additionally, I
> am also constructing the CASToR normalization file by looping over all
> (unique) crystal-pairs and embedding the attenuation- and normalization
> correction factors as is suggested in the general documentation.
>
> When performing the reconstruction (in my case OSEM with a 4 mm axial and
> transaxial FWHM post-filtering) with normalization factors embedded in both
> the list-file and the normalization file, every other slice has a reduced
> intensity - this does not appear if I do not use the CASToR normalization
> file (and thus not embedding attenuation- and/or normalization correction
> factors in the list-file). This can be seen in the attached image, (1)
> shows the reconstructed images (summed) with CASToR including attenuation
> and normalization correction embedded in the file, (2) shows the
> reconstructed images (summed) when using the pifa obtained from the PET
> Toolbox to account for attenuation correction and not including attenuation
> and normalization correction factors in the CASToR file, and (3) is when
> the reconstruction is performed with the PET Toolbox.
>
> Now, if I look at the sinograms extracted from the PET Toolbox I can see
> that for the first axial indices (0-70) there is a notable difference in
> the number of counts, something that I am expecting to be corrected for by
> the normalization correction. So, I tried to look at the prompts sinogram
> by subtracting the randoms and scattered coincidences, and then multiplying
> each sinogram bin by the attenuation- and normalization correction factors.
> From this I get a smooth sinogram (summed over all views) which can be seen
> as (4) in the attached image. If I would do the same thing again, but this
> time not multiply with the normalization correction factors, this differing
> intensity becomes apparent in the first axial slices in the sinogram (ring
> difference 0 for the DMI with four axial units), seen to the left in (5) in
> the attached image.
>
> This made me think that the error lies in the CASToR normalization file.
> So, to be on the safe side that I constructed the CASToR normalization file
> correctly, I looked at the normalization file in the benchmark of the G.E.
> SIGNA data event by event and could not find any discrepancy between how I
> constructed the normalization file and the organization to that of the
> benchmark normalization file.
>
> I have tried changing the projector but the issue remains (although less
> apparent with the distance-driven projector).
>
> Is there something obvious, or less obvious, that I might have missed? Is
> there something that you could point out that might be wrong?
>
> I hope to hear from you!
>
> Best regards,
> *Philip*
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.castor-project.org/pipermail/castor-users/attachments/20201023/5819d550/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atn-norm.png
Type: image/png
Size: 115148 bytes
Desc: not available
URL: <http://lists.castor-project.org/pipermail/castor-users/attachments/20201023/5819d550/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recon.png
Type: image/png
Size: 157001 bytes
Desc: not available
URL: <http://lists.castor-project.org/pipermail/castor-users/attachments/20201023/5819d550/attachment-0003.png>