storing geometry / eff. information into separate file

[gschramm]

Since most modern scanners are "stable" and detector effs. are usually only "re-estimated" every few weeks / months,
storing those in a separate file would decrease storage requirements, especially if not all symmetries are being used
to encode the ModulePairEfficiencies.

[MaxTousss]

Can't that already be done with the current format by creating petsird files with only that information and petsird files with only the list-mode data? If that is the case, it is mostly a convert task at that point but we could modify the model such that the geometry/eff store a file name or an ID to know which petsird file to use.

[gschramm]

Indeed. Writing a 2nd file that only contains the scanner info seems a solution.
However, than the other file containing only the "events" needs to somehow encode where the other file
containing the geom./effs. is.

[gschramm]

an idea would be to encode the file name / path of the 2nd file and maybe also a checksum such that people
can verify that the "linked" 2nd file is the correct one

[MaxTousss]

Ohhh! Checksum is a great idea!

[KrisThielemans]

A URL would be better than a filename. It still creates a headache though when tranferring files. It seems very easy to end up in a situation where the "static" information is lost. You'd therefore need some utilities to move/copy PETSIRD files.

[gschramm]

Loss of files / information is indeed a concern. However, when we deal with scanners with a lot of detecting elements - small detecting elements e.g. due to DOI and small (vitrual crystals) and not too many symmetries, I think it is possible that the "header information" gets bigger than the actual emission data - especially for low and medium count scans.

[MaxTousss]

Yeah, considering the potential "waste" of space in making every file a standalone, I think it will be preferable to embrace the headache of file transferring.

And, would it be that bad? If you deal with a lot of acquisitions and/or multiple scanners, you would have utilities to manipulate them (or you already embrace chaos). If you only have a small number and do not want to deal with this, you can store everything in standalone files and the size should be manageable.

We could suggest an extension to get this info. Something like file.petsird{gnl} or file.ps{gnl}, which are hints that the file should contain geo and/or norm. and/or listmode.