[gate-users] updated proposal and patches
Schmidtlein, Ross/Medical Physics
schmidtr at mskcc.org
Thu Aug 12 17:29:00 CEST 2004
Hi Claude,
Here is a copy of the Michelogram building code. I did some thinking
about how to bin crystal and ring numbers to sinograms and have tested
this strategy against your ECAT system and get about 99.9% agreement (A
few odd counts at large r don't match, not sure why). I checked it by
differencing the sinograms. I made one change to this code a few months
back and haven't completely checked it since, but I think it is OK (I
added a few lines so that submodules in Cylindrical PET could be used).
In addition, the phi = 0 location was somewhat arbitrarily chosen and
may result in rotated images depending upon the scanner.
Also, we have been working on compiling root code outside the root
environment. For some root applications (including this) the speed up
is by about a factor of 4. However, that code needs to be cleaned up
before I feel comfortable sending it out.
I hope you find this code useful.
Cheers,
ross
-----Original Message-----
From: gate-users-bounces at lphe1pet1.epfl.ch
[mailto:gate-users-bounces at lphe1pet1.epfl.ch] On Behalf Of Claude Comtat
Sent: Thursday, August 12, 2004 7:41 AM
To: GATE feedback and helpline for Users
Subject: Re: [gate-users] updated proposal and patches
Hi Ross,
yes, please, I'm definitely interested in your root program (this is
what I did for the ecat7 output, to rebin the LOR via the block and
crystal ID's).
The reason I wanted also a "purely geometric" view was for more complex
systems, with gaps (like the HRRT). In that case, I do not know how to
compute easily the crystal-inside-ring ID, in particular if the gap
width is not a integer multiple of the crystal width.
Cheers,
Claude
Schmidtlein, Ross/Medical Physics wrote:
>Hi Claude,
>
>As an alternative to using the coordinates in the crystals you can bin
>the LOR via the rsector, module, submodule, and crystal ID's to compute
>the crystal and ring number pairs. These pairs then can be binned in
>any format. I have a general root program that does this. Is this
>something you are interested in.
>
>Cheers,
>
>ross
>
>-----Original Message-----
>From: gate-users-bounces at lphe1pet1.epfl.ch
>[mailto:gate-users-bounces at lphe1pet1.epfl.ch] On Behalf Of Claude
>Comtat
>Sent: Sunday, August 08, 2004 5:43 PM
>To: null99 at mails.tsinghua.edu.cn; GATE feedback and helpline for Users
>Cc: Stir-devel at lists.sourceforge.net
>Subject: 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
>>
>
>
>_______________________________________________
>gate-users mailing list
>gate-users at lphe1pet1.epfl.ch
>http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
>
>
>
>
> =====================================================================
>
> Please note that this e-mail and any files transmitted with it may
be
> privileged, confidential, and protected from disclosure under
> applicable law. If the reader of this message is not the intended
> recipient, or an employee or agent responsible for delivering this
> message to the intended recipient, you are hereby notified that
any
> reading, dissemination, distribution, copying, or other use of
this
> communication or any of its attachments is strictly prohibited.
If
> you have received this communication in error, please notify the
> sender immediately by replying to this message and deleting this
> message, any attachments, and all copies and backups from your
> computer.
>
>
>_______________________________________________
>gate-users mailing list
>gate-users at lphe1pet1.epfl.ch
>http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
>
_______________________________________________
gate-users mailing list
gate-users at lphe1pet1.epfl.ch
http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C_PET_Sinogram_full.C
Type: application/octet-stream
Size: 10727 bytes
Desc: C_PET_Sinogram_full.C
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20040812/721ef439/attachment.obj>
More information about the Gate-users
mailing list