[gate-users] patch for STIR for recon Gate output

[null99 at mails.tsinghua.edu.cn]

Sure, Kris, call me Long, please, like brothers. :-)


In your mail:
>From: "Kris Thielemans" <kris.thielemans at csc.mrc.ac.uk>
>Reply-To: GATE feedback and helpline for Users <gate-users at lphe1pet1.epfl.ch>
>To: <null99 at mails.tsinghua.edu.cn>
>Subject: RE: [gate-users] patch for STIR for recon Gate output
>
>> Dear Thielemans,
> >
> call me Kris :-)
> (but I'm not so sure if I should call you Long or Zhang...)
> 
> > Thank you very much!
> >
> > I am sorry, because of incapable of connecting your STIR home
> > page again, I can't
> > communication with STIR developers.
> >
> 
> sigh. web-sites. it's out of my control unfortunately.
> the http://stir.sourceforge.net site does work right now.
> of course, the mailing list is independent of the website.
> 
> 
> > My intention is to joint these two packages as a PET (NO SPECT
> > YET) simulator and
> > verifier, meanwihle, I can gain experiences through this process.
> >
> > About the Userdefined_Scanner. Add the Userdefined_Scanner is for
> > enable STIR to
> > verify user defined, non-exsited scanner. So I mentioned "avoid
> > conflicting" in
> > the document. You must know that if without this const, STIR
> > can't handle data
> > from an abitrary scanner. It can't be called a bug, since they
> > are for different
> > purpose.
> >
> > The term Unknown_Scanner, in my understanding, it is used for
> > auto dection. While
> > the Unserdefined_Scanner will cause no auto detection, since this
> > term tells the
> > STIR that this scanner is an non-existed. Although the same result can be
> > achieved, but they are totally different concepts.
> >
> 
> sorry. I'm still a bit confused here.
> what do you mean with 'auto-detection'? STIR tries to detect the scanner
> from the (interfile, ECAT6 or ECAT7) header. If it doesn't understand it, it
> will return Unknown_scanner.
> 
> The only difference with Userdefined_Scanner then is that you probably avoid
> a warning message.
> 
> If that's true, I'm not inclined to include the patch...

In my understanding, an "Unknown" original system in the interfile will cause STIR
to guess what kind of scanner it belongs to through its detectors/ring. This is
what I mean  "auto-detection". Actually, the Unknown_Scanner will be replaced with
ECAT 962 later. What's more, sometime, a user-defined system may has the same
detectors/ring as a known scanner. these may cause "dramtic output" as the warning
message of STIR, and correctness will not be assured.

> 
> > About the three varible. Thus, it is reasonable to have those
> > three varibles asked
> > from user, whether they are ignored or required by other process.
> > You know, in the
> > constructor Scanner(Userdefined_Scanner), they all are
> > initialized to zero, and
> > this is not the fact. I am considering to move them into the para
> > file now.
> >
> 
> that might be a good idea. there are other scanner parameters that we
> could/should add. These then should all be added to the interfile 4.0
> proposal of course.
> 

That's great! But now, the scanner parameter seems no propriate way to add. At
least neither of my proposal.

> > About the bug fix. The bug means that in the .par file, a gate
> > produced ecat7 file
> > can't be read, just as Mr. Srinivasan and I (maybe others) met.
> > It is called a bug
> > because it can't recognize this ecat7 format. And I guess it is
> > because the field
> > file_type in the ecat7 head is zero. Maybe I am wrong. Sorry.
> >
> 
> if the file_type in the ECAT7 header is 0, it's a GATE bug.
> 

I am sorry, I am guessing here, I don't know what's the exact reason. I will check
it.

> > About the ifheader_for_ecat. To make it generates correct
> > Interfile from the GATE
> > outputed ECAT7 file.
> >
> 
> question is again what needs to be fixed. if there's a mistake in STIR,
> we'll fix it!
> 
> > About lmf. As mentioned before, my intention is to make STIR a
> > verifier instead of
> > only a restorer. So, the support to lmf become the most important
> > thing. You know,
> > the most important system, cylinder system in GATE suports lmf
> > instead of ecat.
> >
> 
> sure. Maybe one of the other people wants to comment on their progress. I
> can poll them directly as well (but not this week). I could also send you
> the relevant files if you want.
> 

Great, send please. :-) I have read the corresponding code in current release, and
found that the lmf data can be converted to sets of projection. Am I right?

> > About patches. It's my pleasure to contribute to STIR project,
> > and I will make a
> > new patch as you required. The patches in this way do convinient
> > my codeing,
> > however, not the formal way.
> 
> great. I would suggest that you first discuss patches on the mailing list
> (stir-devel for STIR patches) before doing any coding. I'm bound to disagree
> :-/
> 
> 

Sorry, I do not mean to do that. I also want to talk with STIR developers, but
just can't.

> 
> Thanks!
> 
> Kris
> 
> 
> _______________________________________________
> gate-users mailing list
> gate-users at lphe1pet1.epfl.ch
> http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
>