[Gate-users] LMF '***.css' analysis
MOREL Christian
morel at cppm.in2p3.fr
Thu Sep 20 19:52:43 CEST 2018
Dear Donghyeon Lee,
The first u16 is used to set the number of bits used to store detector ID. Integer values of 0, 1, and 2 are used to set it to 16-, 32- and 64-bits, respectively. If the first bit of the LMF encoding header is equal to 1, detector ID is encoded over 16 bits by default. In this case, the LMF encoding header starts directly by the rule used to store the encoding rule for detector ID described below. Since you are encoding your detector id on 16 bits, the first u16 directly specifies your scanner topology, e.g. 1111110010000001, i.e.:
111111 [for numbering 42 Rsectors (numbered from 0 to 41) on 6 bits allowing to identify 64 Rsectors]
00 [for numbering 4 Modules (numbered from 0 to 3) on 2 bits]
1 [for numbering 1 Submodule (numbered 0) on 1 bit]
000000 [for numbering 64 Crystals (numbered from 0 to 64) on 6 bits]
1 [for numbering 1 Layer (numbered 0) on 1 bit]
Then this 16 bits encoding rule is followed by the very description of your scanner topology: i.e. 1010011101111110, i.e.:
101001 [=41+1 Rsectors]
11 [=3+1 Modules]
0 [=0+1 Submodule]
111111 [=63+1 Crystals]
0 [=0+1 Layer]
The following two u16 describe the tangential and axial topology. In your case, the tangential encoding will be 1010010000001110, i.e.:
101001 [=41+1 Rsectors]
00 [=0+1 Modules]
0 [=0+1 Submodule]
000111 [=7+1 Crystals]
0 [=0+1 Layer]
and the axial encoding will be 0000001100001110, i.e.:
000000 [=0+1 Rsectors]
11 [=3+1 Modules]
0 [=0+1 Submodule]
000111 [=7+1 Crystals]
0 [=0+1 Layer]
Hence the encoding header of your ccs file will comprise 6 u16:
1111110010000001
1010011101111110
1010010000001110
0000001100001110
0000000000000001
0000011000110000
The 5th one is used to store the number of record types (1 in your case) and the 6th one to describe the event format (event record header), i.e. in your case:
0000 [this record is an event record]
0 [this is a single]
1 [id is stored on 16 bits]
1 [energy is stored on 8 bits]
0 [no energy and DOI from neighboring crystals]
00 [not used since no energy from neighboring crystals]
1 [azimuth position stored on 16 bits (you do not need this if your scanner is not rotating)]
1 [axial position stored on 16 bits (you also do not need this if your bed is not moving axially)]
0000 [not used in your case]
Thus, each event record will be stored on 64 bits for tag (first bit set to 0) and time (63 following bits) + 16 bits (for detector id) + 8 bits (for energy) + 16 bits (for azimuthal position) + 16 bits (for axial position) = 120 bits (15 bytes).
Then, all the following block of 120 bits (15 bytes) are used to store events, one event per block of 120 bits.
Hope this answers your question.
With kind regards, Christian Morel
> Le 20 sept. 2018 à 10:18, Donghyeon Lee <leedhyun85 at kaist.ac.kr> a écrit :
>
> Hello, Christian Morel
>
> Thank you for your answer.
> What I wrote in '.mac' is to get output below:
>
> /gate/output/lmf/enable
> /gate/output/lmf/setFileName benchmarkPET
> /gate/output/lmf/setDetectorIDBool 1
> /gate/output/lmf/setEnergyBool 1
> /gate/output/lmf/setGantryAxialPosBool 1
> /gate/output/lmf/setGantryAngularPosBool 1
> /gate/output/lmf/setSourcePosBool 0
> /gate/output/lmf/setNeighbourBool 0
> /gate/output/lmf/setNeighbourhoodOrder 0
> /gate/output/lmf/setCoincidenceBool 0
> /gate/output/lmf/setGateDigiBool 0
> /gate/output/lmf/setComptonBool 0
> /gate/output/lmf/setSourceIDBool 0
> /gate/output/lmf/setSourceXYZPosBool 0
> /gate/output/lmf/setGlobalXYZPosBool 0
> /gate/output/lmf/setEventIDBool 0
> /gate/output/lmf/setRunIDBool 0
>
> And the size of binary encording is uin16.
>
> The numbers of Rsectors, Modules, and Crystals are 42, 1*1*4, 1*8*8 for each. (x*y*z)
>
> I hope this answers are helpful for you to understand.
>
> Best regards,
> Donghyeon Lee.
>
>
>
> -----------------------Original Message-----------------------
> From: MOREL Christian <morel at cppm.in2p3.fr>
> To: gate-users at lists.opengatecollaboration.org
> Sent date: 2018-09-20 01:20:55 GMT +0900 (Asia/Seoul)
> Subject: Re: [Gate-users] LMF '***.css' analysis
> Dear Donghyeon Lee,
>
> Can you specify me the size of your detector id encoding (16 bits, 32 bits or 64 bits ?)
>
> Looking forward to receiving your answer, with kind regards, Christian Morel
>
>> Le 17 sept. 2018 à 06:18, Donghyeon Lee < leedhyun85 at kaist.ac.kr> a écrit :
>>
>> Dear all GATE users,
>>
>> Hello, I tried to get the information from the LMF(.css) output recently.
>> I read the four documents in the folder(LMF_v3.0) but still not clear.
>> In particular, 'LMF_specifs.pdf', which is about the encoding order for '***.css'.
>>
>> I successfully decorded 'the LMF encoding header' at the '***.css' file, but not following 'the LMF event record'.
>> To understand the encording order of it, I compared the number I got from the file and the document several times....
>>
>> Can you explain the encording order of 'The LMF event record'?
>> Or Is there additional materials to analyse this LMF file?
>>
>> And there were several questions which are similar with this question such as
>> http://lists.opengatecollaboration.org/pipermail/gate-users/2016-October/009182.html
>> and some others. But it wasn't the one for me.
>>
>> I appreciate your attention for my question.
>>
>> Best regards,
>> Donghyeon Lee.
>>
>> Donghyeon Lee
>> Ph.D Candidate
>> Medical Imaging & Radiotherapeutics Lab
>> Dept. Nuclear and Quantum Engineering
>> KAIST
>> Office: +82-42-350-3868
>> Cell: +82-10-2859-6932
>> leedhyun85 at kaist.ac.kr
>> _______________________________________________
>> Gate-users mailing list
>> Gate-users at lists.opengatecollaboration.org
>> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users
__________________
Christian MOREL, PhD
Professeur des universités
Centre de Physique des Particules de Marseille (CPPM)
Aix-Marseille Université et CNRS/IN2P3
163, Av. de Luminy, Case 902, 13288 Marseille, France
tel: +33 (0)4 91 82 76 73
fax: +33 (0)4 91 82 72 99
mobile: +33 (0)6 16 44 20 16
email: morel at cppm.in2p3.fr
url: http://imXgam.in2p3.fr
More information about the Gate-users
mailing list