TIGRE: Tomographic Iterative GPU-based Reconstruction Toolbox
TIGRE is a GPU accelerated software for big scale 3D tomographic reconstruction, being capable of reconstructing geometries such as Cone Beam Computed Tomography and Parallel Beam Computed Tomography.
TIGRE additionally includes a big set of iterative methods for image reconstruction, methods that can achieve better images with less projections. The algorithms included are:
-FDK (inverse radon)
-SART, OS-SART, SIRT (Gradient descend-based)
-CGLS (Krylov subspace based)
-ADS-POCS, OSC-POCS, B-ADS-POCS-β, SART-TV (Total variation regularization)
-MLEM (Statistical inversion)
TIGRE is released by University of Bath and CERN under a modified BSD license, making it available for everyone to use and modify, and the authors do encourage people to contribute to the code bug fixes, new methods or anything that can help it be better!
Visit TIGRE's Github page for more information.
Thanks for sharing awesome code! Anynway, I can not install your program. I have 2 compilers(MinG264, Visual studio 2015), and I succeeded "mex -set up" in Matlab2018b. However, when running "Compile.m", the error masage pops up("mex_ COUDL NOT FIND COMPILER" in line 47(TIGRE-1.4)). I use CUDA9.2 following the explaination of "mex_CUDA_win64_MVS2015.xml". But the graphic card is old(Geforce GT 220). I hope to use TIGRE!!
Hi Shih-Chin Jin
There is no bug, .exp files are not needed to run or compile the code. MATLAB mex compiler throws a warning, but the code still compiles and runs, as you can test it yourself. you can indeed continue.
The code bug still find that
cannot find CERN-TIGRE-1b65bd9\MATLAB\Mex_files\win64\tvDenoise.exp
and I can not continue.
As we all known,FDK has density attenuation artifact,But I can not find this phenomenon in you FDK result. Can you tell me why?
Please contact me (see github for email) and let's talk about it! Any improvement is good, it's fantastic that you have found possible speedups. We can discuss this by email better and add fixes to the main code!
I was just looking at your voxel_backprojection.cu source (trying to learn CUDA, so please bear with me...) and it looks like you introduced the computeDeltasCube() function to pre-compute relative unit directional increments due to rotation to avoid any calls to sin() or cos() in your kernel (kernelPixelBackprojectionFDK()). However, I noticed that you still have calls to sin() and cos() in the kernel when computing the weight near the end of the kernel code. I tried to pre-compute both sin(geo.alpha) and cos(geo.alpha) before the call to the kernel and to pass them as kernel parameters and that speeded up the FDK code by about 7% on my PC. Actually, pre-computing sin and cos before the kernel call may make the computeDeltasCube() function superfluous. You have even more sin() and cos() calls in your other (non-FDK) versions of kernelPixelBackprojection() in voxel_backprojection2.cu, so that kernel could also benefit from pre-computing these values (if you care about some minor speedups, that is).
Loved the ease of installation and the general design logic of the package. Thank you!
You can choose between 2 different projectors:
-Ray-Voxel intersection with Siddons (Jacobs) algorith
-Interpolation based projection, using GPU texure memory, sampling each delta_L and interpolating the value trilinearly.
This last one is generally not used in X-ray tomography due to the CPU computational limitation, but it is really fast in GPUs and give a way more accurate description of the projector than any other. There is a demo (d12) that specifically shows this in the toolbox.
For further questions, do not hesitate to contact us at email@example.com
What kind of projector are you using in your reconstructor? Distance Driven or Ray Driven or something different?