FAST-Imaging/FAST: a C++ and OpenCL framework for streaming medical image pipelines

The problem FAST targets: medical images that have to move while they are being computed on

Most medical imaging code is written for one shot: load a volume, run an algorithm, write a result. FAST is built for the other case, where frames keep arriving and results have to appear while they do. The README describes pipelines that handle both static and dynamic data without a change to the code, and lists movie files, a webcamera, an Intel RealSense camera, an image sequence and ultrasound scanners such as Clarius as streaming sources. That is the shape of the problem it solves: a single pipeline description that does not have to be rewritten when the input stops being a file.

The audience follows from that. FAST is developed by researchers at the Norwegian University of Science and Technology and SINTEF, and it is aimed at people who write C++ or Python and are comfortable with OpenCL, OpenGL and inference runtimes. A radiologist will not install this. A team building an ultrasound demo, a digital pathology viewer or a real-time segmentation prototype will recognise the problem immediately.

How the data objects stay coherent across CPU, GPU and the render thread

The mechanism the README puts first is data management. A data object in FAST represents the same data on all processors, and the framework keeps it coherent across storage areas so the developer does not write explicit memory transfers. In practice that means you write an algorithm against an image, and FAST decides where the bytes live and when they have to move. This is the part that most directly determines how the rest of the framework feels: a filter chain that would otherwise be a sequence of upload and download calls becomes a sequence of operations on objects.

Rendering is separated from computation by threads, which the README gives as the reason visualizations stay responsive while work is in flight. Supported visualizations include 3D mesh, point, line, image slice and volume rendering, plus 2D image, image slice, segmentation and label rendering, and whole slide image pyramids. The algorithms shipped as parallel OpenCL implementations are marching cubes surface extraction, Gaussian smoothing, non-local means, block matching tracking and seeded region growing. Neural network inference goes through a common interface that accepts ONNX, protobuf, SavedModel, OpenVINO and UFF model formats and can run on TensorFlow, TensorRT, OpenVINO or ONNX Runtime.

Two design consequences are worth naming. First, the abstraction assumes your data fits the object model; an algorithm that wants raw pointers and its own buffer strategy is fighting the framework. Second, the streaming claim is only as good as the source implementations, and the README names specific cameras and scanners rather than a general capture API.

Installing FAST and running a first pipeline

The README does not put install commands in the repository root. It points to per-platform installation pages for Windows, Ubuntu Linux and macOS, and to a separate page for Docker containers, and it says the framework can also be built from source using the build instructions for each operating system. So the first step is choosing between a container, a release binary and a source build, and the repository layout supports the last of those: there is a top-level CMakeLists.txt, a cmake directory and a source directory.

The Python path is the shortest route to something running. The README links Python tutorials and Python examples, and the pip download badge on the project page indicates a Python distribution exists. Because the README does not print the package name or an import line, check the Python tutorial page for the exact import before assuming one.

Once FAST is available, the tutorials are the entry point rather than a quickstart snippet in the README. The C++ tutorials and the Python tutorials are listed as the way to start using the framework, and the examples pages collect runnable programs for both languages, including a whole slide image loader, a rotating 3D GIF example and a real-time line plotter. Expect the first working program to come from adapting one of those examples to your own data rather than from a single command.

For a reproducible environment, the container route is the one the README separates out. It exists because the dependency set is wide: OpenCL, OpenGL and one or more of TensorRT, OpenVINO, TensorFlow and ONNX Runtime, plus the data format libraries behind DICOM, NIFTI, MHD, HDF5, VTK polydata and whole slide images.

Where FAST is the wrong tool

The framework's own scope statement is the clearest limitation. FAST is about high-performance processing, inference and visualization on multi-core CPUs and GPUs. If your workload is a batch job that reads a folder of NIFTI volumes, applies one ONNX model and writes masks, the streaming layer, the coherence machinery and the render thread are all overhead with no payoff. A plain inference script plus a file reader will be easier to debug and easier to deploy.

The dependency surface is the second constraint. A FAST binary links against third-party libraries under MIT, Apache 2.0 and LGPL among others, and the README directs readers to the licences folder in the release for the details. That matters for any product that ships a FAST-based binary, and it is a different question from the BSD-2-Clause terms on the source itself.

The third is documentation shape. The repository README is a map, not a manual: install steps, tutorials, examples and API details live on the documentation site, and the README does not document rollback, version pinning or a compatibility matrix between releases and backend versions. If your team needs an offline, self-contained reference, budget time for reading the site and the examples rather than the repository.

How FAST differs from ITK and from plain inference scripts

ITK is the closest comparison in medical imaging and the difference is architectural. ITK is a C++ toolkit of algorithms and file formats with a pipeline model that is typically pull-based and CPU-oriented, and it has no built-in rendering or inference runtime abstraction. FAST puts the GPU and the render loop inside the pipeline: OpenCL kernels for the algorithms it ships, a common interface over four inference backends, and a separate render thread. If your problem is algorithmic breadth, ITK has the larger catalogue. If your problem is getting frames through a GPU and onto a screen without writing the plumbing, that is the gap FAST occupies.

The other comparison is a hand-written script using ONNX Runtime plus a viewer. That approach is smaller and has no framework to learn, and for offline work it is often the right answer. It stops being the right answer when the same code has to serve a live camera or an ultrasound stream and a rendered view at the same time, because then you are rebuilding the streaming and coherence layers yourself.

Release cadence, licence and the cost of staying current

The last push to the default branch was on 2026-09-08, and the most recent tagged releases are v4.17.1 on 2026-03-06, v4.17.0 on 2026-02-17 and v4.16.1 on 2026-02-09. The pattern is a steady stream of 4.17.x tags rather than long gaps, and the repository is not archived.

Upgrade cost is dominated by the inference backends, not by FAST itself. TensorRT, OpenVINO, TensorFlow and ONNX Runtime each version their own APIs and their own GPU requirements, so a FAST upgrade can pull in a backend upgrade and a driver requirement at the same time. The README does not publish a support matrix tying FAST releases to backend versions, so the practical check before upgrading is whether the backends you actually use are still supported by the release you are moving to.

On licensing, the source is BSD 2-clause, which is permissive and imposes no copyleft on your own code. The binaries are a different matter: they use and link third-party libraries under MIT, Apache 2.0, LGPL and others, and the README points to the licences folder in the release. Read that folder before distributing a binary. This is a description of what the project states, not legal advice.

Editorial conclusion

Adopt FAST if you are building a C++ or Python pipeline that has to move medical images through OpenCL kernels, neural network inference and on-screen rendering at the same time, and you are willing to build from source or use a container. Do not adopt it if you only need to read DICOM files and run one segmentation model offline; the framework's streaming and visualization layers are weight you would carry for nothing. Before committing, verify that your target hardware is covered by the OpenCL and inference backends you intend to use, and read the licences folder shipped with the binaries, because the BSD-2-Clause terms cover the FAST source and not the third-party libraries the binaries link against.

Frequently asked questions

Official sources

1. FAST-Imaging/FAST on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases