Dear castor-users,
I give an update to my previous email.
I tried to change the min angle difference in the geometry file from 135 (meaning a coincidence schema 1vs3) to 180 (meaning a coincidence schema 1vs1) and the two reconstructions provided exactly the same results.
Could the artifact be related to some kind of bug (or a misuse by my side) related to the “min angle difference”?
Thank you
Alessandro
Hi Alessandro,
The artifacts are totally normal if you do not apply a normalization correction, especially with low number of detector panels.
As for the min angle difference, did you let CASToR compute the sensitivity image in both cases (135 and 180) ? Are they different ?
The min angle difference is not apply in the loop over the data, so it should be applied by yourself when building the datafile.
Also, how did you build the geometry of your scanner, from your own LUT file or using the GATE converter ?
By the way, your emails successfully reached the mailing list.
Best
Simon
Dear Simon,
thank you for your answer.
I used the GateRoot converter to create the data file in histogram mode and to automatically generate the geometry (-geo parameter). It automatically added the 135 deg min angle difference in the .geom file.
I thought the min angle difference was applied in the loop over the data, so I tried to change it in the .geom file. By the way, now I created two different data files changing the digitizer option in the gate macfile to change the coincidence scheme and the sensitivity images do look different.
For the application of the normalization coefficients, in histogram mode, do I have to manually modify the datafile to change the normalization coefficients of the events from 1 to the appropriate coefficient?
Alessandro
Dear All,
with the intent to include the normalization coefficients I was looking at the data file created by castor-GATERootToCastor and I saw that It contains an odd number of events (LORs), in which an event is identified by a pair crystal1-crystal2. The scanner (with a coincidence scheme of 1vs3) has ~9.7 million LORs but the entries in the data file are more than 25 million. This event includes LOR identified for example by crystals belonging to the same module, even adjacent crystals, that are clearly not in coincidence. The “amount” value for these events is equal to zero. If I remove all the zero-amount events from the data file and create a new histogram, the reconstruction shows no artefacts, even without the application of the normalization correction. I attach the images, left with all the events, right after removing the zero-amount LORs.
Is this normal behaviour?
Best
Alessandro
Dear Alessandro,
Thank you for the feedback.
In histogram mode, the converter fills an histogram with all the events recorded in the simulation. The histogram does not depend on any geometry and blindly assumes all crystal combinations are available, so that is why you end up with a very large file with a lot of nil events. This could actually be improved by checking first if the line is available depending on the transaxial angle restriction in the geom file, but this is not implemented.
This does not usually lead to such artifacts as in your first reconstruction, I believe this could be due to the octagonal geometry. I will have a closer look at that.
I would however expect that removing all the zero-events from the histogram could lead to artifacts, as in histogram mode the lines of response in the histogram are used to generate the sensitivity image. This doesn’t appear in your second reconstructed image, but that might be object/system dependent.
Normalization artifacts are also more or less visible depending on the object. I believe they would be more visible with the simulation of a large object with uniform activity.
Best regards,
Thibaut
