lines=10
degrees=180

Now, let us generate some linear, equally-spaced points:

t_map = linspace(0,lines*pi*2,lines*degrees*2);

What we have here is the 2 for 360 degrees, which may depend on what one tries to achieve. For the more complex case shown later, this will be essential. Now, let’s do the sine/cosine magic:

x_map = t_map.*cos(t_map);
y_map = t_map.*sin(t_map);

This can be plotted with plot(x_map, y_map), but let’s do something more interesting by assigning colour to the sample points and then plotting them as dense dots. The following would work:

flat=zeros(1000,1000);
  for ll=(size(x_map,2)/2):-1:1
    flat(floor(x_map(ll*2))'+500,floor(y_map(ll*2))'+500)=1
  end
imshow(flat)

The values here are rather arbitrary and can be used for demonstrative purposes. The problem itself seems to be commonly recurring, thus the need for a blog post. Different colours can be assigned to sample points, which achieves something like the following:

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.

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.

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.

Before we get to the essence of programming with the toolboxes as well as basic syntax, there ought to be a proper introduction to each component in QtOctave, which simplifies Octave by wrapping it with a GUI.

Please bear in mind that this was done on the spot without rehearsals and future tutorials will hopefully be more organised.

In later parts I shall introduce readers to QtOctave, as well. I currently experiment with all sorts of video capturing/editing programs and I also upload old videos like this one.

Today I present free/libre software called QtOctave, which is a graphical front end to Octave and it uses Qt, as the name suggests. Qt is cross platform, so as expected it runs on Windows too. Without further ado, let’s take an overview of what QtOctave looks like. I typically put QtOctave on my eighth workspace in KDE, which helps me remember where to find it. Here is my workspace 8 (screenshot, click to magnify).

This picture may be daunting, but QtOctave does a good job hiding lot of the functionality under menus, which reduces clutter. QtOctave uses Octave (CLI) as its engine, but it provides a friendlier face to it. Let’s break down this picture and explain what each component does, in turn.

Menu

The main menu contains many of the basic functions one ought to expect. By “functions” what I mean is either functionality like opening files or mathematical functions that are commonly used. Many options there control the appearance of the GUI, whose core component of the command line containing the core, Octave. QtOctave wraps it up nicely and provides tools to work with/around it.

Variables

Octave exposes names and corresponding values of variables it holds, but only upon demand. How about having a GUI component to keep track of these and display this information all the time. You want it? You got it:

Commands and Dynamic Help

The command pane is a companion tool which helps keep track of recently-used commands and makes these conveniently available. In my case, I added the “Dynamic Help” component, to help show what commands are available as soon as I start typing. The contents in the example below show what appears in the window as soon as I began typing “plot”. The namespace of commands can be highly populated if many modules are used (in session’s path), so this is a good way to keep track without looking elsewhere. Bash has a similar functionality which it makes available via the “Tab” key.

Directories

Directories and files are sometimes easier to approach and navigate though when they are quickly accessible through the main GUI. This has use in all sorts of circumstances as drag-and-drop functionality is broadly supported.

Terminal

In the main body of the program there is the terminal section (or other components, if one chooses to make them available there). Show below is an example of basic interaction with Octave.

CLI

The command-line interface is an integral part of the above and it supports up/down arrow key for use of commands history.

Editor Menu

This editor can be made part of the main windows, but it does not have to be. I personally choose to make it an external window on a second monitor where it offers a lot of viewing space. The menu has all one ought to expect to find in a standard text editor, but it also contains program-specific buttons like execution and debugging.

Code

Here is a simple code example. The fonts that I use do not look good because I favour monospace, which helps indentation and other tasks where each character is treated as equal.

Breakpoint

Here is another example of code (further down from the top). This helps show how breakpoints are represented in the editor. Together with the variables panel this provides an excellent environment for debugging, so the editor is definitely not detached from the core components; It’s custom-made for it.

More Components

There is a lot more under the menus, e.g. package management (see the image below). But that’s a subject for another day.

If you like what you see in QtOctave, then consider giving Octave a look. Both Octave and QtOctave are in the *Ubuntu and Fedora repositories, so they only take a moment to install.