Direct download as Ogg (1:39:34 30.8 MB) | Direct download as MP3 (45.6 MB)

Summary: Tim and Roy catch up with some news about GNU/Linux and enter discussions regarding these areas

TONIGHT’S unplanned show covered mostly GNU/Linux-related issues. Corresponding articles will be linked very shortly in OpenBytes‘ show notes. (Update: the notes have just been published)

The show ends with our default track. 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)

Direct download as Ogg (1:37:31 29.8 MB) | Direct download as MP3 (44.6 MB)

Summary: Tim, Gordon, and Roy talk about Microsoft’s results, LCA, ACS:Law, Google’s ‘censorship’, and more

LAST NIGHT’S show covered the above topics and so much more. Corresponding articles will be linked very shortly in OpenBytes‘ show notes.

The show ends with “Chur” from Countdown, which is a track Tim selected. 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)

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

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:

hat freedom means to me is not the same freedom that is preached to the masses by broadcasting companies. It is neither freedom of choice nor freedom that relates to cost.

In its most fundamental state, any person is not tied to anyone else except perhaps the community which is family, extended family, and sometimes more than that. In that case, a person is familiar with/to all peers, which is also what enables trade without currencies. There is a level of trust.

As societies grow bigger and bigger (moving into mega-cities, as noted in the previous post) trust gets replaced by control. Rather than trusting one’s peers people increasingly dominate and reign over other people; it’s means of peer control and it regulates one’s behaviour.

In the software world too there is a move from small communities of privileged developers with access to expensive machines; these days, a lot of people have access to computers and moreover to the Internet, which connects many of these disparate people. Mechanisms of control rather than trust are over time being put in place and these range from simple censorship to all sorts of artificial restrictions.

Freedom is always hindered by control. It is a relation of opposites. Control is antithetical to freedom assuming that control is not one’s own. Whether in a society as broad of ours one can ensure total freedom is very much questionable, but one must always keep in mind that if freedom is the goal, then control by others is a threat; sometimes it is a necessary and legitimate threat, but often it is (mis)used as a pretext for someone else to take control over others.

Writing assignment by anonymous contributor

he nanorobot is an artificial tiny machine that can move on its own. The nanorobot consists of a central unit which can operate inside the human organisms, and of a group of additional units that back the central unit. Its task is to implement certain medical operations on separate organs and tissues. With a successful technology today, the future nanorobots will be able to perform many actions and solve many problems which modern medicine cannot solve. In addition, the nanorobots can cause various atoms and molecules to connect and create new material which can be use as a substitute for important substances in the human body, and the role of certain organs.