Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distance Driven algorithm with large tilt angles #13

Open
melikturker opened this issue Aug 6, 2024 · 4 comments
Open

Distance Driven algorithm with large tilt angles #13

melikturker opened this issue Aug 6, 2024 · 4 comments

Comments

@melikturker
Copy link

I am working with projection algorithms and encountering issues with the Distance Driven (DD) implementation in this toolbox. The DD implementation iterates the indexes of both detector and voxel boundaries, which are mapped onto a common plane, in a regular order. However, if the source or detector is tilted at large angles, the mapped boundaries of both detector and voxels tend to become irregular. This irregularity can cause shifts in the indexes of the corresponding voxel and detector boundaries during the calculation of overlapping areas.

For example, if the "shadow" of the image slice is trapezoidal due to the tilted source and detector, the detector indices can shift downward in rows while the voxel indices count right in columns. This can lead to incorrect index matching between the detector and the image slice. Also, the irregular shapes of intersecting areas begin to distort the rectangular intersection assumption with large tilt angles. Additionally, if the detector is tilted, not only is the image slice affected, but the detector cell boundaries also become trapezoidal on the common plane. I believe this is a critical issue for both the DD and branchless DD algorithms.

Given these observations, can we say that this algorithm was designed only for stable detectors and narrow tilt angles? If so, does this mean that the DD algorithm cannot be effectively used in tomographic imaging? I am trying to determine whether this problem is due to the way the DD algorithm is implemented, or if it is inherent to the theory of DD algorithm itself. Finally, are there any other implementations or methods that address and solve these problems?

Thank you for your attention to this matter.

@rodrigovimieiro
Copy link
Member

we say that this algorithm was designed only for stable detectors and narrow tilt angles?

DD was designed for CT geometries, where there are no many distortions since the detector rotates with the tube.

does this mean that the DD algorithm cannot be effectively used in tomographic imaging?

It can be used for tomographic imaging but I am not sure about your specific geometry. DD works fine for normal CT geometries.

I am trying to determine whether this problem is due to the way the DD algorithm is implemented, or if it is inherent to the theory of the DD algorithm itself.

There is a known bug in my DD implementation (for 2D). I don't think it is related to what you have. See the issue here. Jeff Fessler has a new implementation that you can use.

Also, feel free to modify the codes and make a pull request if you correct the problems (if they really exist).

@melikturker
Copy link
Author

melikturker commented Aug 6, 2024

Sorry, I forgot to add that I am talking about cone beam geometry, but i think the problem still exists in parallel beam.

Even if the detector and source rotate isocentrically like in CT, the mapped boundaries of a rectangular image slice and detector cells become trapezoidal. This effect is maximized when the tilt angles are 45 degrees since for higher angles we can swap the common plane. This makes the intercepting boundaries of detector cells and voxels irregular. However, when I see the implementation, the intersection area is calculated with x_overlap * y_overlap. If the intersection is not rectangular, this calculation does not work. Also, the index matching algorithm becomes too complicated if we try to handle the irregular extension of the mapped boundaries on common plane because indices cannot be incremented one by one in regular order. Am I wrong?

@rodrigovimieiro
Copy link
Member

I do not really remember the implementation details of DD. I have not implemented for 3D cone-beam geometry, only for half-cone beam (DBT).

I would think it works fine for common CT geometry since this is a very well-known method.

Sorry, I cannot help with those details since I haven't seen them for a while. If I were you, I would implement your geometry in Julia, in Jeff's toolbox, and probably ask those questions there. I have to say that they are more capable of answering those details.

@melikturker
Copy link
Author

Thank you very much :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants