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

[Kris Thielemans]

> 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...

> 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.

> 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.

> 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.

> 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
:-/



Thanks!

Kris