algorithm optimization for swept source fourier domain optical coherence tomography (oct) with galvo...
Post on 22-Dec-2015
223 views
TRANSCRIPT
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?