TIme of Flight - clean#918
Conversation
Code from the old work transfered.
image and I am working to be able to apply the normalisation factors. I had problems with the RelatedBins class, therefore I created several fucntion which take as input a vector<Bin> and a DataSymmetriesFromBin, which essentially is the same thing ( at least for this application).
… normalisation Currently I am using only the new bin-wise normalisation. After the tests run I will try the old viewgram-wise method. And report the results.
image as the sinogram objective function.
But I would like to remove the bin-wise functions.
My tests showed that the results are not exactly the same as in the viewgram-wise calculations. So I retreat it for now.
[x]. Crash when segment of measured bin was larger than the max segment in par file. FIXED [x]. Zero stored counts if either total_number_of_events or time_frames were not specified.
[x]. ProjDataFromStream: Only get_bin_value(Bin) left. [x]. ProjData.h get_bin_value was removed [x]. ProjDataGEAdvance.h get_bin_value() was removed [x]. CListModeDataECAT8_32.h reverted. [x]. ProjMatrixByBinSPECTUB reverted. [x]. ProjData.cxx : get_related_bin_values commented out [x].
Not really usefull.
The test script computes a background sinogram. The lm-objective function checks if the additive projdata are compatible.
I added fake normalisation and additive components. In addition, In the run_root_GATE test I changed a bit the way the script detects GATE support, after some complains by users. I hope that is better now. I cleaned up the code in the ProjData FromStream but didn't edit the way get_offsets_bin() works because I see no improvement if it depend or other offset function, or if another offset function depends on that. FInally, I uncomment the use of get_bin_value() in the ProjDataInMemory.
Found that the last fi was commented and the test was failling.
Trying to narrow the error from Travis.
The lm objective function takes the pro_data_info from CListModeData. New keywords for CListrModeROOT to set the sizes of the proj_data_info. Better tests on ranges.
After some more complains about the grep in the run_root_GATE.sh, I changed to an awk.
Use of backquotes in the test script. Other minor imrpovements.
…etectors.inl Uncommented the two commands I had left out.
* run_tests.sh * run_root_GATE.sh * run_scatter_tests.sh Update bcktest.cxx, ListModeData.cxx, and 4 more files...
Update stir.i, CListModeDataGEHDF5.cxx, and 3 more files...
This reverts commit b3f91c0.
…stability with Signa.
actual proj-data not done yet (will call error())
Co-authored-by: Casper da Costa-Luis <casper.dcl@physics.org>
Only use the non-default ones for the style, as otherwise it causes problems with different versions of clang-format
|
I've tried and failed at testing each of the following: mCT LM data
STIR/src/listmode_buildblock/CListRecordECAT8_32bit.cxx Lines 43 to 46 in 59ab3ea This is regardless of the template used. The issue is that the LM data itself, as far as I can tell, is encoded with span 11. (I think I recall this being due to the number or LORs and fitting into 32 bits, I heard you can acquire uncompressed with 64 bit LM?) Does this mean we need to support axial compression in this class? mCT Sino dataI've tried here my own data and data supplied by @Ede1994. These are compressed though, and I've tried and failed to use Siemens' The first file reports a data corruption, which could be possible and unfortunate I guess. The second file runs, and takes some time, but not output file is to be found. Vision 600 LM dataUsing @NicoleJurjew 's data Full error: Which is coming from STIR/src/buildblock/ProjDataInfo.cxx Lines 409 to 410 in 59ab3ea But I haven't yet worked out where this is called from or what is causing STIR to set span=-1. It looks like this is used as a default "unset" value in a few places...
602-1.hl: Actually... Now that I write this out I notice that the mCT LM interfile had the following keys: I guess these may have been necessary for STIR... |
|
Update for the Vision 600: I had to add Now a new problem is working out the layout of the singoram, described in 6.3.1 here: This is definitely for another PR! Lets get the mCT working and test with that... |
|
This is now obsolete. Siemens things have been added to the normal TOF PR. Note that mCT list data still won't be handled there due to the axial compression. |
#304, plus: