# TIGRE: a GPU toolbox for 3D tomographic reconstruction

> TIGRE is a CERN and University of Bath toolbox for iterative 3D CT reconstruction that keeps MATLAB and Python at the surface and CUDA underneath, with algorithms from filtered backprojection through SART, Krylov methods and variational schemes. The documentation is thin by design, so the demo folders are the tutorial, and the licence requires you to cite the authors.

**CERN/TIGRE** — TIGRE: Tomographic Iterative GPU-based Reconstruction Toolbox

- Repository: https://github.com/CERN/TIGRE
- Stars: 814 · Forks: 267
- Language: MATLAB
- License: BSD-3-Clause
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/cern-tigre

## What TIGRE is and where it sits

TIGRE stands for Tomographic Iterative GPU-based Reconstruction Toolbox, and the README describes it as an open-source toolbox for fast and accurate 3D tomographic reconstruction for any geometry. Its focus is on iterative algorithms for improved image quality, all optimised to run on GPUs including multi-GPU systems for improved speed.

The architectural claim in the README is that TIGRE combines the higher level abstraction of MATLAB or Python with the performance of CUDA at a lower level, so that it is both fast and easy to use. That is the design in one sentence: you write MATLAB or Python, and the projection and backprojection operations that dominate the run time are compiled CUDA kernels underneath.

The provenance matters for expectations. The README says the creation of TIGRE was supported by the University of Bath and CERN, and it is hosted under the CERN organisation. The topic tags name CUDA, GPUs, MATLAB, Python, image reconstruction, tomography and X-ray, and the primary language field in the repository metadata says MATLAB.

The purpose stated in the README is a wide range of easy-to-use algorithms for the tomographic community off the shelf, with a stronger bridge between algorithm developers and imaging researchers and clinicians, and it explicitly encourages contributions from both sides. That is a research tool with an academic user base, not a commercial product, and the documentation and support channels reflect that.

## The algorithm families on offer

The feature list is the real content of this project, and it is worth reading as a menu rather than a list of bullet points.

Filtered backprojection is there, with FBP and FDK and variations including different filters and Parker weights, which covers the cone beam case.

The gradient based family is the largest. SART, OS-SART, SIRT, ASD-POCS and its OS and B variants including B-ASD-POCS-beta, PCSD, AwPCSD and Aw-ASD-POCS. The README notes that these come with multiple tuning parameters, naming Nesterov acceleration, initialisation and parameter reduction. That distinction is not cosmetic, because the accelerated and non-accelerated variants of the same iterative scheme can behave differently on real data.

The Krylov subspace family includes CGLS, LSQR, hybrid LSQR, LSMR, IRN-TV-CGLS, hybrid-fLSQR-TV and AB/BA-GMRES.

Statistical reconstruction is present through MLEM, and the variational methods are FISTA and SART-TV.

Around those there is TV denoising for 3D images, basic image loading functionality, a variety of plotting functions and image quality metrics. Those last three are the parts that decide whether you can use the output, because a reconstruction you cannot measure or visualise properly is not a result.

The README also notes that TIGRE remains under development with features still being added, motion compensation being the example given, and invites requests for specific applications.

## Geometry flexibility and the scanner data loaders

The geometry support is a differentiator that the README states in a way that matters more than it first appears.

TIGRE supports cone beam, parallel beam, digital tomosynthesis, C-arm CT and any other geometry. The important detail is the last clause of that sentence: geometric parameters are defined per projection, not per scan.

That is a real architectural commitment. A cone beam C-arm scanner and a fixed gantry have different geometry, and if a toolbox hard-codes one geometry per acquisition, the other case needs a separate code path. Defining the parameters per projection means the geometry is a property of the data rather than of the scan, which is what makes multi-geometry and non-standard setups tractable. For a clinical or industrial user with an unusual scanner, that is the feature that decides whether the toolbox is usable at all.

The other end of the toolbox is the data loaders. The README lists Nikon, Varian and Phillips DICOM scanner data loaders, with the vendor spellings as the README writes them. So the path from a real scanner's projection data to a reconstructed volume is part of the package rather than something each user writes.

Together, the loaders and the per-projection geometry cover both ends of the pipeline, which is the reason the README frames the project as a bridge between algorithm developers and imaging practitioners rather than as a reconstruction library alone.

## Installing for Python and MATLAB, and the build details

Both MATLAB and Python builds are described as fully supported, with separate installation pages in the repository under Frontispiece. There is also a page on tuning TIGRE for a machine, which the README marks as advanced and not required to run TIGRE, and warns that it changes the source code, so only do it if performance is critical.

The Python package metadata gives the dependency set: matplotlib, numpy at 1.20.0 or newer, scipy, h5py and tqdm. The version is 3.1.3 and the Python requirement is 3.10 or newer with an upper bound below 3.15.

The build system requires setuptools, wheel, Cython and numpy, and the package data configuration includes the pyx, pxd and cpp files of the utilities.cuda_interface subpackage, which is the Cython layer sitting on top of the CUDA kernels.

The setup.py shows the flag that governs one of the more interesting runtime choices.

```python
define_macros=[("IS_FOR_PYTIGRE", None)]
no_pinned=False
if len(sys.argv)>2:
    if "--no_pinned_memory" in sys.argv[2:] :
        no_pinned=True
        sys.argv.pop(sys.argv.index("--no_pinned_memory"))

if no_pinned:
    define_macros.append(("NO_PINNED_MEMORY",None))
```

Pinned memory is the standard trick for letting the GPU read host buffers directly instead of copying them, and it is faster. Turning it off is exactly the option you want on a system where pinned allocation fails or behaves badly, and having it as a build flag rather than a runtime setting means you keep both binaries.

The setup.py also contains a get_cuda_version function that reads version.txt or falls back to parsing nvcc --version, and a get_cuda_cc function that calls nvcc --list-gpu-arch to enumerate the compute capabilities to compile for.

## The demos are the documentation

This is the unusual part of TIGRE and the first thing a user should understand.

The README states plainly that there is no documentation page for TIGRE other than the function documentation, and that all features are described and demonstrated with working code in the demos. The demos also serve as a tutorial of each feature. The recommendation is to explore the first four demos for the basic TIGRE functionality and to look at the following ones for more advanced geometry or reconstruction functions.

The demos live in a Demos folder per language, MATLAB/ and Python/demos/ in the repository. So the learning path is: install, open the demo folder, run the first four, then pick the demo for the geometry or algorithm you need.

That approach has an obvious strength and an obvious cost. The strength is that everything in the demos runs, so nothing in them is stale pseudocode, and for a numerical toolbox that matters a great deal. The cost is that there is no place to look up how a parameter behaves, and a user who wants to know what a regularisation weight does has to read the function documentation and then experiment.

The rest of the documentation is thin as well and lives in the same Frontispiece directory: an FAQ page, a gallery of images across CT modalities, and a further reading page. The README links an issue template and a discussions thread, and a Slack group for development questions, with an email to the authors as the way to get an invitation.

A readthedocs badge is present in the README, so the function documentation is published there, and the project site is linked as the most up to date article about TIGRE.

## Where TIGRE is the wrong tool

The first limitation is the GPU requirement. The whole design is built around executing the projection and backprojection operators on CUDA capable hardware, so a machine without an NVIDIA GPU and a working CUDA toolchain is out of scope. The setup.py confirms this by parsing the CUDA version and enumerating GPU architectures at build time. A workstation with an integrated GPU is not a target.

The second is the version range on Python, from 3.10 to below 3.15. That is a deliberate bound, and it means a site on an older Python has to work around it or wait.

The third is the documentation situation, which we have already described but is worth stating as a limitation rather than a fact. There is no manual, no tutorial prose and no parameter reference beyond the per-function documentation. For a research tool whose users are often graduate students and clinicians, that is a real barrier, and the project compensates with the demos and the community rather than with writing.

The fourth is that this is an algorithm library, not a pipeline. The loaders read DICOM projection data from three scanner vendors, and the reconstruction is iterative, but there is no acquisition, no correction stage, no calibration workflow and no detector model. A user with a clinical workflow needs the rest of that from elsewhere.

The fifth is the compilation requirement for the Python build, since Cython and CUDA are part of the build requirements, so a pip install is not a pure-Python operation and the build can fail on a machine that has the libraries but not the toolchain.

## TIGRE compared with ASTRA, FBP and the vendor reconstruction tools

TIGRE is often mentioned alongside other GPU reconstruction toolkits in the same domain, but this article sticks to what the repository itself documents. Within TIGRE you get a set of complete, ready to use reconstruction algorithms, which is the one to reach for when you want a working reconstruction of your data this afternoon rather than a toolkit for composing operators yourself.

The second comparison is with a plain filtered backprojection implementation. TIGRE includes FBP and FDK, so for well-conditioned data and a fast result, the analytic method is available in the same framework, and the iterative algorithms are there for when the data is noisy, the geometry is hard, or the object is not uniformly attenuating. Having both in one toolbox means the comparison between them is a matter of running two functions rather than of two codebases.

The third comparison is with the reconstruction software that comes with a scanner. Vendor packages are tuned for their own hardware, they are covered by the service contract, and they are closed. TIGRE is the opposite on all three counts, and it is the reason a research group would use it: the same code runs on a cone beam C-arm dataset from a physics lab and on a clinical scanner dataset, and the algorithms are the published ones, so the result is reproducible by anyone.

That last property is what makes TIGRE valuable in a clinical research context, where a reconstruction that only the vendor's software can produce is a result nobody else can check.

## Licence, citation and the state of the project

The licence field on the repository records BSD-3-Clause, with LICENSE.txt at the root. The README says TIGRE is released under the BSD License, meaning you can use and modify the software freely, and that the creation was supported by the University of Bath and CERN.

The BSD licence is permissive, and TIGRE is free to download and distribute, with the README putting it plainly: use it, modify it, add to it, share it.

The obligation is citation, and the README states it as a requirement rather than a request. You must cite the original authors. Two papers are named, and the choice between them depends on your data. The first is TIGRE: A MATLAB-GPU toolbox for CBCT image reconstruction by Biguri, Dosanjh, Hancock and Soleimani in Biomedical Physics and Engineering Express. The second is Arbitrarily large iterative tomographic reconstruction on multiple GPUs using the TIGRE toolbox in the Journal of Parallel and Distributed Computing, and the README says to cite that one especially if you use images bigger than 512 cubed or multiple GPUs.

There is also a third: the README says the most up to date article is the TIGRE v3 release paper, TIGRE v3: Efficient and easy to use iterative computed tomographic reconstruction toolbox for real datasets, and that it documents the most novel features well. So the citation guidance is three-layered, and the v3 paper is the right one to reference for the current feature set.

The project is not archived and the last push was on 2026-09-29, so it is being worked on. The recent releases are v3.1.3 from 2026-03-06, v3.1.2 from 2026-01-30 and v3.1.1 from 2026-01-29, a tight patch sequence, and there is a changelog.md in the repository alongside a contributing.md, a CODE_OF_CONDUCT.md and an issue template.

## Conclusion

TIGRE suits an imaging researcher or clinician who needs a reconstruction algorithm that runs on a workstation GPU without writing CUDA, and who is prepared to learn the toolbox from its demos rather than from a manual. It is the wrong tool for anyone without a CUDA capable GPU, since the whole design is built around GPU execution of the projection and backprojection operators. Before using it, read the FAQ and the installation page for your language, and note the citation requirement, which the licence makes mandatory: if you use TIGRE you must reference the authors, and the v3 release paper is the one to cite for the current feature set.

## FAQ

### What is TIGRE?

It is an open-source toolbox for fast and accurate 3D tomographic reconstruction for any geometry, from CERN and the University of Bath, providing MATLAB and Python libraries over CUDA so that iterative reconstruction algorithms run on GPUs including multi-GPU systems.

### Which reconstruction algorithms does TIGRE provide?

Filtered backprojection variants including FBP, FDK and Parker weights, gradient based methods such as SART, OS-SART, SIRT and the ASD-POCS family, Krylov subspace methods such as CGLS, LSQR and LSMR, statistical reconstruction with MLEM, and variational methods such as FISTA and SART-TV.

### How do I learn to use TIGRE?

The README says there is no documentation page for TIGRE other than the function documentation, and that all features are described and demonstrated with working code in the Demos folder for each language. It recommends exploring the first four demos for basic functionality and the following ones for advanced geometry or reconstruction functions.

### Which CT geometries does TIGRE support?

Cone beam, parallel beam, digital tomosynthesis, C-arm CT and any other geometry, with the geometric parameters defined per projection rather than per scan. The README also lists DICOM data loaders for Nikon, Varian and Phillips scanners.

### What are the Python requirements for TIGRE?

Python 3.10 or newer with an upper bound below 3.15, and the dependencies matplotlib, numpy 1.20.0 or newer, scipy, h5py and tqdm. The build itself requires setuptools, wheel, Cython and numpy because the CUDA layer is reached through Cython.

### What licence is TIGRE released under and what does it require?

BSD-3-Clause, with LICENSE.txt in the repository, and you can use, modify and redistribute it freely. The README makes citation mandatory: if you use TIGRE you must cite the original authors, and the v3 release paper is the one documenting the current feature set.

## Sources

- [CERN/TIGRE on GitHub](https://github.com/CERN/TIGRE)
- [Issues](https://github.com/CERN/TIGRE/issues)
- [License: BSD-3-Clause](https://github.com/CERN/TIGRE/blob/master/LICENSE)
- [README](https://github.com/CERN/TIGRE/blob/master/README.md)
- [Releases](https://github.com/CERN/TIGRE/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cern-tigre