Home Projects & Research
Valve models from 64-slice cardiac CT scans (using active appearance models) PDF Print E-mail
Written by Administrator   
Tuesday, 29 December 2009 19:46

This project is the basis for my thesis for my masters degree at UConn. My main goal with the project was initially obtaining the data, which was more challenging than anticipated. Hospital PACS systems are generally designed to store lots of imaging data and make it available for 30 days or so. Then the images go into an archive and can be retrieved when necessary... which generally means one patient at a time. PACS is not designed to retrieve large batches of data, like the 900+ patients we got IRB approval to analyze. The 125 or so patients that I did get will be very useful for future imaging studies though.

I was interested in active appearance models (AAMs) as a method to extract 3D valve models from the CT data because of a project I did in my first semester in a pattern recognition class. I actually used active shape models (ASMs), which are very similar to AAMs, to analyze 2D brain images. It worked fairly well and was able to extract the features from most target images. It wasn't terribly robust because it didn't take into account the texture information like AAMs do. I was hoping to extend the 2D ASMs into 3D AAMs for my thesis.

Transforming the 2D statistical shape model (SSMs) algorithm, of which AAMs and ASMs are subset, to 3D is not complicated. A decision must be made to use polar coordinates, quaternions, or another method of rotation in 3D space, but the general equations and algorithm are very similar. The difficult part is in creating the training data. Creating landmarks on 2D training data might involve picking 25, 50, or more points for each training image. The position of the points is generally the same in each image, so loading a 'master' set of points onto each image and moving the points individually to each landmark is relatively easy.

When trying the 2D approach in 3D it gets a lot more complicated. A simple solution, which has been done in the past is to reslice the volume and apply 2D AAMs to each slice. The drawback to this method is that the 3D objects are of different heights and can occupy different numbers of slices. This can be overcome by normalizing the heights, however the internal structures will appear on different slices. So that method is out.

The method I initially chose was to reslice the CT volumes along the long axis of the aortic valve (the valve were interested in), and establish a set of landmark points that describe the important details of the valve. The points would be defined individually for each of the training datasets and manually moved in a 3D viewer to correct locations. The problem with this is the size of the landmark set. Two hundred points might be necessary to accurately describe the valve shape in 3D, however this is an enormous number of points and would extremely time consuming to click them all by hand.

So now I search for better landmarking methods, and better methods are not limited to using AAMs. I may continue with AAMs, but if I find a simpler feature extraction method, I will probably experiment with it.

MRI data storage system PDF Print E-mail
Written by Administrator   
Wednesday, 09 December 2009 02:41

The Olin Center was started back in 2003, with it's first recorded scans in April. The archiving and retrieval method at the time was a simple web interface that had access to only the past 30 days worth of data. The rest of the data was archived to DVD. After a couple years it became tough to find the data you wanted because you'd need to sift through 200 DVDs to find the MRI scans you wanted. It became more challenging if you needed data from 100 subjects. So in 2005 I built 4 servers to house the MRI data and created a simple web interface to allow people to search and download the directly to our analysis servers. The whole system was dubbed "All Data Online" or the adoserver for short.

In 2007 I rebuilt the system, distributing the data between 2 servers. At the time, there was approximately 6.5TB of data stored on the servers, all instantly searchable and downloadable. Earlier this year, I needed to rebuild the system and placed the entire system on a single server... The trend from 4 to 2 to 1 server is because of the tremendous drop in the price of disk space. It's just more affordable to have 14TB of space on a single server than 2 servers with 7TB. It's also easier to maintain. Since the amount of data transfer on and off the server is about 8GB/day, there's no bottleneck in keeping it in one place.

Now, at the end of 2009 after 7 years of collecting MRI data, our data is archived in triplicate on 1200 DVDs, we have more than 7500 MRI studies, and 170,000 series of MRI data, stored in 4 different formats. In total there are 12TB of data in approximately 68 million files, and the system has used 160 CPU-days to process and archive the data. There are also new reporting, auditing, and trend monitoring tools. Searches are faster and more comprehensive, with thumbnail image results. There have been approximately 40,000 data requests since the system was created, though the counter was reset with each new system.


Last Updated on Tuesday, 29 December 2009 19:45
Hyperscanning PDF Print E-mail
Written by Administrator   
Wednesday, 09 December 2009 02:30

This is a really interesting project that is currently ongoing at the Olin Center. It started back in 2007 with the idea to have two participants play a game of dominoes between two MRI sites. The sites would be the Olin Center in Hartford, CT and the MIND Institute in Albuquerque, NM. The game play is based off of a reward/punishment game written by Itamar Kahn around 2002. Since we knew we got the activation we wanted from the Itamar's game design, we wanted to replicate it for the hyperscanning game. I used similar commands and timings to the old game, but the rest of it was built from scratch. I redid the domino and screen layout, got new voiceovers for the commands, and most important made it networked. I needed to write a server, which actually controlled the game play. The clients connect to the server and all communication between clients goes through the server. We also needed to overcome firewalls and IRB approval, but we eventually ran 3 sets of subjects between the two sites.

As anyone can imagine, the task of arranging and executing game play over the internet, while synchronizing two fMRI sessions can be challenging. Not to mention booking the subjects, especially at centers which don't have a lot of free scan slots. We also found that a landline telephone is the best method to synchronize the start of the game. No special network protocols necessary.

Hopefully we'll run another 10 sets of subjects and publish some results this year.

fMRI of Menstrual Migraine PDF Print E-mail
Written by Administrator   
Tuesday, 08 December 2009 03:22

This was a fascinating project that I worked on at the Olin Center from 2006 to 2008. My goal with this project was to induce a migraine in participants while they received a functional MRI scan. The goal from that is to observe migraine pathogenesis, or any interesting physiologic activity that occurs at the beginning of migraine. The biggest challenge was actually getting someone to get a migraine while the scanner was running. I had a self imposed time limit of about an hour for the participant to be in the scanner, because of expensive scan slots, scanner scheduling, and that no one with a migraine would want to be scanned for that long.

It took a lot of work to get the IRB to approve the protocol, but because I was going to scan menstrual associated migraines, the IRB eventually got the picture. Women with menstrual associated migraines get migraines like clockwork at the beginning of their menstruation cycle, so they would get a migraine whether we scanned them or not. It just happened to the best time to scan them. When I told a friend what I was doing in this project, he said "You have the greatest job in the world. You're going to find PMSing women, give them a migraine and then give them an MRI. Good luck". It actually turned out to be pretty difficult to induce a migraine, even in women with predictable menstrual migraine.

My initial recruitment goal was 15 subjects (6 migraine w/aura, 6 migraine w/out aura, 3 healthy controls). As of Fall 2007 I had recruited 12, scanned 7 (including test subjects to tweak protocol), and successfully induced and observed a migraine in one patient. I gave a talk at the Olin Neuropsychiatry Research Center on September 25, 2007 about the study and a summary of current migraine pathogenesis understanding. The talk is available in PDF. The most interesting finding for the single subject who got a migraine was a negative activation in the trigeminal ganglion during the visual stimulation from the flashing checkerboards. The subject who did not get a migraine had no activation there. The MR angiogram produced no significant changes in blood vessel diameter.


Page 3 of 3
Copyright © 2017 gbook.org. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.