Open Source Optical Coherence Tomography Software

Optical coherence tomography (OCT) is a non-invasive imaging technique that is often described as the optical equivalent to ultrasound imaging. The basic building block of OCT acquisitions is an optical interference pattern that can be processed into a depth profile, which is also called A-scan. Several adjacent A-scans can be merged into a cross-sectional image. Most research that incorporates OCT requires a software solution for processing of the acquired raw data.


Introduction
Optical coherence tomography (OCT) is a non-invasive imaging technique used primarily in the medical field, especially in ophthalmology. The core element of any OCT system is an optical interferometer that generates a spectral fringe pattern by combining a reference beam and the backscattered light from a sample. To obtain an interpretable image from this acquired raw OCT signal several processing steps are necessary, whereby the inverse Fourier transform represents an essential step. As the possible acquisition speed for raw OCT data has increased constantly, more sophisticated methods were needed for processing and live visualization of the acquired OCT data. A particularly impressive setup was presented by Choi et al. (Choi, Hiro-Oka, Shimizu, & Ohbayashi, 2012) that utilizes twenty FPGA-modules for real-time OCT signal processing and a graphics processing unit (GPU) for volume rendering. Nowadays, processing is typically done on graphics cards (Jian, Wong, & Sarunic, 2013;Rasakanthan, Sugden, & Tomlins, 2011;Sylwestrzak et al., 2012;Wieser et al., 2014;Zhang & Kang, 2010), not FPGAs, because implementing algorithms on GPUs is more flexible and takes less time (Li, Sarunic, & Shannon, 2011). Most of the publications that describe OCT GPU processing do not provide the actual software implementation. A commendable exemption is the GPU accelerated OCT processing pipeline published by Jian et al. The associated source code, which demonstrates an implementation of OCT data processing and visualization and does not include any advanced features such as a graphical user interface (GUI), already consists of several thousand lines. Thus, the most time consuming task of Fourier Domain OCT (FD-OCT) system development is not the optical setup, but the software development. The software can be separated into hardware control and signal processing, whereby the former being a highly individual, hardware-dependent software module and the latter being a generic software module, which is almost identical for many systems. To drastically reduce OCT system development time, we present OCTproZ, an open source OCT processing software package that can easily be extended, via a plug-in system, for many different hardware setups. In this paper we give a brief overview of the key functionality and structure of the software.

Basic overview of OCTproZ
OCTproZ performs live signal processing and visualization of OCT data. It is written in C++, uses the cross-platform application framework Qt (Qt, 2020) for the GUI and utilizes Nvidia's computer unified device architecture (CUDA) (NVIDIA, 2020) for GPU parallel computing. A screenshot of the application can be seen in Figure 1. changed before processing is started or while processing is in progress. Processed data is live visualized in 2D as cross sectional images (B-scan and en face view) and in 3D as interactive volume rendering. The live view shows a piece of wood with a couple layers of tape and a laser burned hole.
The software can be separated into three parts: main application, development kit (DevKit) and plug-ins. The main application, OCTproZ itself, contains the logic for the GUI, processing and visualization. The DevKit, which is implemented as static library, provides the necessary interface for plug-in development. Plug-ins can be one of two kinds: "Acquisition Systems" or "Extensions". The former represent OCT systems and provide raw data to OCTproZ, the later are software modules that can extend the functionality of an OCT system (e.g., software control of a liquid lens) or provide additional custom defined post processing steps. All plug-ins are dynamic libraries that can be loaded into OCTproZ during runtime.

Processing Pipeline
Raw data, i.e. acquired spectral fringe pattern, from the OCT system is transferred to RAM until enough data for a user-defined amount of cross-sectional images, so-called B-scans, is acquired. Via direct memory access (DMA) this raw data batch is then copied asynchronously to GPU memory where OCT signal processing is executed. If the processed data needs to be stored or post processing steps are desired the processed OCT data can be transferred back to RAM with the use of DMA. An overview of the processing steps is depicted in Figure 2. The processing pipeline consists of data conversion, k-linearization, numerical dispersion compensation, windowing, fast Fourier transform, fixed-pattern noise removal, truncate, logarithm, backward scan correction, sinusoidal scan correction and visualization. A detailed description of each processing step can be found in the user manual. Here we just want to mention that the implementation of the fixed-pattern noise removal is based on a publication by Moon et al. (Moon, Lee, & Chen, 2010) and the volume viewer is based on source code from an open source raycaster (Pilia, 2018). In order to avoid unnecessary data transfer to host memory, CUDA-OpenGL interoperability is used which allows the processed data to remain in GPU memory for visualization.

Processing Performance
Processing rate highly depends on the size of the raw data, the used computer hardware and resource usage by background or system processes. With common modern computer systems and typical data dimensions for OCT, OCTproZ achieves A-scan rates in the MHz range. Exemplary, Table 1 shows two computer systems and their respective processing rates for the full processing pipeline. However, since the 3D live view is computationally intensive the processing rate changes noticeably depending on whether the volume viewer is activated or not. The used raw data set consists of samples with a bit depth of 12, 1024 samples per raw A-scan, 512 A-scans per B-scan and 256 B-scans per volume. As the volume is processed in batches, the batch size was set for each system to a reasonable number of B-scans per buffer to avoid GPU memory overflow. It should be noted that this performance evaluation was done with OCTproZ v1.0.0 but is also valid for v1.2.0 if the newly introduced processing step for sinusoidal scan distortion correction is disabled. A-scans per second~250 · 10 3~4 .0 · 10 6 Volumes per second~1.9~30 Without 3D live view: A-scans per second~300 · 10 3~4 .8 · 10 6 Volumes per second~2.2~36

Plug-in System
To develop custom plug-ins for OCTproZ and thus extend its functionality, a development kit is provided. It consists of a static library and a collection of C++ header files that specify which classes and methods have to be implemented to create custom plug-ins. Currently two kinds of plug-ins exist: Acquisition Systems and Extensions. For both we made examples including source code publicly available which may be used together with the open source and cross-platform integrated development environment Qt Creator as starting point for custom plug-in development.
The main task of an Acquisition System is to provide raw data to OCTproZ. In most cases, this means that the implementation of an Acquisition System contains the software control of a data acquisition unit.
Extensions have a wide area of use cases. As they are able to receive raw data and processed data via the Qt signals and slots mechanism, they are suitable for custom post-processing routines. The exact implementation of an Extension is mainly up to the developer and can also include hardware control. Therefore, Extensions are ideal for hardware control algorithms that rely on feedback from live OCT images. The best example of this is wavefront sensorless adaptive optics with a wavefront modulator such as a deformable mirror. Particular care must be taken if high speed OCT systems are used, as the acquisition speed of OCT data may exceed the processing speed of the custom Extension. In this case, a routine within the Extension should be implemented that discards incoming OCT data if previous data is still being processed.

Conclusion
In this paper, we introduced OCTproZ, an open source software package for live OCT signal processing. With the presented plug-in system, it is possible to develop software modules to use OCTproZ with custom OCT systems, thus reducing the OCT system development time significantly. OCTproZ is meant to be a collaborative project, where everyone involved in the field of OCT is invited to improve the software and share the changes within the community. We especially hope for more open source publications within the OCT community to reduce the time necessary for the replication of OCT processing algorithms and thereby accelerate scientific progress.

Funding
This work was partially funded by the European Regional Development Fund and the state of Lower Saxony as part of the project OPhonLas (EFRE-SER 2014.