spblurring discussions in gate-users mailing list

In about Aug 2005

Christian found that when using

1/ /gate/digitizer/Singles/spblurring/setSpresolution 0.0
2/ /gate/digitizer/Singles/spblurring/setSpresolution 10.0

the distributions (with root or ASCII output) of globalPosX ; globalPosY ; globalPosZ for the above configurations differ: 

	avgX     stdevX  varX   avgY    stdevY	varY	avgZ	stdevZ	varZ
0mm :	242.435	 1.795	 3.223	0.919   9.09	82.659	-0.685	8.305	68.967
10mm:	241.85	 4.9	24.015  0.955	10.222	104.49	-0.685	68.967	8.304

"I guess these values do make sense, but that does not explain why the projections from the interfile output look identical. Is there a bug in the interfile output?  
"

Mikhail A. Shilov from The Johns Hopkins University posted:

First of all I don't get ANY blurring in the interfile projection output. Does anyone knows why?
Second, when I look at the ASCII  gateSingles.dat file I see the correct blurring in the Y direction but absolutely no blurring in the Z direction.

Christian,

I saw your postings on this issue. Did you manage to fix the problem? Does you correction  to the code fix this bug? : 

GateSpblurring.cc:
G4double PzNew = G4RandGauss::shoot(Pz,m_spresolution/2.35);

In response, Christian said:

Dear Mikhail, 

Good to hear that I am not the only one with this problem. Well, I never got  
the spatial blurring in the interfile output to work. I probably would have 
to dig deeper in the source code of GATE to do so. What I ended up doing is 
writing a program to extract the detector "counts" from the  gateSingles.dat 
file. If you wish, I can provide the source code. 

The correction I made to the GateSpblurring.cc fixes a different problem, 
where the spatial blurring only works in the Y dimension. This is more a  
hotfix, I think some more work is needed to make it 100% correct. I am in 
contact with the developer of this file. If you manage to extract the 
"counts" from gateSingles.dat, I would be more than interested in knowing  
your results and if you also observe that the blurring only works in one 
dimension. 

Please let me know if you need any further help. 

Regards, 

Christian

Another post from Christian regarding the spblurring bug... 

Dear Sebastien,

Thanks for the reply and for continuing the discussion. Please 
correct me if I am wrong with my assumption, but aren't those
coordinates in the world coordinate system of the simultaion, or 
does the detector have it's own coordinate system? If it is the 
world coordinate system, than the z-axis should be along the 
axis of rotation, which is actually one coordinate in the projection 
image (ordinate).  

If you take a closer look at the benchmark_projection.c file, there, 
z is also used at the location of an event on the ordinate. x 
and y contributions are variable, because they are being 
rotated around the z axis. In benchmark_projection.c there are  
multiple case where the correct location of the event along the 
(absizza) is computed from x and y depending on the angle of rotation. 
So at 0 and 180 degree, x is the depth of interaction in the crystal, and  
at 90 and 270 degree y is the depth of intersection.

If you look at my original post below, where I simulated a point source 
at the origin of the world coordinate system, the average value of X is 
exactly the distance between the origin of the world coordinate system  
and the detector, and Y and Z show roughly zero as expected. 

So I created projection images, without spblurring, I get a nice round 
projection of my point source through the pinhole, but if I turn on 
spblurring, this projection is distorted, and shows no blurring in the  
z direction, indicating that there is a bug in the spblurring functionality. 
But after applying my patch, this distortion is not present anymore, and
I get a nice Gaussian distribution in all direction. 

 The only mistake I might be making is that there is indeed within Gate a 
separate coordinate system for the crystal, but my results indicate differently. 
If you have time, I would like to send you my files, running the macro only 
takes 10 minutes, and you can see for yourself what I am talking about. I 
just don't want to send tar archives to this mailing list. 

I am looking forward to hearing more from you and I hope I can contribute to 
the development of Gate in some way. 

Best Regards,

Christian

Steven Staelens, a developer of Gate, answered Christian:

Hi Christian, Hi Mikhail,

This Spblurring function was used 3 years ago for the validation of 
SPECT projections using the typical developer macros of that time.  The
detector head was alywas perpendicular to the Z-axis, which is not the
case with your macros.  This clearly highlights the fact that this class 
is obiously not general enough, and apparently no one had discovered
that before.  So thank you for pointing this out to the collaboration.

I will answer your 2 specific questions below.


> If this is correct, shouldn't Pz also be blurred 
> with the Gaussian function? In my tests I simulated the projection of a point
> source through the pinhole and observed blurring only along the abscissa, and
> no blurring along the ordinate. When I change the line to : 
>
>   G4double PzNew = G4RandGauss::shoot(Pz,m_spresolution/2.35);
>
> I also observe blurring along the ordinate in the projection image.

OK, I agree this is a fix for your particular issue. 

>
> Second, to be more accurate, shouldn't be Py first rotated
> (Py = (-1)*sin(theta) * Px + cos(theta) * Py;) before the blurring is applied?
> Then PxNew can be equal to Px? 
>

actually in my current Gate development distribution I no longer use
spatial blurring on the global coordinates but I added three more leaves
to the ROOT tree for local position next to the global positions.  In 
that way, it is easier to implement a blurrer.  This upgrade is not in
the users distribution however but can be implemented extremely easily
in a few lines: f.i in GateRootDefs and in GateSingleDigi.

The last thing you should add is a pointer to the RotationAxis so that 
your blurring class knows which (newly created) local positions to blur,
since I assume you do not always want to blur the DOI.

hope this helps,

best regards,

Steven