# Bug toolkits/castor-GATERootToCastor.cc **URL:** \ **Category:** General Discussions\ **Created:** [January 23, 2020, 12:34pm UTC](https://castor-project.discourse.group/t/bug-toolkits-castor-gateroottocastor-cc/132 "2020-01-23T12:34:33Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Grahe\_Jan](https://avatars.discourse-cdn.com/v4/letter/g/d26b3c/32.png) [@Grahe\_Jan](https://castor-project.discourse.group/u/Grahe_Jan)\ **Post date:** [January 23, 2020, 12:34pm UTC](https://castor-project.discourse.group/t/bug-toolkits-castor-gateroottocastor-cc/132/1 "2020-01-23T12:34:33Z")
Dear CASToR developers, I tried converting a PET list-mode generated by GATE into the CASToR format using the castor-GATERootToCastor toolkit and obtained an error: “…. sScannerManager::Initialize() → From scanner PET\_PHILIPS\_VEREOS iScannerPET::Initialize() → Initialize remaining stuff for scanner to be ready oProjectorManager::Initialize() → Initialize projectors and projection lines → Use TOF projector for listmode data \*\*\*\*\* vProjector::CheckParameters() → Inconsistent TOF related parameters ! \*\*\*\*\* oProjectorManager::ParseOptionsAndInitializeProjectors() → A problem occurred while checking forward projector parameters ! \*\*\*\*\* oProjectorManager::Initialize() → A problem occurred while parsing projector options and initializing it !” Turns out, that the variable _m\_TOFMeasurementRangeInMm_ has a value of “-0.1498962” in the _oProjectorManager_, which caused the error in the _vProjector::CheckParameters()_. This variable is obtained from the _vDataFile\* Out\_data\_file_ using the method _GetTOFMeasurementRangeInPs()._ The datafile is initialized in the castor-GATERootToCastor.cc file and handed to the _p\_ProjectManager_ using the _SetDataFile()_ method. However, the m\__TOFMeasurementRangeInPs_ variable is set to -1 in the constructor and not set in the _castor-GATERootToCastor_ toolkit before the _oProjectorManager_ requires this variable to be set when calling it’s _Initialize()_ function. Therefore, to use the toolkit with TOF right now I added the red line in the toolkit (the block is approx. at line ~970 of the document): “…. // Set ToF if(tof\_reso\>=0) { ((iDataFilePET\*)Out\_data\_file)-\>SetTOFInfoFlag(); ((iDataFilePET\*)Out\_data\_file)-\>SetTOFResolutionInPs(tof\_reso); ((iDataFilePET\*)Out\_data\_file)-\>SetTOFMeasurementRangeInPs(myScannersTOFrange); } ” This seems to solve the problem, but only with the general coincidence time window of the scanner instead of the longest coincidence time of all events in your datafile. Not sure if that is correct or a factor of e.g. 2 has to be applied. If there is no problem with that, you could fix this bug generally by getting the coincidence time window of the scanner and then later update it to the real variable when all the events have been processed. As this only happens in version 3.0, can I still reconstruct images with CASToR 3.0 using datafiles generated with the CASToR 2.0 framework? Thanks and I hope this helps! Jan ---
**Author:** ![FILIPOVIC\_PIERUCCI\_M](https://avatars.discourse-cdn.com/v4/letter/f/8491ac/32.png) [@FILIPOVIC\_PIERUCCI\_M](https://castor-project.discourse.group/u/FILIPOVIC_PIERUCCI_M)\ **Post date:** [January 23, 2020, 12:56pm UTC](https://castor-project.discourse.group/t/bug-toolkits-castor-gateroottocastor-cc/132/2 "2020-01-23T12:56:35Z")
Dear CASToR developers, I tried converting a PET list-mode generated by GATE into the CASToR format using the castor-GATERootToCastor toolkit and obtained an error: “…. sScannerManager::Initialize() → From scanner PET\_PHILIPS\_VEREOS iScannerPET::Initialize() → Initialize remaining stuff for scanner to be ready oProjectorManager::Initialize() → Initialize projectors and projection lines → Use TOF projector for listmode data \*\*\*\*\* vProjector::CheckParameters() → Inconsistent TOF related parameters ! \*\*\*\*\* oProjectorManager::ParseOptionsAndInitializeProjectors() → A problem occurred while checking forward projector parameters ! \*\*\*\*\* oProjectorManager::Initialize() → A problem occurred while parsing projector options and initializing it !” Turns out, that the variable _m\_TOFMeasurementRangeInMm_ has a value of “-0.1498962” in the _oProjectorManager_, which caused the error in the _vProjector::CheckParameters()_. This variable is obtained from the _vDataFile\* Out\_data\_file_ using the method _GetTOFMeasurementRangeInPs()._ The datafile is initialized in the castor-GATERootToCastor.cc file and handed to the _p\_ProjectManager_ using the _SetDataFile()_ method. However, the m\__TOFMeasurementRangeInPs_ variable is set to -1 in the constructor and not set in the _castor-GATERootToCastor_ toolkit before the _oProjectorManager_ requires this variable to be set when calling it’s _Initialize()_ function. Therefore, to use the toolkit with TOF right now I added the red line in the toolkit (the block is approx. at line ~970 of the document): “…. // Set ToF if(tof\_reso\>=0) { ((iDataFilePET\*)Out\_data\_file)-\>SetTOFInfoFlag(); ((iDataFilePET\*)Out\_data\_file)-\>SetTOFResolutionInPs(tof\_reso); ((iDataFilePET\*)Out\_data\_file)-\>SetTOFMeasurementRangeInPs(myScannersTOFrange); } ” This seems to solve the problem, but only with the general coincidence time window of the scanner instead of the longest coincidence time of all events in your datafile. Not sure if that is correct or a factor of e.g. 2 has to be applied. If there is no problem with that, you could fix this bug generally by getting the coincidence time window of the scanner and then later update it to the real variable when all the events have been processed. As this only happens in version 3.0, can I still reconstruct images with CASToR 3.0 using datafiles generated with the CASToR 2.0 framework? Thanks and I hope this helps! Jan ---
**Author:** ![Maxime\_Toussaint](https://avatars.discourse-cdn.com/v4/letter/m/34f0e0/32.png) [@Maxime\_Toussaint](https://castor-project.discourse.group/u/Maxime_Toussaint)\ **Post date:** [January 23, 2020, 3:56pm UTC](https://castor-project.discourse.group/t/bug-toolkits-castor-gateroottocastor-cc/132/3 "2020-01-23T15:56:00Z")
Greetings, I was curious about your discovery and started to check it out. I am not totally sure but I think there is something else in this bug. The tool castor-GATERootToCastor only require a projector object when evaluating attenuation coefficients. Since these coefficients are independent of TOF, the projector should not need TOF information. Worse, if the projector use the TOF information, the attenuation coefficients will be evaluated from a portion of the LOR which does not fit the reality. However, my previous statement might not be true for on-the-fly system matrix computing. I will leave it to more knowledgeable peers to confirm or infirm that part. In short, my understanding is that TOF should be disabled for the tools castor-GATERootToCastor when evaluating attenuation coefficients (Using the SetIgnoreTOFFlag method, most likely) which should remove the error you observed. On that note, I also like the idea that the variable m\_TOFMeasurementRangeInPs can be user/scanner defined. While the current approach defined in castor-GATERootToCastor, which is data dependent(1), is efficient, it is true that we sometime want to fix that value for comparison or whatnot. Have a nice day, Maxime (1) ((iDataFilePET\*)Out\_data\_file)-\>SetTOFMeasurementRangeInPs(dt\_max - dt\_min); ---
**Author:** ![tmerlin](https://yyz2.discourse-cdn.com/free1/user_avatar/castor-project.discourse.group/tmerlin/32/216_2.png) [@tmerlin](https://castor-project.discourse.group/u/tmerlin)\ **Post date:** [January 24, 2020, 5:49pm UTC](https://castor-project.discourse.group/t/bug-toolkits-castor-gateroottocastor-cc/132/4 "2020-01-24T17:49:04Z")
Hi, Thank you both for your feedback! Indeed there are several issues in the converter occurring when one would like to enable ToF and integrate some custom scatter/random corrections. I hadn’t checked _castor-GATERootToCastor_ in v3.0 with ToF option enabled, and as Jan experienced, it crashes because of incorrect initialization of the ToF measurement range for the projector classes. Additionally, as Maxime suggested, it actually makes no sense to use ToF in the projector to compute ACF. → Quick workaround is to perform the modification Jan suggested, and also add the following line in red after the ProjectorManager initialization: " … // Check parameters if (p\_ProjectorManager-\>CheckParameters()) { Cerr("\*\*\*\*\* castor-GATERootToCastor :: A problem occurred while checking projector manager’s parameters !" \<\< endl); Exit(EXIT\_FAILURE); } // Initialize projector manager if (p\_ProjectorManager-\>Initialize()) { Cerr("\*\*\*\*\* castor-GATERootToCastor :: A problem occurred while initializing projector manager !" \<\< endl); Exit(EXIT\_FAILURE); } p\_ProjectorManager-\>SetSensitivityModeOn(); … " This will force the projector to use the non-ToF projector functions anyway. → Regarding the correct initialization of the ToF measurement range, I agree that it should be initialized with the system coincidence window, rather than derived from the data as Marina and Maxime suggested. This will be fixed in next update (with an additional option to manually set it). A temporary workaround for this is to set it directly in the castor datafile header once it has been generated. → Regarding the reconstruction of v.2 CASToR datasets with the v.3 code, there should not be any issue. The error message comes from additional check in the v3 version. However, the estimation of ACF during conversion was already performed by the projectors with ToF enabled, so the ACF values might be wrong! Thank you all for your insights! Best wishes, Thibaut