[Castor-users] Possible problem with multiSiddon projector random sampling

[tmerlin]

Hello Maxime,

Thank you for your feedback, the current implementation of the Siddon 
multi-lines projector class (and the associated 
/GetRdmPositionsAndOrientations()/ function from the iScannerPET.cc 
file) has indeed some limitations. It is still work in progress and is 
only intended to be used with usual systems whose detectors have an 
axial orientation equal to 0. I should have made it clearer in the 
description of the projector.
It has not been assessed with systems using detectors with non-zero 
axial angle, and as you noticed it contains some errors in this case. 
Regarding the comment about /mp_meanDepthOfInteraction/, it refers to a 
previous implementation in the event a DOI was provided.

This projector is actually a draft and we plan to revamp the management 
of multi-line projector to make it more flexible. In short, the 
estimation of the random position in the detector should be computed in 
the mother class (or inside an additional intermediate class), from 
which any line projector class could be called to compute the system 
matrix elements. This would avoid to create a multi-lines projector 
class specific to each projection algorithm. Besides, we plan to rework 
on the orientations in order to make it more flexible for less generic 
systems. All of this will require some substantial work though.

Thank again for your remark and suggestions. I will have a look this 
summer to correct the current implementation.

Best,
Thibaut



On 18/06/2018 20:13, Maxime Toussaint wrote:
> Hi,
>
> I think there is an error in the GetRdmPositionsAndOrientations 
> function of the file iScannerPET.cc. In short, the vectors used to 
> create a random position in a detector are not orthogonal between each 
> other and two of them are not guaranteed to have a norm of one.
>
> The long version:
> mp_crystalOrientation gives us a vector that goes along the depth of 
> the current detector. However, CASToR does not keep a similar vector 
> for the detector's transaxial and axial axes. For simplicity, let's 
> define (mp_crystalOrientationX, mp_crystalOrientationY, 
> mp_crystalOrientationZ) as (uX, uY, uZ). Currently, the transaxial 
> axis of the detector is defined as (in the function 
> GetRdmPositionsAndOrientations):
> (uY, uX, 0)
> while the axial axis of the detector is defined as:
> (uX*uZ, uY*uZ, sqrt(1-uZ**2))
> From there, we can observe several problems. Two examples:
> 1) (uX, uY, uZ) (uY, uX, 0)' = uX*uY + uY*uX =/= 0 (Most of the time.)
> 2) || (uY, uX, 0) || =/= 1 if uZ =/= 0 (Since ||(uX, uY, uZ)|| = 1.)
> Thus, the set of positions generated by that function does not 
> correspond exactly to the detector.
>
> A possible correction: (it needs to be applied on the computation of 
> ap_Position1 and ap_Position2)
> Replace (uY, uX, 0) by (uY, -uX, 0) / || (uY, -uX, 0) ||
> Replace (uX*uZ, uY*uZ, sqrt(1-uZ**2)) by (-uX*uZ, -uY*uZ, 1-uZ**2) / 
> ||  (-uX*uZ, -uY*uZ, 1-uZ**2) ||
>
> Note: Since mp_crystalOrientationZ is 0.0 for all detectors in most 
> scanner, this error might have negligible repercussions in practice. I 
> am not sure, since I didn't test its repercussions in reconstruction.
>
> I have another question. In the comments prior to the function 
> GetRdmPositionsAndOrientations, there is the following line: "fix the 
> possibility to draw LOR outside the actual crystal volume (if 
> mp_meanDepthOfInteraction != 0.5)". From what I understand, that 
> function never uses that parameter. Was that comment meant for the 
> function GetPositionsAndOrientations or did I miss something?
>
> Have a nice day,
> Maxime Toussaint
>
> _______________________________________________
> Castor-users mailing list
> Castor-users at lists.castor-project.org
> http://lists.castor-project.org/listinfo/castor-users

-- 
Thibaut MERLIN -- PhD

Docteur en Imagerie Médicale au Laboratoire de Traitement de l'Information Medicale (LaTIM - INSERM UMR 1101)
Bâtiment 1
CHRU Morvan - 2, Av. Foch
29609 Brest CEDEX - FRANCE
Tel: 06.75.12.24.90

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.castor-project.org/pipermail/castor-users/attachments/20180620/3bf88229/attachment.html>