Transcript to view the document.

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 lowcoherence
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 onsite 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 PCI6115 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 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: 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?