Starting at Columbia this year, I had nearly no introduction to the concept of Optical Coherence Tomography (OCT) beyond seeing a number of impressive heart scans. It would be pretty disingenuous to call myself an "expert" on the topic now, but after a few months hands on with a few OCT systems and their respective processing backends, I feel I have gained a respectable understanding of the imaging modality.
Specifically with respect to the use of OCT for vibrometry through Spectral Domain Phase Microscopy (SDPM), I have learned that there is a lot of data.
When I first arrived at Fowler lab here at Columbia's Medical Center, we were using an off-the-shelf OCT system for en vivo SDPM of the mammalian basilar membrane. OCT is wonderful for this task, as it has relatively high resolution with enough penetration depth to see the basilar membrane in rodents. The shocking fact, to me, was that despite a very fast data acquisition from the OCT system (about 100kHz), the processing required for generating depth information from the raw OCT output and then SDPM could take several hours, and even a full day (!) for long experiments.
Why? Well for SDPM to give meaningful vibrometry data with a high SNR, you want to take scans over a relatively long time period (the longer the better, theoretically). We want to measure vibration in response to multiple stimuli as well, and at multiple instances in time, so we could have upwards of an hour worth of OCT outputs. The simple motion of this data between RAM and hard drive imposes a serious delay, and is pretty much unavoidable.
If we look at a single output of the OCT, it is a wavelength-domain positive real-valued signal with as many values as there are photodetectors in the device. Once we transform this data to the depth space, we are only actually interested in the motion of a few pixels in the depth signal (those corresponding to the basilar membrane, hair cells, etc.). Thus our signal of interest is sparse, but not in the domain of acquisition! Which means that the problem cannot be simplified through compressive sensing.
So speaking to some folks at the lab, this slow processing seemed like a fact of life -- there was nothing to be done about it. However, there was one clear object in the way of enhanced speed: MATLAB.
Look, I love MATLAB. Being an electrical engineer means you love MATLAB. It is basically the single best platform for rapid prototyping of image processing algorithms, including OCT line processing and SDPM. But MATLAB is painfully slow, and this should come as no surprise to experienced MATLAB users.
Furthermore, if the data processing could happen at acquisition time, we could transfer a sparse signal from RAM to hard drive rather than continuing to move around massive amounts of data. So MATLAB is pretty much the worst solution to this problem that one could imagine!
And simple motion of the key processing code to C++ saw a speed-up of 200 times! Which is actually enough to make most processing real-time for our experiments.
In the future we might want to do considerably more computationally complex experiments, in which case this solution likely wouldn't be fast enough either. There has been some research over the past few years on the viability of GPU processing for OCT scanning, which looks very promising on face value, but they all make a very important oversight.
Let's consider the pipeline -- OCT data comes in fast, it is loaded into RAM, pushed into the GPU, processed, pushed back into RAM and displayed to the user. What's missing?
Well if you just want to look at some OCT scans in real-time, nothing is missing, but this is not particularly valuable for scientific research purposes where this data needs to be saved somewhere. Motion from RAM to hard drive actually presents a bottleneck in very large OCT processing problems!
However, it is possible that for SDPM purposes, this bottleneck can be mitigated by abusing the sparseness of our signal of interest in the depth domain. I do believe this is possible, and as a result I am now looking into SDPM processing on GPUs, an as of yet untouched field.
So what's the main takeaway? Don't use MATLAB for computationally intense tasks, and never forget that data transfers are almost always a bottleneck for large-scale processing tasks.
Comments