During the last month, I took part in the Kaggle challenge on Galaxy Zoo. Kaggle is a platform for Machine Learning challenges, and the goal of the Galaxy Zoo challenge is to learn how humans classified galaxies in order to replace those humans by a program able to classify previously unseen galaxies. As my PhD is on the automated localisation of different fetal organs in MRI scans, Machine Learning is my current obsession (see my previous post on object detection). I chose to take part in this challenge out of my frustration of doing Machine Learning on 50 patients... Indeed, Galaxy Zoo lets us train on 61578 galaxies, and asks us to classify 79975 galaxies. As a result, after finishing 56th out of 329 participants (which puts me in the top 25%), it was an extremely fruitful experience.
I spoke of classification, but the annotations we actually learn from are the responses humans gave to a set of questions. Whereas most competitors went for a regression on the vector of all the human scores, I took a slightly different approach, learning features from the galaxies humans most agreed on.
I worked in Python, using OpenCV for cropping and rotating the galaxies, and scikit-learn for the machine learning part. I decided to use Random Forests (or the very similar Extremely Randomized Trees) to learn a regression on the whole traning data, thinking that if I managed to get the right features that could properly separate the data, it would work.
Wednesday, 9 April 2014
Thursday, 27 March 2014
Object detection
This blog post aims to provide an overview of the main trends in object detection
I encountered in the literature.
Object detection is the process of automatically detecting in an image instances of a class, such as cars or pedestrians. Object localisation is often considered synonym of detection, the main difference I see in medical imaging is that an MRI scan will contain one and only one heart or brain, a localisation task thus assumes the presence of the object in the image. However, in a typical computer vision task, an image could contain several cars or none at all, and the detection task must thus decide whether the object is present or not before finding its location in the image. In the following, I will talk indifferently of detection or localisation.
The simplest approach to find a given object in an image is template matching. This is a very limited approach deprived of any generalisation: it is principally aimed at finding the position of a cropped image in the original version of the image, but it can also be used for objects that have very little variation within a class. An example application in object detection is Anquez et al. (2009) who used template matching to detect the eyes of the fetus in motion free MRI scans, as a starting point for a brain detection pipeline.
In order to take into account the variable appearance of objects within a class, a machine learning framework is usually adopted. An algorithm is trained on training data, using validation data to tweak its various parameters. Testing data, which has not been seen by the detector during training or validation, is then used to assess the accuracy of the trained detector (Bradski et al., 2008). In order to make decisions about images, the algorithm extracts features, which can be as simple as the difference of mean intensities over two rectangular areas (Criminisi et al., 2011), or more complex such as histograms of SIFT features matched to their nearest neighbour in a “vocabulary” of image patches (Csurka et al., 2004). These features are then passed to a machine learning method such as Boosting, Random Forest or SVM, to learn the appearance of the object during training, or to make a decision at testing time. If you look at the common interface for feature detectors in OpenCV and the generic API for classifiers in scikit-learn, you shall notice that image features and machine learning methods are building blocks which can be easily interchanged. Switching between SIFT and SURF, or SVM and Random Forest can be as easy as changing a line of code. Among other things, the choice relies on a trade-off between the desired performance in speed or accuracy, whether your features need to be rotation invariant, the size of your training dataset, whether you have multi-channel images, your hardware limitations such as memory, and of course the implementations you have at hand. Independently of the choice of image features or machine learning method, the questions I am mostly interested for this blog post are the following:
Object detection is the process of automatically detecting in an image instances of a class, such as cars or pedestrians. Object localisation is often considered synonym of detection, the main difference I see in medical imaging is that an MRI scan will contain one and only one heart or brain, a localisation task thus assumes the presence of the object in the image. However, in a typical computer vision task, an image could contain several cars or none at all, and the detection task must thus decide whether the object is present or not before finding its location in the image. In the following, I will talk indifferently of detection or localisation.
The simplest approach to find a given object in an image is template matching. This is a very limited approach deprived of any generalisation: it is principally aimed at finding the position of a cropped image in the original version of the image, but it can also be used for objects that have very little variation within a class. An example application in object detection is Anquez et al. (2009) who used template matching to detect the eyes of the fetus in motion free MRI scans, as a starting point for a brain detection pipeline.
In order to take into account the variable appearance of objects within a class, a machine learning framework is usually adopted. An algorithm is trained on training data, using validation data to tweak its various parameters. Testing data, which has not been seen by the detector during training or validation, is then used to assess the accuracy of the trained detector (Bradski et al., 2008). In order to make decisions about images, the algorithm extracts features, which can be as simple as the difference of mean intensities over two rectangular areas (Criminisi et al., 2011), or more complex such as histograms of SIFT features matched to their nearest neighbour in a “vocabulary” of image patches (Csurka et al., 2004). These features are then passed to a machine learning method such as Boosting, Random Forest or SVM, to learn the appearance of the object during training, or to make a decision at testing time. If you look at the common interface for feature detectors in OpenCV and the generic API for classifiers in scikit-learn, you shall notice that image features and machine learning methods are building blocks which can be easily interchanged. Switching between SIFT and SURF, or SVM and Random Forest can be as easy as changing a line of code. Among other things, the choice relies on a trade-off between the desired performance in speed or accuracy, whether your features need to be rotation invariant, the size of your training dataset, whether you have multi-channel images, your hardware limitations such as memory, and of course the implementations you have at hand. Independently of the choice of image features or machine learning method, the questions I am mostly interested for this blog post are the following:
- At which positions in the image do you want to run your classifier? At every pixel, every superpixel or only on salient regions?
- When your classifer is positioned in the image, is it voting for the current location or for an offset location (see Hough transform)?
- Are you running only one detector, or a cascade of detectors? How do you then define “coarse to fine”?
- If you need to detect several parts of an object, how do you take the spatial configuration into account instead of running independant detectors?
- How do you summarize image information and combine different features?
Sunday, 2 March 2014
XKCD-style beamer presentation (LaTeX)
Last December, I had a short presentation to do, not necessarily too formal, so I decided to have a go at the different XKCDify codes lying around the web to make a more original LaTeX beamer presentation.
It seems that a version of the code is now shipped with Matplotlib, with a basic example here, and the whole galery of Matplotlib examples turned into XKCD plots there.
I did not notice any official code back in December, from what I understood, the idea originated on the Matplotlib users mailing-list from Damon McDougall, followed by a blog post by Jake Vanderplas. But the code I finally used is from Johannes Buchner, with some hard-coded parameterisation. To simulate hand drawn lines with Tikz, I used the LaTex code from percusse.
For the font, I recommand the LaTeX font catalogue to avoid any installation trouble, but in the end, I used the script from Holger Widmann to install Humor-Sans.ttf, which can be downloaded from several places.
Lastly, some LaTeX code to use the font:
and some page layout changes for the Boadilla theme:
and here are the slides:
Automated segmentation and motion correction of the fetal brain
Regarding the content of the slides, a paper is under review, so more information about it will be presented in due time.
It seems that a version of the code is now shipped with Matplotlib, with a basic example here, and the whole galery of Matplotlib examples turned into XKCD plots there.
I did not notice any official code back in December, from what I understood, the idea originated on the Matplotlib users mailing-list from Damon McDougall, followed by a blog post by Jake Vanderplas. But the code I finally used is from Johannes Buchner, with some hard-coded parameterisation. To simulate hand drawn lines with Tikz, I used the LaTex code from percusse.
For the font, I recommand the LaTeX font catalogue to avoid any installation trouble, but in the end, I used the script from Holger Widmann to install Humor-Sans.ttf, which can be downloaded from several places.
Lastly, some LaTeX code to use the font:
%% use xkcd font
%% Note: that's a font with no bold or italic...
\usepackage[T1]{fontenc}
\definecolor{xkcd_color}{rgb}{.376,.435,.533}
\usecolortheme[named=xkcd_color]{structure}
\renewcommand{\familydefault}{xkcd}
and some page layout changes for the Boadilla theme:
%% do not use any \useoutertheme{}
%% disable navigation symbols
\setbeamertemplate{navigation symbols}{}
%% center slide titles
\setbeamertemplate{frametitle}[default][center]
%% customise the footline: only slide numbers
\setbeamertemplate{footline}{
\begin{beamercolorbox}[ht=2.5ex,dp=1.125ex,
leftskip=.3cm,rightskip=.3cm plus1fil]{}
\hfill \small \insertframenumber/\inserttotalframenumber%
\end{beamercolorbox}%
}
and here are the slides:
Automated segmentation and motion correction of the fetal brain
Regarding the content of the slides, a paper is under review, so more information about it will be presented in due time.
Tuesday, 17 December 2013
IRTK Python
Python for Medical Imaging¶
There are several reasons for choosing Python for Medical Imaging. First of all, the main biomedical imaging library out there, ITK, offers both exhaustive SWIG wrappers and a simplified interface called SimpleITK, which can be directly installed from PyPI. Other major libraries, such as VTK for data visualization and OpenCV for Computer Vision also provide excellent Python wrappers.
Then comes the Python eco-system itself, whose ressources for Machine Learning and Image Processing have been growing in the last years with the main libraries: scipy.ndimage, scikit-image and scikit-learn. There are also Python modules for input/output of medical images, such as pydicom and nibabel.
Finally, enough is never enough, there is cython to easily mix python and C/C++ code.
But there's more to Python than a set of existing libraries. It is simple to write, yet powerful. It has a wide community, much wider than the limited scope of scientific computing. It is Open Source, which is a key element for research. It offers several possibilities for optimizing code, for instance making an efficient use of numpy, using joblib for parallelization or cython for C++ optimization.
Then comes the Python eco-system itself, whose ressources for Machine Learning and Image Processing have been growing in the last years with the main libraries: scipy.ndimage, scikit-image and scikit-learn. There are also Python modules for input/output of medical images, such as pydicom and nibabel.
Finally, enough is never enough, there is cython to easily mix python and C/C++ code.
But there's more to Python than a set of existing libraries. It is simple to write, yet powerful. It has a wide community, much wider than the limited scope of scientific computing. It is Open Source, which is a key element for research. It offers several possibilities for optimizing code, for instance making an efficient use of numpy, using joblib for parallelization or cython for C++ optimization.
Why another Medical Imaging library in Python?¶
IRTK is a Medical Imaging library developped within the BioMedIA group at Imperial College London, initially built around Daniel Rueckert's non-rigid registration using free-form deformations. While ITK deals with ND-images, can read most image formats and has a wide range of applications ranging from cell microscopy to satellite images, IRTK is much more focused, its core component being image registration. It can read NIFTI files, and write NIFTI and PNG files, and all images in IRTK are 4D (X, Y, Z, T), with flat dimensions where necessary. The code is only templated other VoxelType.
The main reason I chose to write a Python interface for IRTK instead of using what already existed is that it is much easier to collaborate within the lab if we all use a same code base. Moreover, I wanted medical images to be as much pythonic as possible, namely a subclass of numpy.ndarray which would automatically update its spatial coordinates when cropped.
The main reason I chose to write a Python interface for IRTK instead of using what already existed is that it is much easier to collaborate within the lab if we all use a same code base. Moreover, I wanted medical images to be as much pythonic as possible, namely a subclass of numpy.ndarray which would automatically update its spatial coordinates when cropped.
Monday, 16 December 2013
Thumbnails, default viewer and property tab in nautilus for medical images
This first post is on customising Ubuntu to your needs to make your work easier (and more enjoyable). It is accompanied by this github repository.
Here are quick changes to a brand new installation of Ubuntu:
As you can guess from its title, the main focus of this post is to give medical images what they lack compared with more common image formats: MIME types, thumbnails, open a chosen viewer when you double-click on them, and a property tab in nautilus.
Here are quick changes to a brand new installation of Ubuntu:
- First of all, restart it with the Gnome classic (no effects) mode to get rid of blinking effects, and set it as default mode.
- Set a proper prompt in .bashrc:
PS1="\[\033[1;30m\][\$?]<\[\033[1;35m\]\u\[\033[1;30m\]>{\$(date +%d-%m\" \"%H:%M)}[\w]\[\033[0m\] "
and in .tcshrc:
set prompt="%{\033[1;30m%}[%?]<%{\033n@[1;35m%}m%{\033[1;30m%}>{%D-%W %T}{\033\[0m[%~]} "
The prompt is here to give you useful information such as current folder, current time or exit code of the last command. - Set the location bar to text mode in nautilus, I find it much more easier to type in text with auto-completion than scroll-down and click on folders, and it enables you to copy and paste folder paths:
gsettings set org.gnome.nautilus.preferences always-use-location-entry true - Install nautilus-open-terminal to open a terminal in the current directory from nautilus:
sudo apt-get install nautilus-open-terminal
As you can guess from its title, the main focus of this post is to give medical images what they lack compared with more common image formats: MIME types, thumbnails, open a chosen viewer when you double-click on them, and a property tab in nautilus.
Subscribe to:
Posts (Atom)