Introduction About Site Map

XML
RSS 2 Feed RSS 2 Feed
Navigation

Main Page | Blog Index

Archive for the ‘Programming’ Category

PageRank 7

Finally, for the first time ever, I have gotten a site whose front page is PageRank 7. That would be Techrights. I didn’t see it coming and this is part of a group effort, so it’s a victory for many of us who worked on it for years. I cannot think of another Linux-oriented site which has PageRank 7 or higher. It’s an important milestone for sure, even if it’s mostly symbolic.

Today was generally a great day and I met an old friend who is now a boxer. Did some programming, ran successful experiments, and some of the changes are compiled without an issue, removing the zlib dependency from Cyrus. Now is the time to have these tested and the plan is to use the existing interfaces with some test data and detect mis-correspondence in CRC polynomials. Tomorrow, heavy blogging will resume and maybe a trip to London will wait until Monday.

Outperforming PCA, Revisiting MATLAB

Post-denoising small

I currently work on a very fascinating project which deals with 3-D face recognition, as already stated back in January. Progress has been noticeable recently (easier to get coding done when the Internet is mostly unavailable due to Bad Telecom [1, 2, 3]) and the accompanying text is now about 50 pages long.

A few observations about MATLAB: the programming framework has not really developed much since 2003. It’s either quite stagnant or improved only in unseen places. I did not forget how to develop a GUI environment very rapidly.

A few observations about PCA: the method is a little antiquated and it can probably be outperformed by more problem-specific implementations of algorithms we explore.

A few observations about Bad Telecom (or Bastards Telecom, although some people view the word bastard as too strong): they only ever serve the customer properly if he/she becomes a threat to the reputation of the business. It is sad that customers must be seen as a risk before they can actually get progress made.

Fedora, Importance of GNU/Linux Competition, and Technological Freedom

FEDORA 11 is a fine distribution of GNU/Linux, but my session got stuck (frozen) today. Generally, scheduling on the desktop in this out-of-date operating system is somewhat deficient. Windows sometimes do not respond for a period of several seconds. The bug where a text selection cursor is made permanently visible and allows no real interaction with any applications kicked in… againtoday. It happens quite rarely with other distributions and there’s an escape route out of it, e.g. if the terminate signal can be sent to the application causing it, assuming it can be identified. But not this time though. Bearing in mind that it’s not the very latest version of Fedora and having used the fourteenth release since it was made available (even installed it for others), it does seem fair to say that for a smooth experience on the desktop, one is still better off going with the Debian family. Mandriva (predominantly but not strictly RPM-based) has been very good too, probably a lot better than Fedora.

The problems with Fedora are not really caused by adherence to freedom. Some creases and bugs, however, might not be addressed early enough because Fedora’s adherence to freedom (not strict adherence, but better than Ubuntu’s for example) limits the extent of its userbase, which in turn reduces the incentive Red Hat has to concentrate on the desktop side of things.

I have been working with Fedora 11 since last Friday (just waiting for my home computers to get back online with the new line activated) and as much as I try to love Fedora, I cannot help feeling that Kubuntu and Ubuntu have been giving me less hassle. Deep inside I wanted to declare that Fedora was better, but the experiences simply suggest that any such claim would be wishful thinking, even deceptive. The problem is that Canonical was made quite arrogant (hello Hubris!), which harms Ubuntu on technical and communal grounds alike. Canonical could use more competition.

It may be true that Linux in the mainstream is all about Android, Google, Ubuntu, mainframes, and Red Hat Enterprise Linux these days. That’s fine. As long as Fedora uses and reuses the same pertinent packages, there is no risk of Fedora truly falling behind. The wonder of Free software is, as long as one is allowed to copy the competition or branch out of it, unfair advantage is harder to gain. Canonical and Google have both attempted to produce “added value” (or enhancement) which is hard to emulate, replicate, or even get involved in. They are using some very vendor-specific code, which changes the balance of control not just with copyright assignment. It’s not progress and it is usually counter-productive.

Next week I will resume GNU/Linux advocacy and do a lot less programming (below is a new screenshot of the application I have been developing, but it’s unfortunate and regrettable that the code depends on a proprietary framework) and there is a lot of thinking to be done regarding strategy. Generally speaking, the world’s population loses control over technology at a very rapid pace* and software freedom is no longer the only freedom worth pursuing by a developer with passion for humanism. The head of the Free Software Foundation (FSF) has just stepped down and it is hard to blame him; maybe he too reached similar dilemmas and came to realisations that software freedom is not enough. Collaboration too is crucial (GPL encourages it), not to mention education in general.

Expressions GUI
____
* I spent half an hour this morning chatting with a lady in her 70s. She too — not too surprisingly — feels as though mobile phones are a burden rather than a blessing. In general, she is also concerned about today’s society which lacks face-to-face interaction and intimidates her generation that’s not at all accustomed to a technological control grid. Free/libre software is being used a lot in this context (primarily for companies to bring their user-hostile proprietary layer to market immediately), not as much is being produced though. If technology is not built to provide the user some more control, then it usually tries to control the user. But people are not made sufficiently aware of it, unless the FSF speaks out, as it recently did against Android.

Developing With Fedora 11

GMDS/PCA

FEDORA 14 was a bit of a mixed bag, but it was definitely an improvement compared to previous versions. I’ve used it since it was released (and blogged quite a lot about it). At the moment I use an older version:

bash-4.0$ uname -a
Linux [XXXXX] 2.6.30.10-105.2.23.fc11.i686.PAE #1 SMP
Thu Feb 11 07:05:37 UTC 2010 i686 i686 i386 GNU/Linux

Not to worry, it’s up to date and it runs the latest KDE. The general impression has been positive, having worked on this operating system for the past week or so (still awaiting my Ethernet’s return, so working from a lab, not via SSH). A few remarks about the weak spots:

  • X (org/server) blows up under particular circumstances where a newer version of X might be expected. If an attempt is made to invoke it from a remote host (SSH with X forwarding), the whole of Fedora blows up and the session must be restarted. If run locally, the same type of X issue simply raises a hardware-based exception and produces a major warning, then gives the option to gracefully shut down the affected program. It’s not good, but it’s definitely better than the former scenario, which is reproducible by the way.
  • Dual-screen handling is fantastic. It is still a plug-and-play experience, even with Fedora 11 in place.
  • There are far too many visual artefacts and drawing bugs (direct rendering is lacking). Again, this may just be the fault of old X and nothing whatsoever to do with the drivers of this GPU (Fedora seems to favour free drivers).

Aside from X rants, this platform is fantastic for development. Everything has worked well so far, except Firefox with occasional crashes (occurring at least once a day).

Is Fedora ready to become the most widespread GNU/Linux desktop? Probably not yet. But for development? Sure, why not? Fedora 14 is more mature, but that too has some wrinkles which I covered here before.

By the way, the screenshot at the top (click to zoom) shows the application I’ve been developing recently. More details will be published shortly as blogging distracts from persistent coding, and vice versa.

Cardiomat Version 1.0 is Released

TODAY I AM releasing the final code from my current project. The following is the accompanying README file:


Homepage: http://schestowitz.com/Research/Cardiac/Cardiomat
Index of related documents: http://schestowitz.com/Research/Progress/2010-2011.htm

INTRODUCTION

Cardiomat is the name given to an Octave/MATLAB program whose intended use is heart tracking, with various different bits that help probe cardiac structure and perform basic measurements.

FILES

Contained in the package are the following M-files and sub-directories:

./Experiments
./Experiments/fiesta_simulation-old-experiments.m
./create_synthetic_set.m
./GUI
./GUI/cardiomat.png
./GUI/splash.m
./GUI/splash.fig
./GUI/get_parameters_from_user.m
./GUI/getoptionsgui.m
./GUI/cardiomat-title.jpg
./GUI/cardiomat.m
./GUI/cardiomat.jpg
./getdicomimages.m
./loadtaggedsequence.m
./README (this file)
./Imported
./Imported/findit
./Imported/findit/findit.m
./Imported/arrow
./Imported/arrow/arrow.m
./Imported/gradient
./Imported/gradient/gaussgradient.zip
./Imported/gradient/gaussgradient
./Imported/gradient/gaussgradient/gaussgradient.m
./Imported/gradient/gaussgradient/README.txt.txt
./Imported/gradient/gaussgradient/testgaussgradient.m
./Hybrid
./Hybrid/cardsim_frame_shortaxis.m
./Hybrid/shuffle_transform.m
./fiesta_simulation.m

In addition, the program depends on at least one function from biosig4octmat-2.50, whose homepage is located at http://biosig.sourceforge.net. That function helps find the centre and the radius of a best fit circle/sphere for a group of points.

The directory named “Hybrid” contains functions that were written jointly and “Imported” contains functions which were brought from the outside. The core functions in the package are GPLv3-licensed and the rest are most likely to be BSD-licensed (check the sources to verify). Some of the imported functions may work only in MATLAB and not in GNU Octave, which is a free/libre substitute for MATLAB that lacks some graphical features for the most part.

HOW TO RUN THE PROGRAM

The program was written to be compatible with both Octave and MATLAB. There are some features in it that may require a UNIX/Linux system (e.g. animated videos) and some that may require MATLAB. Additionally, in order to reduce dependency on MATLAB’s GUI utilities, the program can be run in GUI and CLI modes separately, with only the use of figures being the exception to this (figures are output rather than means of interaction).

Key functions reside in the main directory of the program (one function, getdicomimages.m, is deprecated) and a directory named “GUI” contains some of the newer parts that add a GUI.

An important interface function is called fiesta_simulation.m. The first line of code in this function is a boolean flag that says whether the program should be run in GUI mode or not. If use_gui is 0, then the program will simply run the list of tasks specified below. It is possible to give several jobs for the program to complete this way, e.g. in order to run many experiments overnight. If use_gui is non-zero (probably 1 but not necessarily), then the function is assumed to have been called from the file GUI/cardiomat.m, which is a wrapper that invokes a splash screen and some dialogues that serve as a graphical interface. In turn, parameters fed to these dialogues will be passed to fiesta_simulation.m. It might be necessary to modify some paths inside the files in case the functions and the files are located in different places than the ones specified in parameters. Such paths are named in fiesta_simulation.m, loadtaggedsequence.m (specifies output directories onto which to save figures), and splash.m (looks for program images). For a new user, the only things require modifications are likely to be directory paths and maybe the use_gui boolean, depending on this user’s preference.

To run the program in GUI mode, MATLAB is needed. There is also a parameter to specify in fiesta_simulation.m in order to inform loadtaggedsequence.m whether MATLAB or Octave gets used. It is the boolean which is also the last argument in the function call, being 0 for MATLAB and 1 for Octave. The GUI front end will always pass 0 under the assumption that it is run under MATLAB.

DATASETS

The specified directories include a path from which to open images, optionally with a wildcard to filter bits contained within a given directory, e.g. selecting a subset of images that are a range of numbers. Due to privacy/data anonymity constraints, no raw data accompanies this program, even though it can definitely be obtained from many places (see for example https://schestowitz.com/Weblog/archives/2010/11/14/segmented-and-tagged-datasets/).

COMPATIBILITY

There are separate levels of compatibility dilemmas. One is the program level and another is the operating system level. Although the program has been tested in both MATLAB and Octave, on both GNU/Linux and Windows, there may be trivial code changes to make in case errors show up. Most will be path related, so it is abundantly clear that emphasis should be put on making all functions reachable from within paths definition (e.g. “addpath(genpath(YOUR_PROGRAM_ROOT_DIR_HERE))”) and booleans should be set to do the right thing (GUI/CLI and MATLAB/Octave). The goal is to ensure the program can be run under as many platforms as possible, with either free/libre or proprietary software.

IN CASE OF DIFFICULTIES

If issues running the program are experienced, please contact the author (address above). Bugs are expected to exist (it is a research purposes program, so polish is not a priority) and input is not validated or sanitised to provide virtual ‘rails’ on which the user operates the program (sane values need to be given). Sample function calls are given in fiesta_simulation.m and /Experiments/fiesta_simulation-old-experiments.m. Some of them may use the old interface and thus lack some input arguments, but most of them show the type of experiments which were run using the program.

Making My Latest Program (Cardiomat) MD-Ready

By sacrificing the comfort of the command-line interface (CLI)

Over 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:

Cardiomat directory selection

Cardiomat directory menus

Porting Code From Octave to MATLAB (or Vice Versa)

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

For 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.

Retrieval statistics: 21 queries taking a total of 0.155 seconds • Please report low bandwidth using the feedback form
Original styles created by Ian Main (all acknowledgements) • PHP scripts and styles later modified by Roy Schestowitz • Help yourself to a GPL'd copy
|— Proudly powered by W o r d P r e s s — based on a heavily-hacked version 1.2.1 (Mingus) installation —|