[Gate-users] No coincidences when using generic repeater in PET

[Peter Neilson]

Hello Etienne, 

  This is kind of funny, we had attempted something similar to the crystal positioning trick you had described using a Matlab script. Though I figure your technique is more likely to be accurate since its derived from the GATE run itself. 

   I’ve mostly worked out the crystal indexing used by castor for setup, it looks like the order of output from the VRML file will match that of the .placements, so as long as that follows the same ordering as expected by castor the indexing will match up? 

   I wouldn’t worry about my “particle sources in the wrong place” I had attempted hand modification of the .geom file that probably just choked in the actual reconstruction. 

Thanks,
-Peter Neilson

> On Mar 30, 2020, at 10:32 AM, Etienne Auger <Etienne.Auger at USherbrooke.ca> wrote:
> 
> Hello Peter,
> 
> I will address your question paragraph by paragraph to make it more clear: 
> 
> "I had been following this thread and was able to use the patch to get coincidences using a cylindricalPET system that looked just as they should."
> 
> I am glad you successfully obtained coincidences, but I guess you meant "using a PETscanner", because a cylindricalPET system, according to the docs, only supports ring and cubicarray repeaters. The precise object of this thread was that no coincidences were obtained when a generic repeater was used, and a generic repeater can only be used with the PETscanner template.
> 
> "So my problem is not particularly GATE-driven, but I was attempting to reconstruct an image using Castor and found the results to be rather odd. First found that I had to create the .geom file by hand, gateMacToGeom was not recognizing the generic repeater."
> 
> This is no surprise, as it is stated in the pages 48-50 of the v3 doc of CASToR: "The castor-GATEMacToGeom is a very basic utility to generate a geom file from a GATE[7] mac file defining a cylindricalPET, ecat, or SPECThead geometry." We can imagine that it would be very difficult to generalize this utility to systems that are described with other, less restrictive scanner templates.
> 
> This point is important: I think it is easier, when using non-standard geometries, to get the exact positions of all the crystals in your scanner with a little trick that I found, and that I already described here: http://lists.opengatecollaboration.org/pipermail/gate-users/2020-March/011452.html <http://lists.opengatecollaboration.org/pipermail/gate-users/2020-March/011452.html> Once you have parsed the text file describing exactly the geometry of your scanner, you have to format the positions of your crystals in a lookup table format (LUT, p.20+ of v3 CASToR doc) that can be used to reconstruct your data.
> 
> "But then it seemed like it was placing my particle sources in the wrong place, though they were definitely present."
> 
> Without more context and code, it is difficult to tell what could have gone wrong between your simulation, your description of your scanner geometry by hand and the reconstruction itself.
> 
> "I was curious If anyone had attempted image reconstruction in a simulation with a generic repeater and seen similar problems?"
> 
> But do not despair, as I (and probably others) already have successfully reconstructed images with CASToR from a simulation that was using a generic repeater with the PETscanner template. We just need a little more info about your case to help you.
> 
> Cheers,
> 
> Étienne
> _______________________________________________
> Gate-users mailing list
> Gate-users at lists.opengatecollaboration.org <mailto:Gate-users at lists.opengatecollaboration.org>
> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users <http://lists.opengatecollaboration.org/mailman/listinfo/gate-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20200402/cfd4b46b/attachment.html>