Making My Latest Program (Cardiomat) MD-Ready
By sacrificing the comfort of the command-line interface (CLI)
ver the past few days I’ve been repackaging one of my programs such that it becomes easier to install and more user-friendly once installed. The program works in both MATLAB (proprietary software) and Octave (Free/libre software) and it now has a GUI and a name, which I arbitrarily and hastily named “Cardiomat”. Directory selection dialogues and some other user interface features are missing from Octave, so the code has become filled with some conditional statements so that it serves each user, no matter the choice of interpreters (proprietary or Free).
There are mixed feelings whenever time is dedicated to making a GUI. When a program is scriptable in the command-line sense, then it is a lot more flexible to the user and piping I/O is a lot simpler. To a new user, however, this can prove baffling. The GUI and splash screen may be necessary for medical doctors (and radiologists) to use, but it removes a lot of the power of the program, which can really end up incorporating both. When I created a 3-D othello game I made a command-line option available too as this enabled me to run simulations (e.g. game engines playing against one another) overnight, saving the results to files. With a GUI-only approach this is not possible. All my other scientific programs also had CLI interfaces which overrode or replaced the GUI. The conclusion of this whole matter is that no matter how much people like to vilify CLI ‘hackers’, those who embrace the CLI are usually in a position of advantage, especially where research is concerned. The Windows mindset requires people to repeatedly run tasks from GUIs, whereas the use of the CLI can automate all of this and provide more flexibility (I use vi as the editor for programming, still). The GUI is an area where MATLAB and Octave diverge somewhat, so here too there is a problem of universaility breaking. When one strictly sticks to the command line, there are universal interfaces and more a unified language, which tend to break if abstraction is taken that involves graphical interfaces (may also be platform dependent).
Anyway, the program can now handle anything including .bmp files and DICOM, with ginput handling image coordinate extraction (albeit bugs in Octave prevent it from working properly) and with a CLI option/fallback the program still performs the tasks it needs to. I will upload all the final source code shortly (I am the only developer, so there has been no repository yet). In future posts I am going to write about my next project and my next program, which will deal with 3-D face recognition (a departure from my current work on medical, intra-body imaging).
I’ve not been writing about my programming work for quite a few years (my detractors love to dig and smear me for my coding or my job), but I may try to carry on blogging about it. Here are some new screenshots:






Filed under: 


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.
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
eople who say that nothing can replace Photoshop and nothing can replace Microsoft Office simply forget that the functionality they must be implicily referring to is hardly used by anyone among the entire userbase. As pointed out in the 











oday I implemented circular arrangement of landmark points for the algorithm to identify something approximate/similar to the shape of the heart and then place a given number of points around there. In addition, a boundary is shown by sampling between those points, which gives a contour, with or without arrows on top of it. I will upload the code shortly (needs tidying up).

ather than use the
am not always a pessimist, but I do believe that in order to make positive progress we must concentrare on the illnesses and try to cure them. This is why most of my work at present revolves around advancing collaborative platforms like GNU/Linux (no tyranny on people’s desktops and servers). Sure, companies like Google and IBM make a lot of money out of the platform, but it does not take away from anyone else’s ability to use the same code. Overall, it leads to solidarity. Just watch how many companies jointly develop Linux (kernel space), including giants like AMD, Intel, and NVIDIA, which must play nice with the free graphics stack. A decade ago it was hardly conceivable, but here we are today with some truly powerful applications for GNU/Linux (some are still proprietary, especially games). It is exciting to see desktop environments like the K Desktop Environment (KDE SC) and GNOME desktop becoming highly competitive with whatever else is out there, proprietary included. LXDE and Xfce continue to serve an important role, especially in less capable PCs that rely on light-weight distributions. New releases of GNU/Linux come at a pace of about one per day and diversity continues to exist, with popular branches like the Mandrake/Mandriva family (with several derivatives), the Red Hat family (including Fedora), and the Debian family, which notably includes Ubuntu for the desktops (it has a huge number of variants).