ORKING with bare metal for the purpose of maximal hardware utilisation and performance is not the same as working with typical computer programs. Developing software for research is also different from software development for end users, where the software is treated as a product. Different scenarios require different methodologies and different levels of polish, and thus have different specifications and priorities. In research, brute force becomes essential to the success of one group or another.

I often find myself working on servers or clusters (only GNU/Linux), in which case it is useful to manage up to 50 computers, for example, remotely, at the same time. With full GUI sessions it can be a disorienting task, but that too can be achieved and I wrote about it roughly 6 years ago in this blog (back when I was a Ph.D. student).

Working from the command line at a desktop is perfectly acceptable if brains and not candy count, so platforms like Mac OS X are irrelevant. To do coding on the server I currently use vi as the editor in one terminal and the MATLAB session in another. On the desktop I would use QtOctave, as covered before (also in some screencasts). Unfortunate issues that had me revisit MATLAB (which in any case would be inevitable as means of ensuring compatibility with colleagues) led me back to the old days of developing over SSH (using KIO slaves and the likes of that). Quick access to the file can be gained using abbreviated wrappers such as:

./Main/Programs/Scripts/SSH/42
/opt/matlab/bin/matlab -nodesktop -nosplash -r "addpath(genpath('/home/S00/schestr0/'))"

where 42 is a script numbered after the machine number and the latter command initialises the command line. /home/S00/schestr0/ is using NFS and it can be reached from any computer at the department at the same time (multiple machines can write to the filesystem at the same time, too). If the files are edited locally, they can be passed across to the server using a simple command that transfers them in encrypted form.

scp /home/roy/Main/IT/Programs/get_dicom_heart/* -r
schestr0@eng041.cs.man.ac.uk:/home/S00/schestr0/get_dicom_heart/

Occasional local backups (usually nightly because it is resources-intensive over USB2) are achieved as follows:

mkdir /media/disk/Home/`date +%Y-%m-%d`

tar -cf - /home/roy|split -b 1000m - /media/disk/Home/`date +%Y-%m-%d`/Home-`date +%Y-%m-%d`.tar.

To decipher this, try:

man tar
man split

For example in:

tar -cf - /media/SEA_DISK/Home/|split -b 1000m - Baine-`date +%Y-%m-%d`

the backup is split into chunks of 1 gigabyte and the files are named by the date

To reassemble the above (resorting from backups):

cat *|tar -xf - 

No command line interface should be intimidating. Many powerful computer tasks are managed from it because the command line makes streamlining simpler and scripting jobs is a lot easier. My programs are written in a way that enables assigning many parameters like paths and wildcards, which lets the programs run for many hours and automatically produce output like images, videos, and text for inspection later. Research in computer vision or computer graphics requires heavy computation and for compelling experiments, the larger the sample sets, the more convincing the results. Use of computer resources therefore becomes the difference between failure and success and those who fail to master it can easily perish against the competition. Another valuable skill is knowing how to reuse code (legally of course) and this is where free/libre software orientation helps a lot. Publication in Open Access (OA) and availability of one’s own work — including code — can help gain more citations, which is the currency by which many publications are being judged.

currently put the final touches on my program which detects and analyses the movement of the heart using the fiesta protocol in an MRI-type modality (1.5 Tesla).

Recent and very simplistic experiments, where two rather distinct images were taken from the set and then rotated, were used such that the only real and anatomical shift is a rigid, geometric one. Two sorts of transformations were used; firstly, in two cases the images were rotated about the middle and in one case the rotation was around one of the corners. This gave different types of variations and various parameters were changes until the algorithm was able to track the points (placed at the edges) rather well. There are now new parameters in place, e.g. (in this case):

threshold = 1
transform_type = sum
frame_size = 2
shuffle_radius = 1
draw_grid =  0
arrow_type = gradient
verbosity = 1
output_type = image
draw_circles = 1
triagulate = 1
measure_tangent_component = 1
search_along_gradient = 1
gradient_search_range = 2
boundaries_line_width =  2
...

Going under the suffix “mid” (slice 3 from the bottom) we have an example of how the landmark points get moved between the frames.

Initial frame

Initial frame with landmark points on

Initial frame with connected landmark points

Position of landmark points at the end of the tracking sequence

Looking at edge detectors we have the possibility of fusion for improved tracking — with a two-tier image, one for the derivative and another being the original.

Sample image

Sobel edge detection of the image

Prewitt edge detection of the image

As an engine, I am currently using MATLAB for reasons of succession (other users of the program I built are less likely to run it in Octave like I do), but I don’t touch the MATLAB ‘desktop’, just the bash shell and vi as the editor (ncurses).

T HAS been a while since the last post about an ongoing port from Octave to MATLAB (not a major challenge, ensuing compatibility being the goal) and also since the last episode of TechBytes. I work hard this weekend finishing and finalising (with GUI) my work on an existing project before proceeding to the next, which will deal with 3-D face recognition.

hown here are two images derived from experiments out of which there are also videos. The set of cardiac images contains 340 images, divided into 17 groups of 20 images belonging to each. A group of 20 consecutive images represents one slice imaged throughout one cardiac cycle. This means that from the 2^nd and 4^th slides — images 21 and 61 respectively for example — the signal is approximately correspondent and thus can be compared. A series of experiments was performed in turn, dealing with each slice in isolation and learning how our algorithm copes with the complicated task of tracking the heart’s walls without a priori knowledge such as a model of the heart, for example (a model whose parameter values can be optimised over, for a good fit to be eventually found). We are interested in the rotation of the heart at the different vertical levels, particularly because we expect to see clockwise and counterclockwise movements throughout the cycle, depending on the slice (the heart squeezes blood by moving in different — almost opposite — directions).

The results are encouraging. Leaving aside slices that hardly contain any signal from the heart because they are at the top and bottom edges, it is quite consistently found that there is a clockwise rotation at the centre, detected by averaging the direction of the move of many salient points. In the middle slices in particular (those in which the heart gives more signal owing to greater overall area), the curves are entirely, or at least almost entirely, monotonic, which means that at each iteration the clockwise rotation continues. This can help show some otherwise-hidden information, but more datasets and rigorous testing on synthetic data for validation may be required as well.

QtOctave on Kubuntu with a
MATLAB window imported from Fedora over SSH

or the sake of cross-application/framework compatibility, one occasionally needs to alter code until it works everywhere, without the need to keep two (or more) separate codebases. This situation is far from ideal, but then again, not everything works like Java. When colleagues use a different platform and occasionally prefer proprietary software it is only fair to do some extra work catering for it.

In a matter of days or maybe a few weeks I will have some new code ready for release. I had already released this before it was ready for stable usage, partly because I had not set up a proper repository, so each release of code become a manual process. This may change soon.

In the early part of the day I ensured my programs work in both MATLAB and Octave. It was not as trivial as I had expected because there is certain functionality in Octave which MATLAB simply does not support. There are notes that I took to summarise and thus simplify this task in the future. The code now works in the latest MATLAB and also in Octave, with very minor differences between these two. The same set of files can be used for both, interchangeably.

Over the course of my work I have organised the data, documentation, experimental results, and code. All of these can be neatly packaged to provide the tools necessary for others to extend the program and use it to run more experiments. Following a very thorough survey of programs that are already available around the Web, it does not appear as though opportunities to reuse code were missed. At the moment, the program has an interface function with clearly-defined inputs and its output — in the form of images and video — is sent to a directory of choice at the end.

What would be nice to attempt next is implementation of other methods that assess similarity between regions, as means of selecting points more accurately. Making the placement of points diffeomorphic so that nothing gets folded or torn between the connecting curves that make up the contours would be essential too, especially for visualisation and 3-D reconstruction for example. At the moment it is possible to take point positions at each slice and each of the 20 iterations contained for that slice and then produce — using polygons — a sort of 3-D model of the heart. This, however, would require results to be of higher precision too.

uring the holidays I decided to see what else is out there which is already free/libre software like my own work, which thus can be merged for comparative purposes. It would be valuable to have applied to my work some comparison to existing tracking algorithms which deal with cardiac images. A decade-old paper from Osman et al. covers the very popular HARP and states in its abstract that it offers an “image processing technique for rapid analysis of tagged cardiac magnetic resonance image sequences.[...] Results from the new method are shown to compare very well with a previously validated tracking algorithm.” It’s not easy to gain access even to code samples of complete frameworks that facilitate benchmarking, so the search ascended to SourceForge. I uploaded some projects of mine to SourceForge about 8.5 years ago and hoped that others would do the same. A search in SourceForge for “cardiac” yields about a dozen results (at the time of writing), but there are empty entries in the code repositories where there ought to be complete projects. The Cardiac MR toolbox for Matlab, for instance, is an empty project:

[roy@blueberry cmr-toolbox]$ svn co
https://cmr-toolbox.svn.sourceforge.net/svnroot/cmr-toolbox cmr-toolbox
Checked out revision 0.
[roy@blueberry cmr-toolbox]$ ls
cmr-toolbox
[roy@blueberry cmr-toolbox]$ cd cmr-toolbox/
[roy@blueberry cmr-toolbox]$ ls
[roy@blueberry cmr-toolbox]$

The same goes for Neonatal Rat Cardiac Action Potential, but the Evaluation of Cardiac MR Segmentation project (all of them written for MATLAB but ought to be compatible with Octave) contains some LGPL-licensed code. Repository access (SVN):

svn co https://cardiac-mr.svn.sourceforge.net/svnroot/cardiac-mr cardiac-mr

Looking at MATLAB Central for some more existing code I find an old BSD-licensed function but almost nothing else when searching for “Cardiac”. Since the literature review phase and the subsequent finding of some data [1, 2, 3] there has been almost no room for code reuse, so I had to code everything from scratch. I will soon publish the code (GPLv3-licensed), but in a more scientific society more code would have already been out there for others to collaborate and build upon the work of others.

T HAS been a week or so since I last made a research-related post, so here is a quick update. I am currently coding some bits that can detect and measure rotation in the heart, including tangential/centrifugal components. The goal is to calculate the twist and also the scale changes separately, giving a figure indicative of each. The notions found in flow/vortex mathematics ought to enable this to be calculated from a set (or matrix) of points, each of which being a vector of directions around a central point. To quote Wikipedia on vortex: “A vortex (plural: vortices) is a spinning, often turbulent, flow of fluid. Any spiral motion with closed streamlines is vortex flow. The motion of the fluid swirling rapidly around a center is called a vortex. The speed and rate of rotation of the fluid in a free (irrotational) vortex are greatest at the center, and decrease progressively with distance from the center, whereas the speed of a forced (rotational) vortex is zero at the center and increases proportional to the distance from the center. Both types of vortices exhibit a pressure minimum at the center, though the pressure minimum in a free vortex is much lower.”

My implementation of this is simplistic as it merely uses an accumulator whose value increases for each point that moves in a given direction (e.g. for each clockwise arrow) and decreases for the opposite.

An issue we face here is that circular motion in the heart walls is far from trivial to see. A careful look at image sequences taken with about 20 frames for each cycle and each slice does not quite expose a ‘squeeze’ of the heart, not unless there is tagging of the image which also enables reconstruction of a higher quality. So, to calculate rotation of the sides based on just intensity is rather hard, unless there is something in the signal that can be detected. Generally, looking at the tracking typically carried out, there is hardly a tendency to pick up any traces of tangential motion and where it does exist it is not consistent. Assuming a direction is known and then estimated with a probabilistic model, there is room for improvement, maybe even a significant change in contrast. Different slices show different directions for the twist and it requires a look inside the heart too, in order to visually compare intensities and assume a rotation of some sort. I will post some images soon to illustrate this.

Additional code was completed to calculate and plot the centre of the points around the heart, based on the fitting of a circle to all the surrounding points (best match). At the end of each tracking sequence a plot if shown to give a statistical analysis of how points move around the walls and whether they move in and out throughout the cardiac cycle. The goal here is to, based on several cycle, find out if and how the algorithm can detect wall motion and quantify it. There is clearly a correlation to be found here.

Today’s addition (it’s a holiday, so lots of spare time for coding and also to read literature) will soon be uploaded along with more material, all of which will be shared not just for the sake of transparency. I’ll post results shortly.

As a side note, I’ve begun looking into the possibility of writing a book about Novell and another possibility I’m looking into is initiating a startup around the code I’ve been writing since 2003 to achieve something nobody achieved before, even with free/libre software (the whole stack). I’m currently doing cardiac analysis but still considering a situation where come back to a more CS-oriented work, at least when the existing contract is over. There are many projects on my mind and choosing just the best one/s is not easy. Then again, it’s good to have possibilities and I’m still in my twenties, so there is no pressure.