Skip to content

TIme of Flight - clean#918

Closed
ashgillman wants to merge 226 commits into
UCL:masterfrom
ashgillman:clean-tof_sino_UCL
Closed

TIme of Flight - clean#918
ashgillman wants to merge 226 commits into
UCL:masterfrom
ashgillman:clean-tof_sino_UCL

Conversation

@ashgillman

@ashgillman ashgillman commented Aug 17, 2021

Copy link
Copy Markdown
Collaborator

#304, plus:

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.
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].
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.
NikEfth and others added 24 commits December 18, 2020 01:15
…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...
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
@ashgillman

Copy link
Copy Markdown
Collaborator Author

@ashgillman

Copy link
Copy Markdown
Collaborator Author

I've tried and failed at testing each of the following:

mCT LM data

lm_to_projdata fails - "CListEventECAT8_32bit can only handle axial compression==1"

if (proj_data_info_ptr->get_max_ring_difference(0) != proj_data_info_ptr->get_min_ring_difference(0))
error(boost::format(
"CListEventECAT8_32bit can only handle axial compression==1, got segment 0 min/max RD: %s,%s")
% proj_data_info_ptr->get_max_ring_difference(0) % proj_data_info_ptr->get_min_ring_difference(0));

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 data

I've tried here my own data and data supplied by @Ede1994. These are compressed though, and I've tried and failed to use Siemens' intfcomr.exe to uncompress without success. Any hints here would be greatly appreciated:

C:\Siemens\PET>intfcompr -e V:\scratch\hoffstatic.hs --oe V:\scratch\hoffstatic_decomp.hs
I 08/17/2021 10:41:47.544 (UTC+10:00) build label: No version information
I 08/17/2021 10:41:47.554 (UTC+10:00) Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz (1x)    memory: 8190 MByte
I 08/17/2021 10:41:47.565 (UTC+10:00) Number of NUMA nodes: 1
I 08/17/2021 10:41:47.571 (UTC+10:00) Number of physical processor packages: 1
I 08/17/2021 10:41:47.581 (UTC+10:00) Number of processor cores: 4
I 08/17/2021 10:41:47.590 (UTC+10:00) Number of logical processors: 4
I 08/17/2021 10:41:47.598 (UTC+10:00) Number of processor L1/L2/L3 caches: 8/4/1
I 08/17/2021 10:41:47.610 (UTC+10:00) Hyper-Threading in BIOS Disabled.
I 08/17/2021 10:41:47.621 (UTC+10:00)  supported CPU features: MMX,SSE,SSE2,SSE3,SSE4.1,SSE4.2,AVX
I 08/17/2021 10:41:47.663 (UTC+10:00) GPU Driver Version: 8.16.7.5
I 08/17/2021 10:41:47.671 (UTC+10:00) GPU Driver supported CUDA Version: 0
I 08/17/2021 10:41:47.681 (UTC+10:00) CUDA runtime is newer than driver
I 08/17/2021 10:41:47.706 (UTC+10:00) uncompress 'V:\scratch\hoffstatic.s' into 'V:\scratch\hoffstatic_decomp.hs.s'
Possible data corruption.

C:\Siemens\PET>intfcompr -e V:\scratch\mct_wasser.hs --oe V:\scratch\mct_wasser_decomp
I 08/17/2021 10:42:48.398 (UTC+10:00) build label: No version information
I 08/17/2021 10:42:48.408 (UTC+10:00) Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz (1x)    memory: 8190 MByte
I 08/17/2021 10:42:48.420 (UTC+10:00) Number of NUMA nodes: 1
I 08/17/2021 10:42:48.426 (UTC+10:00) Number of physical processor packages: 1
I 08/17/2021 10:42:48.437 (UTC+10:00) Number of processor cores: 4
I 08/17/2021 10:42:48.445 (UTC+10:00) Number of logical processors: 4
I 08/17/2021 10:42:48.454 (UTC+10:00) Number of processor L1/L2/L3 caches: 8/4/1
I 08/17/2021 10:42:48.464 (UTC+10:00) Hyper-Threading in BIOS Disabled.
I 08/17/2021 10:42:48.472 (UTC+10:00)  supported CPU features: MMX,SSE,SSE2,SSE3,SSE4.1,SSE4.2,AVX
I 08/17/2021 10:42:48.515 (UTC+10:00) GPU Driver Version: 8.16.7.5
I 08/17/2021 10:42:48.523 (UTC+10:00) GPU Driver supported CUDA Version: 0
I 08/17/2021 10:42:48.531 (UTC+10:00) CUDA runtime is newer than driver
I 08/17/2021 10:42:48.555 (UTC+10:00) uncompress 'V:\scratch\mct_wasser.s' into 'V:\scratch\mct_wasser_decomp.s'

C:\Siemens\PET>

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 data

Using @NicoleJurjew 's data
This one has be a bit stumped: I'm running into: "ERROR: construct_proj_data_info: span -1 has to be larger than 0" when calling lm_to_projdata. This happens even when calling with a "dummy" template sinogram, and I believe is before loading the template, so it is coming from the loading of the LM data.

Full error:

~/src/STIR-clean-tof/build/test]$ INPUT=602-1.hl OUTPUT=602-1_esttrues TEMPLATE=dummyfile ../src/listmode_utilities/lm_to_projdata lm_to_projdata.par
+ INPUT=602-1.hl
+ OUTPUT=602-1_esttrues
+ TEMPLATE=avision_template_span11.hs
+ ../src/listmode_utilities/lm_to_projdata lm_to_projdata.par

WARNING: FactoryRegistry:: overwriting previous value of key in registry.
     key: None
WARNING: KeyParser: keyword 'isotope name' already registered for parsing, overwriting previous value
WARNING: KeyParser: keyword '%comment' already registered for parsing, overwriting previous value
WARNING: KeyParser warning: unrecognized keyword: %number of configured rings
WARNING: KeyParser warning: unrecognized keyword: gantry offset dimensions
WARNING: KeyParser warning: unrecognized keyword: %gantry offset (mm)
WARNING: KeyParser warning: unrecognized keyword: %gantry offset (mm)
WARNING: KeyParser warning: unrecognized keyword: %gantry offset (mm)
WARNING: KeyParser warning: unrecognized keyword: %gantry offset pitch (degrees)
WARNING: KeyParser warning: unrecognized keyword: %gantry offset yaw (degrees)
WARNING: KeyParser warning: unrecognized keyword: %gantry offset roll (degrees)
ERROR: construct_proj_data_info: span -1 has to be larger than 0
terminate called after throwing an instance of 'std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >'
Aborted (core dumped)

Which is coming from

if (span < 1)
error(boost::format("construct_proj_data_info: span %d has to be larger than 0") % span);

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:

!INTERFILE:=
%comment := Raw Listmode SubHeader for PETSYNGO_VG76B 766.200.1910.2101
!originating system := 1208
%sms-mi header name space := PETLINK raw data
%sms-mi version number := 3.9
!general data := 
!name of data file := 602-1.l
!general image data := 
!type of data := PET
%study date (yyyy:mm:dd) := 2021:05:27
%study time (hh:mm:ss gmt+00:00) := 14:29:53
isotope name := F-18
isotope gamma halflife (sec) := 6586.2
isotope branching factor := 0.9673
radiopharmaceutical := Fluorodeoxyglucose
relative time of tracer injection (sec) := 152336464
tracer activity at time of injection (bq) := 36980000.0
injected volume (ml) := 0.0
%tracer injection date (yyyy:mm:dd) := 2021:05:27
%tracer injection time (hh:mm:ss gmt+00:00) := 14:20:45
%patient orientation := HFS
pet data type := Emission
data format := CoincidenceList
horizontal bed translation := STEPPED
start horizontal bed position (mm) := -1765.32
end horizontal bed position (mm) := -1765.32
start vertical bed position (mm) := 195
%bed zero offset (mm) := -124.5
%coincidence window width (ns) := 4.72662
number of energy windows := 1
%energy window lower level (kev) [1] := 435
%energy window upper level (kev) [1] := 585
!pet study (emission data) := 
pet scanner type := cylindrical
transaxial fov diameter (cm) := 70.04
number of rings := 80
%number of configured rings := 80
distance between rings (cm) := 0.329114
gantry tilt angle (degrees) := 0
gantry crystal radius (cm) := 41
bin size (cm) := 0.16
septa state := none
gantry offset dimensions := 3
%gantry offset (mm) [1] := -0.021
%gantry offset (mm) [2] := -0.351
%gantry offset (mm) [3] := 756.766
%gantry offset pitch (degrees) := 0.072
%gantry offset yaw (degrees) := 0.044
%gantry offset roll (degrees) := -0.183
%number of tof time bins := 33
!image data description := 
%preset type := TIME
%preset value := 180
%preset unit := seconds
image duration (sec) := 180
%total listmode word counts := 19584512
%coincidence list data := 
%lm event and tag words format (bits) := 64
%timing tagwords interval (msec) := 1
%singles polling method := instantaneous
%singles polling interval (sec) := 2
%singles scale factor := 1
%total number of singles blocks := 152
number format := unsigned integer
!number of bytes per pixel := 4
imagedata byte order := LITTLEENDIAN
!END OF INTERFILE:=

Actually... Now that I write this out I notice that the mCT LM interfile had the following keys:

%axial compression := 11
%maximum ring difference := 49
%number of projections := 400
%number of views := 168
%number of segments := 9
%segment table := { 109, 97, 97, 75, 75, 53, 53, 31, 31 }

I guess these may have been necessary for STIR...

@ashgillman

Copy link
Copy Markdown
Collaborator Author

Update for the Vision 600:

I had to add %axial compression := 1 to the Vision LM data - but it seems this isn't in there by default.

Now a new problem is working out the layout of the singoram, described in 6.3.1 here:
https://link.springer.com/chapter/10.1007%2F978-3-030-43040-5_6

This is definitely for another PR! Lets get the mCT working and test with that...

@KrisThielemans

Copy link
Copy Markdown
Collaborator

This PR should be closed. I'm not sure how much of this should be merged onto the normal TOF PR #304. Better to do that soon, or create a new PR to #304.

@KrisThielemans

Copy link
Copy Markdown
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants