A question about common geometries defined in utilities (ArbitrarySourceDetectorFixedObject)
Hi, I hope you’re doing well.
Regarding the title, my understanding is that in this type of geometry you can freely define any position to set up the desired geometry. However, I’m not sure whether the rotation angle of the whole system still affects the detector’s u, v vectors.
In the geometry of my instrument, the source and detector both move along a circular path, but the detector itself does not rotate relative to that path—it is fixed in orientation.
After testing this geometry and reviewing the results, it seems that the detector might still be rotating. Could you please provide some clarification or explanation about this behavior?
What do you mean the detector doesn't rotate? You mean that at 90degrees you see the side of the detector and at 180 you see the back?
Or are you describing a standard CT setting?
Sorry for the confusion earlier — my geometry is not the standard CT imaging setup.
I think I shared an image of it in this issue. As you can see there, although the detector center position rotates along the circular trajectory, the detector orientation itself remains fixed and does not rotate with the system.
You are doing laminography. You describe it that way, but the alternative (and easier) descriptor is to think of a static source-detector with a rotating object
This object rotates though a tilted axis, which you can easily define with giving 3 angles pero projection to Tigre (see arbitrary axis of rotation demo).
This indeed makes a detector that always is looking at the source indeed, so you also need to find which rotation to apply (look at the demo of rotation of detector) to make it look at the direction you want.
There is no function in Tigre that will define this geometry for you, as its very non standard. You will need to resolve the geoemtry parameters to feed them into Tigre, unfortunately.
Yes, I completely understand. I’m not expecting TIGRE to compute the geometry parameters for me. In fact, I’ve already calculated the rotations of the source and detector, as well as the detector’s u, v vectors, manually. What I need is simply a way to define these parameters directly in TIGRE so that I can run FDK reconstruction with them.
The difficulty I’m facing is that the rotational angles I provide to the TIGRE geometry for each projection seem to override or alter my detector’s u, v vectors. I believe this is what causes the reconstruction artifact I showed in the image.
For comparison, the Astra Toolbox provides a geometry model called cone_vec, where all the geometry parameters (for each projection) can be passed in a single vector. This allows full control of the geometry per projection without the framework altering detector orientation implicitly.
I’m looking for a similar way in TIGRE — ideally, to define per-projection geometry explicitly without losing control of the detector basis vectors.
No, the values are not overridden, so they just must be something wrong in your calculations/understanding of Tigre geometry. However you don't need "detector u/v vectors" in Tigre (I assume you mean geo.offDetector) to describe this geometry.
Indeed it would be great to have a function in Tigre that can take directional vectors of detector/source/object and convert them to TIGRE geometry, I agree! However this is non trivial to write and it's an open feature request in Tigre already. If you write one it would be a great addition to Tigre.
Thank you for your attention and the time you’ve devoted to this matter. Unfortunately, I haven’t been able to find a clear visual definition of the TIGRE geometry system.
In my work, I mainly use the Core Imaging Library (CIL) for reconstruction, since it supports both Astra and TIGRE backends. CIL also provides helpful visualization tools for geometry definitions. For example, here is a sample visualization of a geometry defined in CIL:
(In this figure, Dx and Dy correspond to what I refer to as the detector’s u, v vectors in my text.)
My main challenge is understanding how TIGRE defines the detector orientation in a 3D coordinate system. For instance, in the above geometry the detector’s orientation vectors are:
Detector_direction_x = np.array([0, 1, 0], dtype=np.float32) Detector_direction_y = np.array([-1, 0, 0], dtype=np.float32)
This approach allows me to explicitly control the orientation of the detector in 3D space and apply the necessary transformations to my system.
Tigre defines the detector center to be perpendicular to the source-origin.
The angles between the normal direction vector and the DSD vector gives you the rotation you need for the detector.
Hello, I saw your post on this issue(https://github.com/CERN/TIGRE/issues/654) and noticed I’m encountering the same problem like you. I looked at the diagram you attached and may have reproduced the same geometry, but my reconstruction result is very poor (please see the attached image). Could you suggest what might be causing this? To briefly describe my geometry: the source is below, the detector is above, the detector is horizontal and does not rotate during the scan, and the whole setup rotates clockwise. I would greatly appreciate any help. Thank you!