Rudy Lam just graduated with a BSc in Engineering Physics, Electrical Option. Rudy worked at the Biomedical Signal and Image computing Lab (BiSICL) with Professor Rafeef Abugharbieh and her PhD student Seyed-Alborz Amir-Khalili over the summer researching software that enables real-time localization of bones in three-dimensional (3D) ultrasound images.
How would this technology be used in a medical setting?
A surgeon needs a real-time view of the inside of a patient’s body during a minimally-invasive surgical procedure, e.g. a fracture reduction where broken pieces of bone are realigned. A common method of getting a detailed image is to use radiation based imaging, such as X-ray and CT scans. Though such images do clearly reveal the patient’s anatomy as well as where the surgeon’s instruments are in relation to the areas to be operated, radiation has serious potential effects on both patients and surgical teams. Dr. Abugharbieh’s lab is thus currently investigating the use of 3D ultrasound imaging as a safer alternative. Ultrasound however does not produce as crisp an image so to process the data and see clear features one needs to apply advanced signal processing techniques to overcome the high levels of noise and low signal levels.
That is where my algorithm comes in. This algorithm is used when we automatically calculate image features through a ‘phase symmetry’ measure that Prof. Abugharbieh’s lab has shown to be an excellent way to localize bony structures and bone fragments in ultrasound.
What is your role in the project?
The algorithm was already written. I am optimizing the software to enable it to run in real-time in an operating room setting.
The optimization involves streamlining the code and looking for alternate methods to implement the same code. Currently, the code is running on the CPU that has only one core so it can only execute one command at a time. I am trying to execute as much of the code on the GPU that can execute commands on many different values at the same time. At times the program alternates between the CPU and the GPU because there are some algorithms that are difficult to execute on the GPU. The ultimate goal is to implement as much code on the GPU as possible.
Working from the GPU is a different way of thinking and organizing the code. There is also a difference in syntax and differences in the nuances of programming such as memory allocation, defining what is executed and how you define it. To define functions that are GPU executable and connect it with the host you need to create a bridge.
What have been some of the challenges you’ve encountered?
When you have a 3D piece of data you imagine the data inhabiting a cube but on the memory it is not allocated like that. It is allocated in a 1D array. The question is how do I write this 3D structure into a 1D array consistently so that, when I apply a filter to the image, I am overlaying correctly and I’m multiplying the points that correlate. In the beginning I was getting garbage values and had to adjust the algorithm. The code does not always behave the way you anticipate so there is some learning and re-writing that has to happen.
What languages are you working in?
The GPU language is in Cuda which is C and the CPU language is C++.
What skills did you bring to the position?
I had a very solid background in math and I took CPSC 260 and other programing courses, not specifically C but the principles were the same. I think Dr. Abugharbieh chose me for the position because of my strong math and logic.
How will this internship help you in the future?
I wanted my Summer position to involve a lot of programming because I am looking towards a career in software. This was the perfect opportunity to expand my programming skills and give me the confidence to apply for software jobs.