HAD worries that GNU Octave would not support some of the advanced graphing functionality of MATLAB, but with the help of tools like gnuplot, Octave stays on par in this game (bar some OpenGL enhancements). Much to my surprise, the 3-D charting and graphing software in GNU Octave. Here are some visualisations of cardiac images I work with.

VERY program has areas worth improving. GNU Octave is no exception and I’ve been trying to submit bug reports (via Savannah) only to find that it has just been compromised (therefore temporarily down), so in the mean time, here is the gist of issues that I found so far.

While Octave is proving to be perfectly compatible with all the basic functions in MATLAB it also proves to be ‘compatible’ with MATLAB’s weight problem. Octave’s core is generally light and much faster to start than MATLAB’s, but when it opens child windows (e.g. ImageMagick), then it suffers a limitation due to the maximum number of allowed windows. For some reason, resources appear not to be recovered when images are closed (it may be leaking memory too), so X.org limits are sooner or later reached. This is a bizarre issue that’s hard to reproduce (in Fedora I cannot even open such windows [1, 2, 3]). But anyway, that’s mostly a performance issue. Closing an Octave session also helps as once it’s restarted windows are numbered from 1 upwards once again.

When it comes to vertical listing of files the UNIX way, there is something a little unexpected in Octave’s implementation of it (which may or may not be compatible with other software). The “ls” function, unless it gets invoked with specific options, will pick its data horizontally rather than vertically from standard I/O in the system call. To illustrate this point consider the following:

>>> ls('*.bmp')
MR000192.bmp  MR000200.bmp  MR000208.bmp  MR000216.bmp	MR000224.bmp
MR000193.bmp  MR000201.bmp  MR000209.bmp  MR000217.bmp	MR000225.bmp
MR000194.bmp  MR000202.bmp  MR000210.bmp  MR000218.bmp	MR000226.bmp
MR000195.bmp  MR000203.bmp  MR000211.bmp  MR000219.bmp	MR000227.bmp
MR000196.bmp  MR000204.bmp  MR000212.bmp  MR000220.bmp
MR000197.bmp  MR000205.bmp  MR000213.bmp  MR000221.bmp
MR000198.bmp  MR000206.bmp  MR000214.bmp  MR000222.bmp
MR000199.bmp  MR000207.bmp  MR000215.bmp  MR000223.bmp
>>> a=ls('*.bmp')
a =

MR000192.bmp
MR000200.bmp
MR000208.bmp
MR000216.bmp
MR000224.bmp
MR000193.bmp
MR000201.bmp
MR000209.bmp
MR000217.bmp
MR000225.bmp
MR000194.bmp
MR000202.bmp
MR000210.bmp
MR000218.bmp
MR000226.bmp
MR000195.bmp
MR000203.bmp
MR000211.bmp
MR000219.bmp
MR000227.bmp
MR000196.bmp
MR000204.bmp
MR000212.bmp
MR000220.bmp
MR000197.bmp
MR000205.bmp
MR000213.bmp
MR000221.bmp
MR000198.bmp
MR000206.bmp
MR000214.bmp
MR000222.bmp
MR000199.bmp
MR000207.bmp
MR000215.bmp
MR000223.bmp

The arrangement is supposed to be on a column-by-column basis (the real ordering), but in the case of an assignment the data gets flattened in a way which does not preserve the original file ordering (alpha-numeric in this case).

By all means move from MATLAB to GNU Octave because these issues are not critical and some may be matters of convenience rather than practicality. If anything, this proves that Octave has only minor creases and no major deficiencies. That’s all I could find after heavy usage.

HIS MORNING I spent some time helping others make the same migration which happily enough I made over a month ago (so far, so good!). It’s a migration from proprietary software (and BSA backer) to free-as-in-freedom software, which also happens to be a GNU project. It helps that the project is cross-platform because unlike myself and many others, there are still a lot more Windows users out there. Moving them to Free software on Windows is an essential step which removes barriers when they swap the whole platform. GNU works better on GNU/Linux than on Windows, for obvious reasons. Although it’s a matter of opinion, under KDE QtOctave looks better than MATLAB, as well.

Installing GNU Octave in GNU/Linux is very simple because it is packaged in the repositories of *buntu and Fedora. These are the two distributions where I have checked to verify this although I encountered bumps along the way in Fedora [1, 2, 3]. It is not entirely Fedora’s fault and it’s a known issue that affects many people who are Octave users.

The packages one need to fetch via yum/apt-get (or graphical front ends like Synaptic and KPackageKit) are “Octave” and “QtOctave”. They are not large packages and they should be able to fetch dependencies that are being determined and resolved by the packager/packaging process. Once these are installed, an icon will typically show up somewhere along/inside the menus. If not, run qtoctave from the command line and ensure it gets access to the octave executable (it usually works perfectly ‘out of the box’ based on my experience on multiple boxes). Yes, this should work by default without user intervention, but in case it does not, ensure octave is properly installed and put in the path.

I am unfortunate enough to have faced Windows for about half an hour just now (not my computer) because in some cases, for collaboration purposes, computers that run Windows also need to have Octave installed on them, along with QtOctave for improved ease of use. The way to get that installed is a lot more complex and time consuming because Windows does not have packages managers (this is one of the areas where GNU/Linux is ahead of its competition). In any case, here is how one should install everything and get it set up

Navigate to the downloads page of Octave. At the time of writing (and this may change in the future) there is a native build for Windows, which seems to work without any issues in Windows XP and probably predecessors too. Scroll down to part which says: “The Octave Forge project hosts a native Windows binary distribution of Octave built with the MinGW compiler.”

This leads to Octave-Forge. Near the top of the page there is a “Windows installer (Octave and Octave-Forge)” listed. Now, download the file which is an executable (.exe) and run that. Follow the simple process of installation until completion and at the end ensure that Octave is installed and then listed among the programs in the Windows “Start” (now just Windows logo) menu. The main program is just called “Octave”. When it’s executed it offers a command line prompt which is the Octave interpreter. If everything works fine at this stage, then Octave runs properly and it is time to install the graphical wrapper, QtOctave.

Qt is a cross-platform graphical toolkit and a front end for Octave was written with it not so long ago. The main build is for GNU/Linux with tendency towards KDE, but there is also a Windows port and the one which works best can currently be found in outsch.org. There is a ZIP archive in there, so download it with caution (it is not an official source). Finally, uncompress the file and install it in a suitable location of choice on your hard-drive partition (e.g. C:). When all the files are extracted from the ZIP archive find the qtoctave executable (qtoctave.exe) under the directory containing the DLL files and the other binaries. If necessary, create a convenient shortcut to this file. Unlike UNIX-type environments, paths in Windows are not quite as universal, so QtOctave may not have anything defined regarding the location of the octave executable. Depending on where it’s installed, it may need to be entered manually, otherwise QtOctave will not be able to access the very core and engine of Octave. If that’s the case, go to the “Config” menu (top menu), then “general configuration” (menu item), then “Octave”, “Octave path”. Put in the text field the full path to the Octave executable where you had it installed earlier. This ensures QtOctave knows where to find it. Restart QtOctave (for settings changes to take effect) and once the program can detect the executable ensure it can provide a command prompt for .m files to be run or for commands to be entered manually. If needed, run a basic function like plot just to ensure that graphical units of Octave are also fully supported and installed without any conflicts. QtOctave comes with several units including an editor and it integrates quite well, including drag-and-drop support.

The point of this whole exercise is to liberate users whose personal programs that they write are stuck in the “MATLAB trap”, so to speak (like the old “Java trap”).

If you are interested in converting fellow staff and their students to Octave, remember that it suits an educational environment much better as it encourages sharing and collaborating, not asking for permissions, paying heavy fees/fines, and begging developers to fix bugs rather than have access to the source code, which in turn enables participation. Additionally, most of the basic functions are truly compatible with MATLAB’s and the lack of JIT optimisation, for example, should not matter much in an educational setting. Not many people create MATLAB GUIs either, so there is hardly a need for such advanced functionality. At a later date I hope to make some screencasts about Octave.

EDORA 14 is an adorable distribution, at least on the KDE (4.5) side of it. I only had problems in the repository and ones that were not truly Fedora’s fault. Image-related functions gave me a hard time in Fedora because of a known conflict and version numbers. It was not simple to resolve even after hours of trying. I consider myself to be an expert user (not guru) and unless I start compiling from source code as I did 5 years ago, Octave will be a challenge to use. Over on a Kubuntu machine I had no such issues. As the pictures below show, things worked perfectly well without any effort at all. Say what you will about Ubuntu GNU/Linux, but it does tend to work rather well.

My goal is to do my entire daytime job under a true GNU/Linux/KDE experience with Gnash, no proprietary codecs, and even Konqueror (KIO/kio and sftp/ssh support make it indispensable) as the only Web browser along with Okular, LyX (not OpenOffice.org), and other great Qt/KDE SC programs. There are some limitations in use, but there are usually ways around those (although never as easy to install as Firefox extensions for example). In addition, advances in the Web itself can prove a tad tricky. The nature of the World Wide Web and the Web browsers which change over time is not predictable, so presentations that worked alright with background pictures in the past no longer appear correctly, unless the code is redone (I still use S5 for presentations. It is an excellent presentation tool I’ve used happily for over half a decade).

The main issue I’ve had with Fedora is to do with Octave, which I hope to replace MATLAB with. MATLAB was the last bit of proprietary software I was still using on GNU/Linux (since I began using GNU/Linux exclusively at work, around 7-8 years ago). The problem is not at all exposure to Windows or Mac OS; I never need those, but proprietary software in general is the problem here because of lock-in (practicality), which makes it not a purely philosophical argument.

After wasting many hours trying to get Octave to work the way I want and need it to work under Fedora 14 I decided to just virtualise another distribution under Fedora. The first thing which occurred to me is that VirtualBox was not available (see below).

In the mean time I also decided to give Mint a go for the first time (I was curious after doing a special audiocast about it). That was a smooth experience luckily. Debian makes it daunting for one to download, so after a couple of minutes I left their Web site. Here’s Mint’s less-than-perfect download experience, assuming one particular route:

Fedora makes it a lot more user-friendly when one downloads an ISO. There are usability issues here as most people cannot tell the difference between the different files.

To run it I needed a hypervisor and here is what Fedora had under the virtualisation category (descriptions would help enw users):

In summary, it is a bit of a shame that one needs to have those barriers; using Octave is not a case of using basic applications, but I was hopeful that Fedora would make it easy. I still reject MATLAB at all costs and I avoid installing it because Octave is doing almost everything that I need. In a future post I hope to write about Linux Mint.

BOUT three weeks ago I decided to go back to working with Fedora. This distribution served me well over the years, especially in distributed clusters. Fedora 14 looked very promising and it still is, but there are creases that are hard to undo and to hide. In order for matters to improve I will post a quick rant and hope that someone, somewhere will help address the issue that I’ve already reported (I also submit bug reports whenever that’s possible).

My main problem is package specific. The problem was first mentioned here. Thanks to a blog comment from Rahul I was made aware of fairly trustworthy repositories where packagers offer alternative packages. I soon found this newer build of Octave (needed to manually uninstall the existing one as it does not support updating existing packages). It is one of those unsigned packages, which require the user to jump through some hoops. The changelog looked promising because the latest entry mentioned exactly the bug that I was suffering from (many other people must be suffering from it too):

* Sun Feb 28 2010 Alex Lancaster <alexlan[AT]fedoraproject org> – 6:3.2.4-3
- Temporarily disable %check to enable build to complete and ensure upgrade path works. This works around a crash in the imread.m image test script, this may be the same problem as described by upstream here:

https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-January/014891.html

So, here goes:

[root@blueberry roy]# yum remove octave
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package octave.i686 6:3.2.4-3.fc14 set to be erased
--> Processing Dependency: libcruft.so for package: pfstools-octave-1.8.1-1.fc14.2.i686
--> Processing Dependency: libcruft.so for package: octave-forge-20090607-17.fc14.i686
--> Processing Dependency: liboctave.so for package: octave-forge-20090607-17.fc14.i686
--> Processing Dependency: liboctave.so for package: pfstools-octave-1.8.1-1.fc14.2.i686
--> Processing Dependency: liboctave.so for package: plplot-octave-5.9.6-5.fc14.i686
--> Processing Dependency: liboctinterp.so for package: octave-forge-20090607-17.fc14.i686
--> Processing Dependency: liboctinterp.so for package: pfstools-octave-1.8.1-1.fc14.2.i686
--> Processing Dependency: liboctinterp.so for package: plplot-octave-5.9.6-5.fc14.i686
--> Processing Dependency: octave(api) = api-v37 for package: octave-forge-20090607-17.fc14.i686
--> Processing Dependency: octave(api) = api-v37 for package: plplot-octave-5.9.6-5.fc14.i686
--> Processing Dependency: octave >= 3.2.0 for package: qtoctave-0.9.1-2.fc14.i686
--> Processing Dependency: octave for package: plplot-octave-5.9.6-5.fc14.i686
--> Processing Dependency: octave = 6:3.2.4-3.fc14 for package: 6:octave-devel-3.2.4-3.fc14.i686
--> Running transaction check
---> Package octave-devel.i686 6:3.2.4-3.fc14 set to be erased
---> Package octave-forge.i686 0:20090607-17.fc14 set to be erased
---> Package pfstools-octave.i686 0:1.8.1-1.fc14.2 set to be erased
---> Package plplot-octave.i686 0:5.9.6-5.fc14 set to be erased
---> Package qtoctave.i686 0:0.9.1-2.fc14 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package                     Arch             Version                        Repository           Size
=======================================================================================================
Removing:
 octave                      i686             6:3.2.4-3.fc14                 @fedora              32 M
Removing for dependencies:
 octave-devel                i686             6:3.2.4-3.fc14                 @fedora             2.5 M
 octave-forge                i686             20090607-17.fc14               @fedora              39 M
 pfstools-octave             i686             1.8.1-1.fc14.2                 @fedora             254 k
 plplot-octave               i686             5.9.6-5.fc14                   @fedora             1.3 M
 qtoctave                    i686             0.9.1-2.fc14                   @fedora             2.9 M

Transaction Summary
=======================================================================================================
Remove        6 Package(s)

Installed size: 78 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing        : pfstools-octave-1.8.1-1.fc14.2.i686                                             1/6 
  Erasing        : qtoctave-0.9.1-2.fc14.i686                                                      2/6 
  Erasing        : octave-forge-20090607-17.fc14.i686                                              3/6 
  Erasing        : plplot-octave-5.9.6-5.fc14.i686                                                 4/6 
  Erasing        : 6:octave-devel-3.2.4-3.fc14.i686                                                5/6 
  Erasing        : 6:octave-3.2.4-3.fc14.i686                                                      6/6 

Removed:
  octave.i686 6:3.2.4-3.fc14                                                                           

Dependency Removed:
  octave-devel.i686 6:3.2.4-3.fc14                   octave-forge.i686 0:20090607-17.fc14             
  pfstools-octave.i686 0:1.8.1-1.fc14.2              plplot-octave.i686 0:5.9.6-5.fc14                
  qtoctave.i686 0:0.9.1-2.fc14                      

Complete!

This can be done from the GUI as well. But it’s not working. The bug still exists and prevails after the new package gets installed. To make matters worse, for some reason, yum just disallows installing unsigned packages. It does not even produce a warning with an opt-out/force option. It’s very stubborn, so I had to use the GUI. Then, running the program (the new build) showed that:

octave:4> imshow('Konqueror.jpg')
octave: magick/semaphore.c:525: LockSemaphoreInfo: Assertion `semaphore_info != (SemaphoreInfo *) ((void *)0)' failed.
panic: Aborted -- stopping myself...
Aborted (core dumped)
[root@blueberry roy]# qtoctave
[main()] Error loading the QT Translation file for locale 'en_US'.
[main()] Error loading the translation file for locale 'en_US'. Not found in /usr/share/qtoctave/lang 
[Main::Main] Building commands list.

[Main::Main] Commands list builded.
QWidget::setMinimumSize: (/QMdi::ControlLabel) Negative sizes (-1,-1) are not possible
[OctaveConnection::startOctave] Octave path: octave
[OctaveConnection::startOctave] Octave version: 3.2.4 (3.2.4)
[OctaveConnection::startOctave] Starting octave: "octave"  --eval "PS1('octave:\#>');PS2('octave:\#+>');addpath('/usr/share/qtoctave/scripts_octave/')"  --persist --no-history -i 
[OctaveConnection::startOctave] Octave running
klauncher(2168) kdemain: No DBUS session-bus found. Check if you have started the DBUS server. 
kdeinit4: Communication error with launcher. Exiting!
Segmentation fault (core dumped)

Oh, wonderful. Well, eventually I found a way to run qtoctave again. Checking the version/build names again:

[root@blueberry roy]# yum remove octave
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package octave.i686 6:3.2.4-3.el6 set to be erased
--> Processing Dependency: octave >= 3.2.0 for package: qtoctave-0.9.1-2.fc14.i686
--> Processing Dependency: octave = 6:3.2.4-3.el6 for package: 6:octave-devel-3.2.4-3.el6.i686
--> Running transaction check
---> Package octave-devel.i686 6:3.2.4-3.el6 set to be erased
---> Package qtoctave.i686 0:0.9.1-2.fc14 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package            Arch       Version              Repository                                    Size
=======================================================================================================
Removing:
 octave             i686       6:3.2.4-3.el6        @/2067.0.octave-3.2.4-3.el6.i686              32 M
Removing for dependencies:
 octave-devel       i686       6:3.2.4-3.el6        @/2220.0.octave-devel-3.2.4-3.el6.i686       2.5 M
 qtoctave           i686       0.9.1-2.fc14         @fedora                                      2.9 M

Transaction Summary
=======================================================================================================
Remove        3 Package(s)

Installed size: 37 M

Yes, even octave-3.2.4-3.el6.i686 has this same bug, so what gives? In Kubuntu 10.04 there is no such problem, not in the packaged version of Octave. Having to go through less official routes to unsigned packages is daunting enough for most people; finding out that it still does not work is even a lot worse. The problem here is not really Fedora but lack of coordination between octave and the magick folks. qtoctave handles this admirably well by restarting octave and not just letting the entire program crash. But still, having wasted several hours on this first looking for bugs in my code and then playing with packages rather than doing research (realising that my code was not the problem), I am left a bit bitter about my Fedora 14 experience. It is not as though I have been too lazy trying to resolve this and for the time being it seems like I will do more of my work on my Kubuntu box. It happens to have done packaging of Octave more successfully (at least that older version).

Update: not even stepping back to older versions of ImageMagic has worked and yum had the same limitations because the packages were unsigned.

[root@blueberry roy]# yum remove ImageMagick
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package ImageMagick.i686 0:6.6.4.1-14.fc14.1 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package                  Arch              Version                         Repository            Size
=======================================================================================================
Removing:
 ImageMagick              i686              6.6.4.1-14.fc14.1               @fedora              6.5 M

Transaction Summary
=======================================================================================================
Remove        1 Package(s)

Installed size: 6.5 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing        : ImageMagick-6.6.4.1-14.fc14.1.i686                                              1/1 

Removed:
  ImageMagick.i686 0:6.6.4.1-14.fc14.1                                                                 

Complete!

Then installing the older version via the GUI. Still the same issue.

[root@blueberry roy]# yum remove ImageMagick
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package ImageMagick.i686 0:6.6.0.2-8.fc14 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package          Arch      Version                Repository                                     Size
=======================================================================================================
Removing:
 ImageMagick      i686      6.6.0.2-8.fc14         @/2494.0.ImageMagick-6.6.0.2-8.fc14.i686      6.3 M

Transaction Summary
=======================================================================================================
Remove        1 Package(s)

Installed size: 6.3 M
Is this ok [y/N]: n
Exiting on user Command
Complete!
[root@blueberry roy]# octave
GNU Octave, version 3.2.4
Copyright (C) 2009 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.

Octave was configured for "i386-redhat-linux-gnu".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html

Report bugs to  (but first, please read
http://www.octave.org/bugs.html to learn how to write a helpful report).

For information about changes from previous versions, type `news'.

octave:1> imshow('in')
octave: magick/semaphore.c:525: LockSemaphoreInfo: Assertion `semaphore_info != (SemaphoreInfo *) ((void *)0)' failed.
panic: Aborted -- stopping myself...
Aborted (core dumped)

I’m giving up. Maybe I just need to go to far older versions for compatibility, but I tried the oldest ones built for Fedora 14.

‘ve been an Octave user on several machines and everything worked perfectly well until Fedora 14, which has a newer version of the software and thus a serious conflict of incompatible libraries. For many image loaders the following type of error is shown just before Octave crashes:

octave: magick/semaphore.c:525: LockSemaphoreInfo: Assertion `semaphore_info !=
 (SemaphoreInfo *) ((void *)0)' failed.
panic: Aborted -- stopping myself...

Do not waste time trying to find a bug in the code of an Octave program. It is a known issue that GraphicsMagick and Octave are having this year.

Somebody posted debugging information and John W. Eaton responded with a link to this thread from January. The best solution is probably to escape to previous versions for the time being.

HIS POST is part of a series that I do about my incursions moving from MATLAB to Octave, which has so far been a pleasant experience. QtOctave looks better and is easier to install than MATLAB (on GNU/Linux with KDE at least). For those who experienced being a customer/user of MATLAB, it can really be a pain in the butt, licence-wise. The parent company, MathWorks, can be very aggressive when it comes to licensing (it pays the BSA after all), so people are kept tied to particular IP addresses and must renew something to remove artificial limitations. Moreover, the toolboxes that MATLAB sells separately are a case of artificial scarcity and they can be expensive. Octave resolves much of this by centralising a lot of software as shown in the screenshots above (also separating free/libre from proprietary). Rather than waste time with paperwork and bank transactions, any QtOctave user can simply and quickly click away to receive anything s/he desires. It’s truly like a candy store.

Why ever go through the trouble presented by MATLAB, Maple, Mathematica, or IDL? Some people may need these for collaboration and consistency (as in monoculture), but it is better to start without any proprietary software dependency.

I will report on more aspects of this comparison as I go along. At the moment I’m exploring the GPLv3-licensed BioSig project, which allows me to deal with DICOM datasets of the heart (images acquired just recently — ones that I picked up at the hospital yesterday). Speaking of which, I’ve learned that some scanning machines that traditionally used Windows are now moving to GNU/Linux. How exciting times are coming…