[gate-users] Re: gate-users Digest, Vol 18, Issue 11

Jianfeng He jfenghe at petnm.unimelb.edu.au
Tue Sep 13 01:50:36 CEST 2005 

Dear Vandana,

Thank you so much! I also met an interrupting error message during
simulating that could be related to memory leak issues on Fedora core 4.
I will try to reinstall GATE on Fedora core 3. Thanks again!

Regards,

Jianfeng


On Mon, 2005-09-12 at 21:23 +0200, gate-users-request at lphe1pet1.epfl.ch
wrote:
> Send gate-users mailing list submissions to
> 	gate-users at lphe1pet1.epfl.ch
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
> 
> Please use the GATE's site webmaster e-mail to  reach the person
> managing the list.
> 
> 
> Today's Topics:
> 
>    1. syntax error (Sweta)
>    2. Re: syntax error (Justin Dingley)
>    3. Re: RE: STIR reconstruction software (GATE simualtions)
>       (Claude Comtat)
>    4. RE: RE: STIR reconstruction software (GATE simualtions)
>       (Kris Thielemans)
>    5. Re: Benchmark (Vandana Kohli)
>    6. Re: RE: STIR reconstruction software (GATE simualtions)
>       (Vandana Kohli)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 12 Sep 2005 12:37:35 +0100 (BST)
> From: Sweta <sweta_indbhavan at yahoo.co.in>
> Subject: [gate-users] syntax error
> To: gate-users at lphe1pet1.epfl.ch
> Message-ID: <20050912113735.43044.qmail at web8405.mail.in.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Dear all,
>  
> I am trying to install GATE v 2.2.0 on RedHat Linux 9 with GEANT and CLHEP in place.
>  
> I get the following error 
>  
> # source env_gate.csh
> bash: env_gate.csh: line 137: syntax error near unexpected token 'else'
> bash: env_gate.csh: line 137: '     else'
>  
> I checked the number of If's and else's in the env_gate.csh file and it looks OK!
>  
> Regards,
> Sweta
>  
> 
> 		
> ---------------------------------
>  Yahoo! India Matrimony: Find your partner now.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lphe1pet1.epfl.ch/mailman/private/gate-users/attachments/20050912/6731f510/attachment-0001.htm
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 12 Sep 2005 09:14:48 -0400 (EDT)
> From: Justin Dingley <weebl411 at ufl.edu>
> Subject: Re: [gate-users] syntax error
> To: sweta_indbhavan at yahoo.co.in,   GATE feedback and helpline for
> 	Users <gate-users at lphe1pet1.epfl.ch>
> Message-ID:
> 	<895443591.1126530888081.JavaMail.osg at osgjas01.cns.ufl.edu>
> Content-Type: text/plain; format=flowed; charset=us-ascii
> 
> 
> Sweta-
> The problem is that you're trying to source a csh script from the 
> bash shell. Just switch to the c shell and it should work.
> 
> 
> 
> Justin Dingley
> 
> Medical Physics
> University of Florida
> weebl411 at ufl.edu
> (352)219-5529
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 12 Sep 2005 15:58:27 +0200
> From: Claude Comtat <comtat at shfj.cea.fr>
> Subject: Re: [gate-users] RE: STIR reconstruction software (GATE
> 	simualtions)
> To: GATE feedback and helpline for Users
> 	<gate-users at lphe1pet1.epfl.ch>
> Cc: 'Vandana Kohli' <kohli.vandana at gmail.com>
> Message-ID: <43258983.1090704 at shfj.cea.fr>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Dear Vandana and Kris,
> 
> just to confirm that Kris is correct.
> 
> > 
> > My understanding is that as long as you are simulating a CTI/Siemens PET
> > scanner that actually exists and is supported by STIR (which essentially
> > means one that outputs ECAT7 data, so no PET/CT), then you don't have to do
> > anything specific. 
> > 
> > One of the problems with ECAT7 output is that it doesn't contain all scanner
> > dimensions. Instead, it contains a system_type field. If GATE fills this in
> > correctly, then STIR can figure out the dimensions and off you go.
> 
> You need the following command in GATE to specify our system ID:
> 
> /gate/output/ecat7/system XXX
> 
> 
> > An alternative way would be to let GATE write Interfile headers that STIR
> > can understand. This shouldn't be incredibly difficult, but I don't know of
> > anybody who has plans in that direction.
> 
> For now, the sinogram outputs (raw or ecat7) are only defined for ECAT
> systems as the LOR-to-SinogramBIN conversion follows the ECAT
> specifications. It means, in particular, that the sinogram radial
> sampling is not uniform (arc effect) and requires reconstruction
> routines that handle this specific feature. If we can keep these ECAT
> specifications, it is quite straightforward to convert an ECAT7 sinogram
> to an Interfile sinogram (remove the binary headers and directory
> matrices and write a separate ascii header file, plus byte swapping for
> the raw data if needed).
> 
> An alternative, valid for all PET systems, would be to have an "exact"
> rebining from the LOR to the sinogram (or projection ) space (calculate
> for each LOR the four projection coordinates --- radial and axial
> positions ; azimuthal and co-polar angles --- and then fill the
> corresponding 4D sinogram or projection bin). As they are different ways
> to define the projections coordinates (co-polar angle or its tangential
> ?), the reconstruction routines should follows the same definition ...
> 
> Kris, do you think that such an output would be useful for STIR ? If
> yes, a correct geometrical normalization of the data will also be needed.
> 
> All the best,
> 
> 
> Claude
> 
> 
> -- 
> Claude Comtat					comtat at ieee.org
> Image Acquisition and Processing group		tel: +33 1 69 86 78 01
> Frdric Joliot Hospital Facility		fax: +33 1 69 86 77 49
> French Atomic Energy Commission 		www-dsv.cea.fr/shfj
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 12 Sep 2005 19:19:00 +0100
> From: "Kris Thielemans" <kris.thielemans at csc.mrc.ac.uk>
> Subject: RE: [gate-users] RE: STIR reconstruction software (GATE
> 	simualtions)
> To: "'GATE feedback and helpline for Users'"
> 	<gate-users at lphe1pet1.epfl.ch>
> Cc: 'Vandana Kohli' <kohli.vandana at gmail.com>
> Message-ID: <001901c5b7c6$7295ba70$0d0a10ac at bach>
> Content-Type: text/plain;	charset="US-ASCII"
> 
> 
> Hi Claude
> 
> > 
> > > An alternative way would be to let GATE write Interfile 
> > headers that 
> > > STIR can understand. This shouldn't be incredibly difficult, but I 
> > > don't know of anybody who has plans in that direction.
> > 
> > For now, the sinogram outputs (raw or ecat7) are only defined 
> > for ECAT systems as the LOR-to-SinogramBIN conversion follows 
> > the ECAT specifications. It means, in particular, that the 
> > sinogram radial sampling is not uniform (arc effect) and 
> > requires reconstruction routines that handle this specific 
> > feature. If we can keep these ECAT specifications, it is 
> > quite straightforward to convert an ECAT7 sinogram to an 
> > Interfile sinogram (remove the binary headers and directory 
> > matrices and write a separate ascii header file, plus byte 
> > swapping for the raw data if needed).
> > 
> 
> You can keep ECAT conventions without changes. 
> 
> As an example, STIR contains a utility ifheaders_for_ecat7 which given an
> ECAT7 file, it cooks up an Interfile header that points towards the binary
> data in the ECAT7 file. Of course, this routine can only give correct
> scanner dimensions if the system_type is known.
> 
> 
> So, maybe a very ugly work-around would be to let GATE write an ECAT7 file
> (with some junk system_type), run ifheaders_for_ecat7 on the data, and then
> correct the scanner dimensions etc by hand.
> 
> An alternative would be to write some extra code for GATE that essentially
> writes only the binary data of the sinogram (just as it would have done for
> ECAT7), but writes in addition a fairly simple text file (with the Interfile
> header).
> 
> Unfortunately, I'm not volunteering.
> 
> [In fact, all the stuff that we say is still correct for GE scanners (to the
> best of my knowledge, although this is limited...). The main difference
> between GE VOLPET and ECAT files is the order of the data and the different
> axial compression scheme. In essence, VOLPET uses span=3 for segment 0, and
> no axial compression (span=1) for all ring differences>1.]
> 
> > An alternative, valid for all PET systems, would be to have 
> > an "exact" rebining from the LOR to the sinogram (or 
> > projection ) space 
> <snip>
> > 
> > Kris, do you think that such an output would be useful for 
> > STIR ?
> 
> Not necessary, no. In any case, you wouldn't want that for iterative
> reconstructions I think.
> 
> 
> 
> Kris
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 12 Sep 2005 12:20:30 -0700
> From: Vandana Kohli <kohli.vandana at gmail.com>
> Subject: Re: [gate-users] Benchmark
> To: GATE feedback and helpline for Users
> 	<gate-users at lphe1pet1.epfl.ch>
> Message-ID: <298e9e1705091212202fd65938 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Dear Jianfeng,
> I was using Fedora core 4 for sometime. It has had issues with memory leak 
> and all that stuff. The GATE software has not been tested for Fedora core 4. 
> I downgraded to Fedora core 3. That is what I am using right now.
> Vandana Kohli
> 
>  On 9/11/05, Jianfeng He <jfenghe at petnm.unimelb.edu.au> wrote: 
> > 
> > Dear all,
> > 
> > Has somebody validated successfully the benchmarkPET with GATE package
> > in the following environment:
> > Fedora Core 4
> > gcc 4.0.0
> > Geant4.7.0.p01
> > CLHEP 1.8.1.0 <http://1.8.1.0>,
> > Root 4.03/04,
> > GATE2.2.0
> > 
> > After installation and benchmark, I got a strange problem about
> > benchmark result that one detector head was lost in the plots of the
> > benchmark compared with the reference plots of benchmark(normally it
> > should be 8 repeat head).
> > 
> > I modified the camera.mac file of bechmark related to the part of repeat
> > head, adding one more the setRepeatNumber from 8 to 9, then running
> > benchmark again. The result of benchmark seems to be close the reference
> > as follow:
> > 
> > Acquisition start time = 0 [s]
> > Acquisition stop time = 240 [s]
> > O-15 decay factor = 0.546383
> > F-18 decay factor = 0.987477
> > O-15 initial activity = 100000 [Bq]
> > F-18 initial activity = 100000 [Bq]
> > O-15 decays = 1.31132e+07
> > F-18 decays = 2.36994e+07
> > ==> Expected total number of decays during the acquisition is 3.68126e
> > +07 +/- 6067.34
> > There are 3.68072e+07 recorded decays
> > There are 314545 true unscattered coincidences
> > There are 24421 random coincidences
> > There are 369822 scattered coincidences
> > ==> there are 708788 coincidences (true, scattered, and random)
> > ==> global scatter fraction = 0.540385
> > ==> absolute sensitivity = 0.854573 %
> > Measured O-15 life-time = 123.607 [s]
> > Nominal O-15 life-time = 122.24 [s]
> > ==> difference = 1.11809 %
> > Gamma acolinearity FWHM = 0.606303 degree (expected: 0.58)
> > 
> > Does anybody have any idea why one detector head is lost? Thanks a lot!
> > 
> > Regards,
> > 
> > Jianfeng
> > 
> > 
> > 
> > 
> > _______________________________________________
> > gate-users mailing list
> > gate-users at lphe1pet1.epfl.ch
> > http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lphe1pet1.epfl.ch/mailman/private/gate-users/attachments/20050912/834de7d0/attachment-0001.htm
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 12 Sep 2005 12:22:39 -0700
> From: Vandana Kohli <kohli.vandana at gmail.com>
> Subject: Re: [gate-users] RE: STIR reconstruction software (GATE
> 	simualtions)
> To: Kris Thielemans <kris.thielemans at csc.mrc.ac.uk>
> Cc: GATE feedback and helpline for Users
> 	<gate-users at lphe1pet1.epfl.ch>
> Message-ID: <298e9e17050912122228c485a3 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Dear Kris and Claude,
> Thanks for your reply. As of now I am simulating CTI/Siemens scanner so I 
> should be okay with using STIR reconstruction software.
> cheers
> Vandana 
> 
> 
>  On 9/12/05, Kris Thielemans <kris.thielemans at csc.mrc.ac.uk> wrote: 
> > 
> > 
> > Hi Claude
> > 
> > >
> > > > An alternative way would be to let GATE write Interfile
> > > headers that
> > > > STIR can understand. This shouldn't be incredibly difficult, but I
> > > > don't know of anybody who has plans in that direction.
> > >
> > > For now, the sinogram outputs (raw or ecat7) are only defined
> > > for ECAT systems as the LOR-to-SinogramBIN conversion follows
> > > the ECAT specifications. It means, in particular, that the
> > > sinogram radial sampling is not uniform (arc effect) and
> > > requires reconstruction routines that handle this specific
> > > feature. If we can keep these ECAT specifications, it is
> > > quite straightforward to convert an ECAT7 sinogram to an
> > > Interfile sinogram (remove the binary headers and directory
> > > matrices and write a separate ascii header file, plus byte
> > > swapping for the raw data if needed).
> > >
> > 
> > You can keep ECAT conventions without changes.
> > 
> > As an example, STIR contains a utility ifheaders_for_ecat7 which given an
> > ECAT7 file, it cooks up an Interfile header that points towards the binary
> > data in the ECAT7 file. Of course, this routine can only give correct
> > scanner dimensions if the system_type is known.
> > 
> > 
> > So, maybe a very ugly work-around would be to let GATE write an ECAT7 file
> > (with some junk system_type), run ifheaders_for_ecat7 on the data, and 
> > then
> > correct the scanner dimensions etc by hand.
> > 
> > An alternative would be to write some extra code for GATE that essentially
> > writes only the binary data of the sinogram (just as it would have done 
> > for
> > ECAT7), but writes in addition a fairly simple text file (with the 
> > Interfile
> > header).
> > 
> > Unfortunately, I'm not volunteering.
> > 
> > [In fact, all the stuff that we say is still correct for GE scanners (to 
> > the
> > best of my knowledge, although this is limited...). The main difference
> > between GE VOLPET and ECAT files is the order of the data and the 
> > different
> > axial compression scheme. In essence, VOLPET uses span=3 for segment 0, 
> > and
> > no axial compression (span=1) for all ring differences>1.]
> > 
> > > An alternative, valid for all PET systems, would be to have
> > > an "exact" rebining from the LOR to the sinogram (or
> > > projection ) space
> > <snip>
> > >
> > > Kris, do you think that such an output would be useful for
> > > STIR ?
> > 
> > Not necessary, no. In any case, you wouldn't want that for iterative
> > reconstructions I think.
> > 
> > 
> > 
> > Kris
> > 
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lphe1pet1.epfl.ch/mailman/private/gate-users/attachments/20050912/fd85ddc3/attachment.htm
> 
> ------------------------------
> 
> _______________________________________________
> gate-users mailing list
> gate-users at lphe1pet1.epfl.ch
> http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
> 
> End of gate-users Digest, Vol 18, Issue 11
> ******************************************
>

More information about the Gate-users mailing list