[Stir-devel] Re: [gate-users] updated proposal and patches

[null99 at mails.tsinghua.edu.cn]

Dear Claude,

Thank you very much!

You are absolutely right, so is your proposal. 

My idea is very simply. Since the LOR of two pair of (x,y,x) and director ID
(layer) of cocidence in LMF file can be extracted (Please refer to pg2~3 of
LMF.pdf in lmfv1.0/document/, and exampleMain_05.c in lmfv1.0/examples/), the four
parameter of 3D scan can be achieved. 

Based on this, we can build logical rings (not the cylindrical system ring, but
the ecat ring) to enable span, and build logical detector id (with even space at
all angles, similar to the arc corrected ecat distribution) to enable  mashing, or
sampling (as you said, isn't it?). Thus we have arc corrected michelogram
directly.

If we drop ecat7 header (if we have Interfile head), we can call it sinogram.

By regarding root, I have no much idea on how to use it. Because of poor network
conecting, I can't visit any ftp site in a foreign contry. Unfortunatly, the root
mannules reside on one of them. Maybe, you can help me to get one. :-)

I suggest to use LMF lib when writing root script if possible, they are good at
handling LMF file.

BTW, here is the new patch for basic interfile output in GateSinoToEcat7 with two
bugs fixed.

Regards,

Long

In your mail:
>From: Claude Comtat <comtat at ieee.org>
>Reply-To: 
>To: null99 at mails.tsinghua.edu.cn,
GATE feedback and helpline for Users <gate-users at lphe1pet1.epfl.ch>
>Subject: [Stir-devel] Re: [gate-users] updated proposal and patches
>
>Dear Long,
> 
> thank you very much for your effort to define a joint GATE - STIR 
> proposal. I'll do my best to help you in this job. Indeed, the Gate 
> developer team is more than happy to incorporate new contributions from 
> different users.
> 
> To begin with, a few words about data format/organization in PET. By 
> nature, in "3D PET" (acquisition  without septa or with the septa 
> retracted), the data are actually 4D and not 3D. The four dimensions are:
> 
> 1) radial
> 2) azimuthal
> 3) axial
> 4) polar
> 
> A sinogram is defined by dimensions 1 and 2, and the size of the third 
> dimension (number of axial bins) decreases as the polar angle increases. 
> In addition, because of the typical curvature of the detectors, the 
> radial sampling is not uniform.  Theses facts make that there is no 
> consensus on how to store these 4D data (unlike interfile for 3D data 
> like in SPECT, where the polar angle is null and the radial sampling is 
> uniform). Each manufacturer has its own implementation, highly dependent 
> on the geometry of the scanner. For these reasons, the ECAT7 output 
> could not be implemented as a generic output format for CylindricalPET 
> and a new system had to be defined in order to support that format. I do 
> not know how Interfile supports 4D PET data and ring curvature ??? For 
> ECAT7 data, the non uniformity of the radial sampling is typically 
> corrected during the reconstruction of the image (this also prevents 
> truly generic reconstruction tools).
> 
> The sinogram output is closely related to the ECAT7 format, except for 
> the polar mashing (span) and can not be implemented as it is in the 
> cylindricalPET system. The radial, azimuthal, axial and polar indexing 
> of the sinogram bin is based on the crystal numbering (approximate and 
> non exact rebinning,  like for real ecat systems). For cylindricalPET, I 
> would rather suggest a different approach, where the radial, azimuthal, 
> axial and polar indexing of the sinogram bin is based on the exact 
> radial, azimuthal, axial and polar coordinates of the LOR (exact 
> rebinning). This will make also the reconstruction easier. The exact 
> radial and azimuthal coordinates of the LOR are already calculated in 
> the root output. Once you know the exact four coordinates of the LOR, 
> based on the closest neighbor, you can assign the corresponding sinogram 
> bin (you can let the user choose the sampling). I suggest to start with 
> a root macro rather than a new Gate class (can be done later, when 
> everything is working properly). This root macro will convert the 
> listmode root output into an Interfile  sinogram format. I can help you 
> in this job.
> 
> Best regards,
> 
> Claude
> 
> 
> null99 at mails.tsinghua.edu.cn wrote:
> 
> >Dear all,
> >
> >The JOINT GATE STIR proposal is updated, including typo fix, and adding
roadmap.
> >Most important of all, adding request for help on GATE side implement.
> >
> >Patches including:
> >stir patch
> > 1. newly fixed support for userdefined scanner for ifheader_for_ecat7
> >
> >gate patch
> > 1. introduce macro: B_JOINT_GATESTIR
> > 2. add support for Userdefined_Scanner
> > 3. add Interfile support for GATESinoToECAT7
> >
> >TODOs:
> > STIR:
> >   no plans yet.
> > GATE:
> >   request help on how to adding Interfile support for cylinder system,
> >suggestions and contribution is highly appreciated, esp. those from GATE
> >developer.
> >   
> >Again, I hope all kinds of questions, comments, suggestions, contributions!
Thanks
> >in advance!
> >
> >Regards,
> >
> >Long Zhang
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >gate-users mailing list
> >gate-users at lphe1pet1.epfl.ch
> >http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
> >
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Stir-devel mailing list
> Stir-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stir-devel
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: joint.patch.4.gate.1.0.v0.0.1.gz
Type: application/x-gzip-compressed
Size: 2616 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20040809/3ad57224/attachment.bin>