STIR
STIR copied to clipboard
UCL
TIme of Flight - clean
#304, plus:
- merged master following whitespace cleanups (#724)
- definition for Vision (perhaps we'd want this for a separate PR?)
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"
https://github.com/UCL/STIR/blob/59ab3eadadfe514fa5d4a823a6db305c9193567a/src/listmode_buildblock/CListRecordECAT8_32bit.cxx#L43-L46
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
https://github.com/UCL/STIR/blob/59ab3eadadfe514fa5d4a823a6db305c9193567a/src/buildblock/ProjDataInfo.cxx#L409-L410
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...
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...
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.
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.