Algorithm Optimization for Swept Source Fourier Domain Optical Coherence Tomography (OCT) with Galvo Scanner and Digital Signal Processor (DSP) Kevin Seekell.

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-6115 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

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 finalImage.

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.

ResultsFrame-to-Frame Algorithm:

Average CreateTable() Time: 302.9 ms

Average RotateImg() Time: 320.6 ms

Average total Time: 623.5 ms

New Interpolation

Average CreateTable() Time: 231.3 ms

Average RotateImg() Time: 386.7ms

Average Total Time: 617.4 ms

Line-to-Line: Original

Average CreateTable() Time: 0 ms

Average RotateImg() Time: 206.0 ms

Average Total Time: 206.0 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: 279.5 ms

Average Total Time: 279.5 ms

Line-to-Line: Sine and Cosine

Average CreateTable() Time: 0 ms

Average RotateImg() Time: 419.6 ms

Average Total Time: 419.6 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?