Issue where implementing TOF creates extremely large numbers for crystal ID out of scanner range

Im reconstructing PET scanner data, and I’ve had it working without incorporating TOF information into my data for a while.

Now I want to use TOF data, but it creates a lot of errors like this:
***** iScannerPET::GetPositionsAndOrientations() → Crystal index 2 (1121913881) out of range [0:1751039] !
***** vProjector::Project() → A problem occurred while getting positions and orientations from scanner !
***** oProjectorManager::ComputeProjectionLine() → A problem occurred while forward projecting an event !

I don’t have any numbers near that (1121913881) in my cdf file, so I have no clue where this number is coming from.

I’ve read through my entire CDF file, and there are no numbers even close to that. Also this only happens for crystal index 2 and not crystal index 1 in my error messages.

Does anybody have any ideas, or have they had issues with this before?
I am on the latest version, CasTor 3.2, not dev branch

Greetings,

To my knowledge, “Crystal index” is never modified after it is read from the cdf file. It is, however, computed by CASToR for the sensitivity image if the geometry is defined using a geom file. Is the problem occurring while computing the sensitivity image or in the iterations?

If it is the former, do you use a geom or lut to define the geometry? And did you modify them to include TOF?

If it is the latter, my guess is that something went wrong in creating the cdf file. How did you check the crystal index in the cdf file? Did you use CASToR datafile explorer application?

Bests,
Maxime Toussaint

I already have my sensitivity premade — I’m using the same one as for without TOF — so my issue appears in the iteration.

I’m using LUT to define geometry. Do i need to modify my geometry files to include TOF? I never really considered it because I didn’t think including TOF would change how i do my geometry.

To see the crystal index I just printed it using this python script:

import struct
import os

FILENAME = “coincidence_LXe_src0.0cm_fine.cdf”

num_events = 39409

struct_fmt = “<IIIf”
struct_size = struct.calcsize(struct_fmt)
print(“Struct format:”, struct_fmt, “size (bytes):”, struct_size)

print(“File size:”, os.path.getsize(FILENAME))
print(“Expected size:”, num_events * struct_size)

with open(FILENAME, “rb”) as f:
for evt in range(10000):
data = f.read(struct_size)
if not data:
print(“Reached EOF after”, evt, “events”)
break
time_field, id1, id2, tof_ps = struct.unpack(struct_fmt, data)
print(f"Event {evt}: time_field={time_field}, id1={id1}, id2={id2}, tof_ps={tof_ps:.1f} ps")

Thanks,

Burgeon

Greetings,

Looking at CASToR’s documentation, the fields order in a list-mode should be
time […] [TOF] […] c1 c2

Your code read the file using the order:
time c1 c2 TOF

Thus, you might just need to re-write the cdf file with the correct order!

Bests,
Maxime Toussaint

Hello,

Thank you, your solution worked! I definitely should’ve realized it earlier, but now I have another issue. :sweat_smile:

I reconstructed the data with TOF, but it returns an empty image. I tried it without TOF, and it worked, so now I’m lost again. Are there any common causes of this?

Thank you,

Burgeon

Hi,

Well, I guess that providing invalid TOF, e.g., too low/high values, could cause that.

You should use CASToR data file explorer application to check the TOF values.

Bests,
Maxime Toussaint