checking ECAT8 normalisation code for Siemens scanners other than the mMR

[KrisThielemans]

Since #352, the code is generic, but it has been untested (aside from the mMR). Comments on how to do this are in #352.

[danieldeidda]

norm3D.h33 is a s follow:

!INTERFILE name of data file := norm3d_00.a image data byte order := LITTLEENDIAN number of dimensions := 3 matrix size [1] := 400 matrix size [2] := 168 matrix size [3] := 621 number of z elements := 109 194 150 106 62 number format := float number of bytes per pixel := 4 data offset in bytes := 0 scaling factor (mm/pixel) [1] := 2.005 scaling factor (mm/pixel) [2] := 1.0 scaling factor (mm/pixel) [3] := 2.027

[KrisThielemans]

that seems to be an attenuation file

[danieldeidda]

no clue. Is it possible that this is actually a normalization sinogram extracted by e7tools?

[KrisThielemans]

could be, but in any case, we need the original component-based norm to be independent of the e7tools.

Might be good to have a screenshot o fyour file (a single sinogram or so)

[danieldeidda]

[KrisThielemans]

ok. definitely looks like a norm sinogram. So it's great to have this such that we can compare to it. STIR's Siemens interfile reader will probably not be happy about the header, as it expects some Siemens keywords. You could just copy the emission header presumably. files should be the same size (maybe a factor because of floats vs short ints).

Do we have the original component based header as well?

[danieldeidda]

George is going to send the .n/.n.hdr as soon as he extracts it with e7tools. Then I can run correct_projdata

[danieldeidda]

running correct projdata gives the following: ERROR: Unknown originating_system '1104', when parsing file 'norm_sinogram/use_EXPORT_PET_RAW_DATA-norm.n.hdr'

[danieldeidda]

is this the name of the mCT?

[danieldeidda]

Although it seems that "1104" name is listed in Scanner.

[KrisThielemans]

it should have picked it up, but I guess you can try to replace the name with mCT and see what happens...

[danieldeidda]

I tried all these but I get the same: "Siemens mCT", "mCT", "2011", "1104"

[KrisThielemans]

parsing is https://github.com/UCL/STIR/blob/fa10cd3cac20bf858287f9a06b602b1a51e1ee97/src/recon_buildblock/BinNormalisationFromECAT8.cxx#L272 clean-up https://github.com/UCL/STIR/blob/fa10cd3cac20bf858287f9a06b602b1a51e1ee97/src/recon_buildblock/BinNormalisationFromECAT8.cxx#L279-L281 construction here https://github.com/UCL/STIR/blob/fa10cd3cac20bf858287f9a06b602b1a51e1ee97/src/recon_buildblock/BinNormalisationFromECAT8.cxx#L286

I don't see anything wrong, so I suspect that there is a problem with line-endings, that I referred to during the tcon. The "clean-up" code tries to solve this, but might fail. pet-rd-tools nm_extract would take care of this, but in this data it might still be here.

Can you post the header here as an attachment (not paste the content itself)

[KrisThielemans]

or the link

[danieldeidda]

https://drive.google.com/file/d/1YL7VpNN0N73MPcIIPMfxHBFirWiafHAO/view?usp=sharing

[KrisThielemans]

try

tr -d '\r' < use_EXPORT_PET_RAW_DATA-norm.n.hdr >new_norm.n.hdr

[KrisThielemans]

this gets rid of the DOS-style EOL and just keeps the unix ones. (normally dos2unix should work, but because the file isn't consistent in its EOL convention, it could fail)

[danieldeidda]

nothing changes. I noticed that there is a weird character at the very end when I open with gedit.

[KrisThielemans]

yes. there's a 0 character. you could delete the end bit.. check with od -c new_norm.n.hdr

[danieldeidda]

Now I get this: WARNING: KeyParser: keyword 'scan data type description' already registered for parsing, overwriting previous value

WARNING: KeyParser warning: early EOF or bad file

WARNING: KeyParser error: required first keyword "interfile" not found

WARNING: Interfile parsing of Siemens Interfile projection data failed

ERROR: ProjData::read_from_file could not read projection data raw_data_scanner_sino_LM/PETSINO_2_0_0_2.0.176555216.s.hdr. Unsupported file format? Aborting. terminate called after throwing an instance of 'std::__cxx11::basic_string<char, std::char_traits, std::allocator >' Aborted (core dumped)

also I have loads of warnings of unrecognized keywords

[KrisThielemans]

well, this is now an error on the sinogram. So I guess you need to post that header. (not sure where they all are, sorry)

There's a few hurdles on this though:

• it'll be TOF sinogram, so we cannot read it anyway
• more than likely it will be compressed by the scanner, so we couldn't read it with the TOF branch as well

Note: to be able the listmode data, we'll also have to collapse the TOF dimension.

However, to test the normalisation, we don't need to use measured data luckily. We should use output of create_projdata_template (mCT, mash=2, span=11, max-ring-diff=49, no arc-correction). Then need to do

export INPUT=template.hs
export OUTPUT=norm_projdata.hs
export ECATNORM=norm.n.hdr
correct_projdata ~/devel/STIR/examples/Siemens-mMR/correct_projdata_nogaps.par

[danieldeidda]

This seems to work. The segment 0 is the following:

[danieldeidda]

The interfile header for the sinogram is this:

https://drive.google.com/file/d/1jDEsKUcWQ_H-odO0dM5OugVADFkctNla/view?usp=sharing

[danieldeidda]

to test the normalisation factors use:

export INPUT=template.hs
export OUTPUT=norm_projdata.hs
export ECATNORM=norm.n.hdr
correct_projdata ~/devel/STIR/examples/Siemens-mMR/correct_projdata_nogaps.par

to read the sinogram from e7tools I need to create a template like the follwoing:

!INTERFILE  :=
!imaging modality := PT
name of data file := norm3d_00.a
originating system := Siemens mCT
!version of keys := STIR4.0
!GENERAL DATA :=
!GENERAL IMAGE DATA :=
!type of data := PET
imagedata byte order := LITTLEENDIAN
!PET STUDY (General) :=
!PET data type := Emission
applied corrections := {None}
!number format := float
!number of bytes per pixel := 4
number of dimensions := 4
matrix axis label [4] := segment
!matrix size [4] := 9
matrix axis label [2] := view
!matrix size [2] := 168
matrix axis label [3] := axial coordinate
!matrix size [3] := { 109, 97, 97, 75, 75, 53, 53, 31,31}
matrix axis label [1] := tangential coordinate
!matrix size [1] := 400
minimum ring difference per segment := { -5, -16,6,-27,17,-38,28,-49,39}
maximum ring difference per segment := { 5,-6,16,-17,27,-28,38,-39,49}
Scanner parameters:= 
Scanner type := Siemens mCT
Number of rings                          := 55
Number of detectors per ring             := 672
Inner ring diameter (cm)                 := 84.2
Average depth of interaction (cm)        := 0.7
Distance between rings (cm)              := 0.4054
Default bin size (cm)                    := 0.2005
View offset (degrees)                    := 0
Maximum number of non-arc-corrected bins := 400
Default number of arc-corrected bins     := 400
Number of blocks per bucket in transaxial direction         := 1
Number of blocks per bucket in axial direction              := 4
Number of crystals per block in axial direction             := 14
Number of crystals per block in transaxial direction        := 14
Number of detector layers                                   := 1
Number of crystals per singles unit in axial direction      := 0
Number of crystals per singles unit in transaxial direction := 0
end scanner parameters:=
effective central bin size (cm) := 0.200089
number of time frames := 1
start vertical bed position (mm) := 0
start horizontal bed position (mm) := 0
!END OF INTERFILE :=

after this we can extract_segments for the norm_proj created with STIR and the one created with e7tools. looking at the segments there seems to be a difference in pattern but also in scale.

[KrisThielemans]

@gnee-git do you have an attenuation correction file in the same format as the norm above? (i.e. as a sinogram). would be easier to debug that...

[gnee-git]

Sorry for the delay - had a few meetings and e7 tools is playing up again. BUT I've found some example ACF sinograms from some mCT test data Siemens sent. I've uploaded them here: https://drive.google.com/drive/folders/1sb4eUVtzRjSOSL9_dJTM1WIzNfR-l_5e?usp=sharing

[danieldeidda]

Is this supposed to have the same dimensions as the norm?

[KrisThielemans]

Now I get this: WARNING: KeyParser: keyword 'scan data type description' already registered for parsing, overwriting previous value WARNING: KeyParser warning: early EOF or bad file WARNING: KeyParser error: required first keyword "interfile" not found WARNING: Interfile parsing of Siemens Interfile projection data failed ERROR: ProjData::read_from_file could not read projection data raw_data_scanner_sino_LM/PETSINO_2_0_0_2.0.176555216.s.hdr.

Caused by #620. but then there's other failures down the line. see #622

[KrisThielemans]

I've found some example ACF sinograms from some mCT test data Siemens sent

ah. fun. This is more like a normal sinogram header (but just a bit different such that we cannot read this either). I see though

matrix size[1]:=336
matrix size[2]:=168
matrix size[3]:=559

applied corrections:={radial arc-correction,xy-smoothing,z-smoothing}

%number of segments:=7
%segment table:={109,97,97,75,75,53,53}

which means that we cannot use it for a non-arccorrected dataset.

This might not help us figuring out what we do wrong with the norm.

I suppose we could see if a small mod of the norm3d.hs above would at least read it sensible

matrix axis label [4] := segment
!matrix size [4] := 7
matrix axis label [2] := view
!matrix size [2] := 168
matrix axis label [3] := axial coordinate
!matrix size [3] := { 109, 97, 97, 75, 75, 53, 53}
matrix axis label [1] := tangential coordinate
!matrix size [1] := 336
minimum ring difference per segment := { -5, -16,6,-27,17,-38,28}
maximum ring difference per segment := { 5,-6,16,-17,27,-28,38}
applied corrections:={arc-correction}

[danieldeidda]

I suppose we could see if a small mod of the norm3d.hs above would at least read it sensible

what do you mean with small mod?

[danieldeidda]

Possible check: if we have data from an easy object, like a cylinder and apply the normalisation to the emission sino, we can see whether at least it reduces artifacts. The issue at the moment is that we cannot read the sinogram due to #620 and #622 ?

[KrisThielemans]

624 contains some notes on adding the axial effects

[KrisThielemans]

There's plenty more info in #624 (which is now merged). Sadly, we still cannot read the mCT norm properly. Not sure why,