Are there any restrictions on the ordering of the scintillators in the scanner’s lut file or the ordering is completely arbitrary?
The question comes from the following problem: I have made a custom scanner file according to my simulation geometry (and indexing). The validation using castor-scannerLUTExplorer -g -sf filename gives correct position/orientation for all the crystals. However, the sensitivity image is wrong: I can see a scatterred set of standalone points filling the correct cylindrical volume:
Hi Andrey,
There is no specific ordering for LUT. To generate the sensitivity image from the geometry, CASToR will just loop on the crystal indices and project every possible LOR.
So indeed if everything was right when you double check the positions of the detectors, the output you get is strange, as if the image was opened with the wrong endianness. What range of values do you have in the voxels ?
Thank you for theprompt reply!
I doubt that the problem is with reading of the images as I use a standard tool (Amide). I have opened them using InterFile 3.3 import option.
I have asked about restrictions on the indexation since my indexing is highly “irregular”: after continuous indexing for one 8x8 “assembly” of scintillators, the next one will always be on the other side of the scanner. Also, the scanner does not have a complete ring.
I think I should try to compute my own calibration dataset, “feed” it to the reconstruction and see if the problem persists. What do you think?
Be careful with Amide, some recent version had issues with endianess lately and I would double check the raw image if you have very erratic values. See [3] below:
With a LUT the indexing doesn’t matter, you could choose to randomly shuffle the detector index and you should get the same sensitivity image as computed from geometry. However it is true the aspect of this image will depend on your geometry, but if your positions seems correct I would not expect such noisy output except maybe if the number of detectors if very low.
Of course you can generate your own dataset and feed it to CASToR as a normalization datafile with the proper data channels (with or without correction factor) and give it to CASToR to generate the sensitivity image. This should actually be better than computing from geometry.
You were right, the problem was a bug in Amide: [amide-users] Interfile reading problems | AMIDE
I have tried on Windows with anothe version of Amide, and both sensitivity and reconstructed images are OK
