[Gate-users] FW: GATE/STIR Ecat7 bed motion

[Kris Thielemans]

Dear John

> Kris,
> Thank you for your response it gave me much to think about.
> 
> I believe you are informing me that STIR is limited to reconstructing a
single
> frame of an ECAT7 sinogram, and that if multiple reconstructions are to be
> joined then joining them has to be done with care.
>

Yes

 
> I have been working hard to avoid work. Here is my suggestion - but there
is
> still something I haven't resolved.
> 
> i) In GATE, extend the geometry to have four times the current number of
> crystal rings. i.e 128 rings.
> That will be large enough to cover the torso that I require, of just under
half a
> metre, with enough spare to throw away the top and bottom of the final
> image.
> That will mean no joining.
>

Problematic, unless in 2D. see below

 
> ii) choose small time-slices so that the job-splitter can run several long
> acquisitions at once. We have a server with 128Gb of main memory.
> Will the summation of sinograms will be the simple sort - summing all but
the
> headers?
> That will means that GATE will take care of the decaying count rate.
>

The decay rate stuff is only important want you want to join multiple bed
positions where you move the bed etc in GATE (i.e. they are acquired at
later time points). If you just simulate different bed positions
independently, then you can set it up that they all start at the same
"injected activity"). (Of course, figuring out the decay is not that hard in
any case)

I have no idea about time-slices and job-splitters in GATE. Sorry.

 
> iii) The item that I have been unable to resolve is what the sinogram
shape
> will be.
> Currently with 32 rings I believe there are 32*32 entries. If that means
this
> proposal would need 128*128 that seems rather large but surely only
> 128*maxringdiff are required?
> 

Yes, that's the problem. Even if you impose a maxringdiff of 31, your
scanner won't resemble anything existing. For example, your sensitivity will
hardly vary at all over the whole ranges (except in the 31 end slices at
each end). This doesn't look at all like what you'd get from a 32 ring
scanner where you're shifting bed positions.

As I said, you could/should have overlapping bed positions such that the
axial sensitivity does remain approx. constant. I guess your scanner with a
maxringg diff of 31 would have data somewhat similar to that case (although
still different, for example, your scanner would measure coincidences
between ring 2 and 33, which would never have been measured with overlapping
bed positions, unless your overlap is equal to 31 rings, which nobody does).
In any case scatter from the scanner etc would be different (that might not
be so important for your application).

A work-around for this would be to simulate the whole thing as you suggest,
but then set sinograms to zero (in both the data and the normalisation file)
that would never have been measured. This starts to be more complicated than
simply merging the images though...

> My Questions are, Do you think this could be a solution? Would the
existing
> ECAT 7 facilities in either GATE or STIR break if the size of the
sinograms
> increased by a factor of 16?

STIR should be fine as STIR reads sinograms bit by bit. The projection
matrix will get large but as STIR uses symmetries, it won't have to store a
larger matrix (I think) then for the 32 ring case.

> If so, or if the STIR geometry would have to be tweaked,  do you know
> whether it could be achieved with feasible effort by someone new to
> GATE/STIR?

So, for the above, I think STIR would be ok, but I don't think it'll be a
very realistic simulation.
> 
> If you think it might work perhaps you would point me in the direction of
the
> STIR source that handles geometry of ecat scanners.
> 
There's nothing specific about ECAT scanners in STIR. Currently all scanners
are assumed to be cylindrical. (ECAT handling is only in the file format).

I'm wondering a bit about your application though. GATE is intended to
provide quite realistic simulations. You don't seem to be too worried about
that. If you don't, an analytic simulator might be easier and save you tons
of time. ASIM (from Univ Wash) is designed to handle multiple bed positions.
They do use STIR for recons, but am not so sure how they handle the
multi-bed part of the recon. But this is the wrong mailing list for that I
guess:-)

Kris

> From: Kris Thielemans []
> Sent: 22 February 2012 21:38
> To: Jones JH Mr (PG/R - Electronic Eng); gate-
> users at lists.opengatecollaboration.org
> Cc: s.users
> Subject: RE: [Gate-users] FW: GATE/STIR Ecat7 bed motion
> 
> Hi John
> 
> > I am using GATE 6.1.98524 and have no STIR installation yet.
> >
> > I am planning how to simulate bed motion because the phantom in use is
> > several times the dimension of the crystal ring.
> > GATE  documentation/code suggest that there are 4 dimensions in the data
> > set : FrameID, GateID, DataID and BedID but only FrameID and DataID are
> set
> > by Gate.
> > STIR documentation suggests it handles all four fields.
> >
> 
> STIR doc suggests that it can read the ECAT7 frame,gate,date,bed fields
and
> corresponding sinograms, but that doesn't mean that it'll handle multiple
> bed positions gracefully :-;
> 
> Of course, if you have overlapping bed positions (and you should in 3D),
> theoretically the best way to do this is to reconstruct a single image
from
> all the data, but that'd require major work.
> 
> At present, STIR can really only reconstruct a single frame (aside from
the
> dynamic stuff, but that's not what you're interested in). So, you'd
normally
> have to reconstruct each bed position, and then merge them somewhat
> intelligently. Simple averaging of the corresponding slices is your first
> bet, but ideally you would take the varying sensitivity into account to
> downweight the noisy slices. (That'd automatically make the transition
> between the bed positions more smooth). And of course, then there's
> radioactive decay you have to take into account.
> 
> So, not so easy unfortunately...
> 
> There was a discussion on this a while ago on the STIR list, but I'm not
> sure if anyone actually implemented something, and/or if they'd be willing
> to share. Therefore, I've cross-posted this to the STIR list as well.
> 
> > From what I have read, there is nothing specifically built into GATE for
> bed
> > motion and the only way I can find/think of doing this is to use, from
> GATE
> > documentation,  /gate/name_volume/moves/insert translation and
> > /gate/name_volume/translation/setSpeed and also to arrange the time
> > frames to include a period of non capture between each counting period.
> > Then use STIR utilities to set the file headers for STIR.
> >
> 
> STIR cannot update ECAT7 file headers out-of-the-box (i.e. you'd need to
> write some code), but you probably don't care as STIR will later on ignore
> that information anyway :-(
> 
> 
> > Main Question : Do you feel this a sensible and feasible way to proceed,
> > please?
> >
> 
> As far as the GATE sim goes, it sounds good to me (but I haven't used
GATE)
> 
> > Would simply cutting the phantom into crystal ring sized pieces and
> treating
> > them as independent until reassembly after STIR be simpler and as
> effective,
> > or would the joins show?
> >
> 
> 
> The main difference here seems to be that the original approach would
> handle
> out-of-FOV scatter, randoms etc. Aside from that, the mechanics to get it
to
> work via STIR will be essentially the same.
> 
> Hope this helps (but not enough, I know!)
> 
> Kris
>