<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hello Maxime,</p>
    <p>Thank you for your feedback, the current implementation of the
      Siddon multi-lines projector class (and the associated <i>GetRdmPositionsAndOrientations()</i>
      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. <br>
      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 <i>mp_meanDepthOfInteraction</i>,
      it refers to a previous implementation in the event a DOI was
      provided.<br>
    </p>
    <p>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.<br>
    </p>
    <p>Thank again for your remark and suggestions. I will have a look
      this summer to correct the current implementation. <br>
    </p>
    <p>Best,<br>
      Thibaut<br>
    </p>
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 18/06/2018 20:13, Maxime Toussaint
      wrote:<br>
    </div>
    <blockquote
      cite="mid:a7e0e131-5dcf-6c8c-bd1a-0e81add568a0@usherbrooke.ca"
      type="cite">Hi,
      <br>
      <br>
      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.
      <br>
      <br>
      The long version:
      <br>
      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):
      <br>
      (uY, uX, 0)
      <br>
      while the axial axis of the detector is defined as:
      <br>
      (uX*uZ, uY*uZ, sqrt(1-uZ**2))
      <br>
      From there, we can observe several problems. Two examples:
      <br>
      1) (uX, uY, uZ) (uY, uX, 0)' = uX*uY + uY*uX =/= 0 (Most of the
      time.)
      <br>
      2) || (uY, uX, 0) || =/= 1 if uZ =/= 0 (Since ||(uX, uY, uZ)|| =
      1.)
      <br>
      Thus, the set of positions generated by that function does not
      correspond exactly to the detector.
      <br>
      <br>
      A possible correction: (it needs to be applied on the computation
      of ap_Position1 and ap_Position2)
      <br>
      Replace (uY, uX, 0) by (uY, -uX, 0) / || (uY, -uX, 0) ||
      <br>
      Replace (uX*uZ, uY*uZ, sqrt(1-uZ**2)) by (-uX*uZ, -uY*uZ, 1-uZ**2)
      / ||  (-uX*uZ, -uY*uZ, 1-uZ**2) ||
      <br>
      <br>
      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.
      <br>
      <br>
      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?
      <br>
      <br>
      Have a nice day,
      <br>
      Maxime Toussaint
      <br>
      <br>
      _______________________________________________
      <br>
      Castor-users mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:Castor-users@lists.castor-project.org">Castor-users@lists.castor-project.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.castor-project.org/listinfo/castor-users">http://lists.castor-project.org/listinfo/castor-users</a>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
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</pre>
  </body>
</html>