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.

ESTERDAY I encountered my first major setback in Octave for Kubuntu. It was a bug, not a missing feature. It involved an outside library again. I tried installing a newer version of gnuplot (installing the latest one by compiling the source code), but this did not resolve the issue. All in all, over an hour was spent on it, first assuming that I was coding wrongly and later realising that the issue was upstream (there are many more threads like this and they dominate the discussion on the matter). Applying the patch manually would only be a short-term solution as it was already submitted for inclusion in future releases, so for the time being, where this function is needed, I will reluctantly be testing the code under MATLAB (for which I have an academic licence that everyone gets whether they want to or not). It was rather depressing to use MATLAB for a few hours yesterday. Compatibility will be assured again when the little issue (fixable with just a line or a few) is addressed also in the binaries offered by GNU/Linux distributions. Apart from that I’m having Fedora-Octave-ImageMagick compatibility issues [1, 2], which help not at all.

My overall experience with Octave is pleasant and it remains by far the primary choice for image analysis. But for others who insist on using MATLAB I must ensure cross-compatibility, thus the following (under Fedora):

The image shows the interface which now precedes the tracking phase. Points can be placed by the user with text guidance in the console. The interfaces were also improved to separate between rectangular, circular, and manual placements.

Here is an example image without the interface.

Direct download as Ogg (1:19:35, 23.8 MB) | Direct download as MP3 (36.4 MB)

Summary: First show for 2011 speaks about consoles, sales, Android, software patents, and an outlook for the new year

THE FIRST 2011 audiocast is out. The show is getting a new site very soon and OpenBytes publishes the show notes for everybody. Today’s show concentrates on Microsoft failures, criticism of statistics in the media or the recording industry, and finally some 2011 predications about Android’s success and Steve Ballmer’s departure.

We hope you will join us for future shows and consider subscribing to the show via the RSS feed. You can also visit our archives for past shows. If you have an Identi.ca account, consider subscribing to TechBytes in order to keep up to date.

As embedded (HTML5):

Download:

(There is also an MP3 version)

FEW DAYS ago I wrote about some plans for the coming year. One promise that I managed to fulfill was the revival of this Web log, which was started way back in 2004. I post less in Techrights these days because a lot of the content is being put in the audiocast and because there are some moving goalposts for any freedom fighter. Microsoft, for example, is losing its place in the world of technology (the media trends confirm this) and issues relating to free speech (including protests) and free Internet (communication) help show that our society is being closed down. It’s at times like these that speeches like the following one ought to be watched and shared.

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.

HIS fourth video in tonight’s series looks more closely at some of the different components of QtOctave.