[Gate-users] LMF '***.css' analysis
MOREL Christian
morel at cppm.in2p3.fr
Sun Oct 14 17:03:30 CEST 2018
Dear Donghyeon Lee,
Since you are using only 16 bits to store your detector ID, the first 5 u16 are employed the way you have decoded it. Then, the bytes following these 5 u16 are read and decoded on their own. Therefore, you do not have to revert the byte order anymore, which should read:
1111111111111100 : 1st u16
111111100100000: 2nd u16 for the crystal ID rule
0101001110111111: 3rd u16 for the general topology
010100100000111: 4th u16 for the tangential topology
0000000110000111: 5th u16 for the axial topology
00000000
00000001: 1 record type only
00000110: TTTcdEn corresponding to event record tag (TTTT= 0000), consisting of singles (c = 0), with storage of detecor ID (d = 1) and energy (E = 1).
00110000: NNgbsGZR corresponding to the second byte describing the event tag, here with storage of the gantry angular position (g = 1) and the gantry axial (bed) position (b = 1)
This means that every 15 bytes following this header will form an event record consisting of 8 bytes for the time stamp, followed by two bytes for the gantry angular position, 2 bytes for the bed position, 2 bytes for the detector id and 1 byte for the deposited energy.
Hope this helps, regards, Christian Morel
> Le 27 sept. 2018 à 08:05, Donghyeon Lee <leedhyun85 at kaist.ac.kr> a écrit :
>
> Dear Christian
>
> I sincerely think you for your detail answer.
> The answer you wrote is exactly what I wanted.
> I checked the output and compared your answer.
>
> But there are a little differences.
>
> The following is the encorded output I got:
>
> 1111111111111100
> 1111111001000000
> 0101001110111111 - x
> 0101001000000111 - y
> 0000000110000111 - z
> 0000000100000000
> 0011000000000110
>
> As you can notice, first u16 refers to the size of integer values. 00 stands for 'u16'. 01 for 'u32' and 10 for 'u64', for example.
> Then I think next16 bits encoding rule is followed:
>
> 7 bits Rsectors
> 2 bits Modules
> 1 bit Submodule
> 7 bits Crystals
> 0 bit Layer
>
> In my opinion, the reason why Rsectors has 7 bits is that there is only one layer and it dose require any bit to record.
> And the followings have same rules you wrote.
>
> But I couldn't understand the number emphasized by blue.
> It doesn't seem to follow the rule.
> I am still confused about the event record part....
>
> 1111111111111100
> 1111111001000000
> 0101001110111111 - x
> 0101001000000111 - y
> 0000000110000111 - z
> 0000000100000000
>
> 0011000000000110
> 0000000000000000
> 0000000000000000
> 0010110100000000
> 1111111101111111
>
> 1011001100011010
>
> I copy and paste first 12 of 'u16' if it would help you to make out the output.
> Thank you.
>
> Best regard,
> Donghyeon Lee.
>
>
>
> -----------------------원본메일-----------------------
> 보낸사람 : MOREL Christian <morel at cppm.in2p3.fr>
> 받는사람: gate-users at lists.opengatecollaboration.org
> 보낸날짜: 2018-09-21 02:52:43 GMT +0900 (Asia/Seoul)
> 제목: Re: [Gate-users] LMF '***.css' analysis
> 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 <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 <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 <http://imxgam.in2p3.fr/>
>
> _______________________________________________
> Gate-users mailing list
> Gate-users at lists.opengatecollaboration.org
> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20181014/622acfe5/attachment-0001.html>
More information about the Gate-users
mailing list