Algorithm Optimization for Swept Source Fourier Domain Optical Coherence Tomography (OCT) with Galvo Scanner and Digital Signal Processor (DSP) Kevin Seekell Faculty Mentor: Professor Zhongping Chen Ph.D Candidate Mentor: Jianping Su

What is OCT? A non-invasive medical technique that uses the interference of light waves to produce images. Data is gathered using low- coherence interferometry.

Project Goals Involuntary movement of the subject (ex. the retina) can greatly distort the image. Increasing the speed of data acquisition and processing reduces this risk. Faster processing speeds would allow for on- site diagnosis. This project focuses on modifying the algorithms (in C++) controlling the OCT to make them quicker and more effective.

Galvo Mirrors A pair of micro-scale mirrors guide the scanning laser. Controlled by an applied voltage. Program NI PCI DAQ to provide voltage waveforms. Path created by the galvo mirrors to scan the sample

Channel 0: Step Function Total of 500 steps Voltage ranges from –0.5V to 0.5V Returns to 0V after completing the scan.

Channel 1: Ramp Functions Period of 62.5 ms. Voltage range from -1V to 1V. A step in Channel 0 occurs when Channel 1 reaches -1V.

Combined Results:

Swept Source OCT

Conversion to Rotational Image: scanning laser Linear Image Rotational Image

Frame-to-Frame Algorithm Two functions: –CreateTable(): Calculates the radius and angle of each pixel that will be in the rotational image. –RotateImg(): Uses the previous calculation to find the corresponding pixel in the linear image. The pixel value is calculated through interpolation. The pixel value is then written into the new bitmap file.

New Interpolation Method Frame-to-Frame algorithm interpolates pixel values using the four surrounding pixels. –Weights are given based on the target pixel’s distance from each of these pixels. The new method only uses the pixels to the left and right to interpolate. –This program should show how much interpolation effects program speed.

Why Use Lines? Symmetry Each radial line has the same length (radial components). Only differ in angles. Need much less information to describe each pixel in the final Image.

Line-to-Line Algorithm Same two functions as Frame-to-Frame. –CreateTable(): Stores radius values for any given line, and a set of angles spanning the whole circle. Can be used to describe any single pixel. –RotateImg(): basically the same as frame-to-frame. Works with every pixel in a radial line before moving to the next one. Should allow for the data to be processed as each individual A-scan is made.

Testing the Algorithms Creating the Sample Image The CreateBMP() function writes and saves a 1024x1024sample bitmap image. 10 evenly spaced horizontal and vertical stripes pass through a black background. If the rotation runs correctly: Vertical lines become radial lines. Horizontal lines become concentric circles.

Timing the Programs The ctime library is used to time each algorithm. clock_t begin=clock(); //records start time. clock_t end=clock(); // records end time. float period=(float) (end-begin); //total time. This method may be used to record the entire execution time for each algorithm or the times for individual segments of the programs.

Experimental Procedure Use the sample image in each rotational algorithm to observe the final image. Repeat each algorithm 10 times to record: –Execution time for CreateTable() function. –Execution time for RotateImg() function. –Total execution time.

Results Frame-to-Frame Algorithm: Average CreateTable() Time: ms Average RotateImg() Time: ms Average total Time: ms

New Interpolation Average CreateTable() Time: ms Average RotateImg() Time: 386.7ms Average Total Time: ms

Line-to-Line: Original Average CreateTable() Time: 0 ms Average RotateImg() Time: ms Average Total Time: ms

Major Flaw Frame-to-Frame calculates the radius and angle for each pixel in the order in which they appear in the rotational image. –Therefore it knows where to place each pixel value after calculating them. Line-to-Line creates arbitrary radii and angle values. –The program has no way of knowing where to place the pixel values afterwards.

Possible Solutions Sine and Cosine –Use the trig functions to calculate proper x and y coordinates before writing the pixel value. Increment –When saving the pixel values on a radial line, increment the x and y coordinates each time by a value based on the line’s angle.

Line-to-Line: Increment Average CreateTable() Time: 0 ms Average RotateImg() Time: ms Average Total Time: ms

Line-to-Line: Sine and Cosine Average CreateTable() Time: 0 ms Average RotateImg() Time: ms Average Total Time: ms Takes roughly 33% less time then the frame-to-frame algorithm

Observations: Line-to-Line algorithm –Higher speed, but lower accuracy –Accuracy becomes lower as the radius increases –Greatest amount of time spent on sine and cosine functions Frame-to-Frame or Line-to-Line –With a few more adjustments, line-to-line should be the preferred method

PC vs. DSP Rotational tests performed on a PC During OCT data acquisition, rotational program is run on a Digital Signal Processor PC and DSP do not perform by the same mechanisms Difference between the algorithms should be greater when integrated into the DSP

Future Work: Fix calibration and memory algorithms to produce the 3-D image New interpolation method for the line-to-line algorithm Incorporate line-to-line into DSP

Acknowledgements Dr. Zhongping Chen Jianping Su Said Shokair and the UROP Department IM-SURE Fellows National Science Foundation

Questions?