Ninth Electrotechnical and Computer Science Conference, 21-23 September 2000, Portorož, Slovenia
Primož Peterlin1, France Sevšek1,2 and Walter Fetter Lages3
1Institute of Biophysics, Faculty of Medicine,
University of Ljubljana, Lipičeva 2, SI-1000 Ljubljana, Slovenia
2University College of Health Care, University of
Ljubljana, Poljanska 26a, SI-1000 Ljubljana, Slovenia
3Electrical Engineering Department School of
Engineering, Federal University of Rio Grande do Sul, Av. Osvaldo
Aranha 103, 90035-190 Porto Alegre - RS,
Brazil
A system developed on Linux platform for acquisition of biomedical images is described. It consists of a kernel driver, a library, and a set of application programs.
To great extent, biomedical research relies on image acquisition and digital image analysis. This often requires acquiring and analysing a large amount of images, in our case micrographs of phospholipid vesicle cross-sections [1, 2]. Therefore, an efficient, easy to use, and cost-effective solution is sought. We present here a six-layer modular solution based on the open-source Linux operating system that can adequately replace commercial image acquisition software.
| Script |
| Application |
| Library |
| Operating System |
| Device Driver |
| Hardware |
Fig. 1: Structure of the image acquisition software.
The lowest layer (Fig. 1) in the presented solution is the Hardware Layer. The actual hardware solution presented here is based on the Data Translation DT2851 high resolution frame grabber, connected via ISA bus to the PC-compatible host computer. With the documentation on register-level programming of the image-acquisition board, it can be extended to other types of boards. Sitting on the top of Hardware Layer is the Device Driver Layer. Device driver for the DT2851 is part of the operating system kernel and provides the device files and the neccessary infrastructure for the communication between the user-space programs and the hardware via the operating systems calls.
The third layer - the Operating System Layer - comprises of a standard Linux kernel. The optional fourth layer is represented by the library, provided primarily to ensure consistent API for legacy MS-DOS programs.
The fifth layer, the Application Layer, is the platform for user-level programs written in C or C++ programming language, providing either a graphical user interface (GUI) or a simpler command line interface. In the case of the latter, an optional sixth layer or Scripting Layer is introduced. As a solution which allows rapid prototyping, non-compiled scripting languages like shell scripting language, Perl or Python can be used to tie together simpler compiled commands into more complex scripts. These can either do some batch processing or provide a visual interface using TCL/TK.
Excellent networking support on Linux allows for the physical separation of image acquisition and image analysis phases. Thus, the workstation where the image analysis is performed can be physically detached from the one performing image acquisition, and can access the files on the latter over the local network, using either File Transfer Protocol (FTP), the Network File System (NFS) or the Server Message Block (SMB) mechanisms. This can be favourable when the image acquisition has to be performed in reduced light conditions (e.g. flourescence microscopy), thus making it inconvenient for the operator to work.
Data Translation DT2851 is a professional frame grabber that connects to host computer via ISA bus. It has two 512×512 8-bit high-speed frame-store memory buffers, eight 256 by 8-bit RAM input look-up tables, eight 256 by 24-bit RAM output look-up tables [3]. The DT2851 can be programmed via eight 16-bit I/O registers, which are used for control and status purposes (Fig. 2).
The rather old design of this frame grabber poses a problem, as it requires 512 kilobytes as a frame-store buffer in the lower 16 megabytes of host memory addressing space. This requires either a computer with at most 12 megabytes of RAM, or one with a BIOS supporting a one megabyte memory hole within the lower 16 megabytes.
| INCSR1 | Video Input Control/Status Register 1 |
| INCSR2 | Video Input Control/Status Register 2 |
| OUTCSR | Video Output Control/Status Register |
| CURSOR | Cursor |
| INDEX | Index |
| INLUT | Input Look-Up Table Register |
| REDGRN | Red/Green Output Look-Up Table Register |
| BLUE | Blue Output Look-Up Table Register |
Fig. 2: The DT2851 frame grabber is controlled and monitored via eight 16-bit control and status registers.
The Linux kernel device driver for DT2851 [4] provides user-space programs the access to the frame grabber via special files and system calls.
The I/O registers, the frame-store memory buffers, and the eight
input and output look-up tables can be accessed via Unix device
files. Major number 26 has been reserved for the DT2851 device
files. Up to four DT2851 frame grabber boards are supported, using
major device number 26 and being available through character special
files /dev/fga*, /dev/fgb*,
/dev/fgc* and /dev/fgd*. As they are
identical, we can limit our treatment to the first of them.
/dev/fgabuf0/dev/fgabuf1/dev/fgailut0 to /dev/fgailut7/dev/fgaolut0 to /dev/fgaolut7/dev/fgacsioctl(2) calls to the /dev/fgacs device.
/dev/fgacurUser-space applications can control and monitor the frame grabber via
ioctl(2) system calls. In the example code snippet below
frame buffer 0 on the DT2851 is selected as the input buffer (code
CS_SELIBUF with the argument 0 is written to the
control/status register device):
#include <dt2851.h>
#include <dt2851io.h>
...
int cs;
cs=open("/dev/fgacs", O_RDWR);
ioctl(cs, CS_SELIBUF, 0);
The mechanism provides easy access to the frame buffer memory, which
can be for easier manipulation read into an array:
int fb;
unsigned char buf[512][512];
...
fb=open("/dev/fgabuf", O_RDWR);
lseek(fb, 0, SEEK_SET);
read(fb, &buf, sizeof(buf));
Just as easy is writing to the look-up table:
int olut;
unsigned char lut[256][3];
...
olut=open("/dev/fgaolut0", O_RDWR);
lseek(olut, 0, SEEK_SET);
write(olut, &lut, sizeof(lut));
DT2851 device driver requires Linux 2.0 or any later version. It has been tested with kernel versions 2.0 and 2.2. Please note that the program interface for kernel modules occasionally experiences minor changes with a new major kernel release.
Due to its modular architecture, DT2851 device driver can be loaded
into the kernel or removed from it at run-time using the commands
insmod(1) and rmmod(1), without the need to reboot
the system.
For backward compatibility with legacy applications developed under
MS-DOS, a library was written. Its sole function in Linux is
translating the library calls like start51(3),
setinlut51(3) etc. into the corresponding
ioctl(2) calls. As it provides less flexible interface to
the frame grabber board while at the same time introducing some extra
overhead, its use is discouraged for developing new programs.
We use the term application for compiled programs, as opposed to scripts using them. The user interface divides compiled programs into two classes: those employing a graphical user interface (GUI) and those which use command line for user communication. The latter group can be more easily combined with scripts into bigger entities.
In our example, the programs of application layer are lightweight applications, limited to the image acquisition step. Image analysis [5] is separated and conducted on another workstation, connected to the aquisition site over network. There are two reasons for separating image acquisition from image analysis. First, this allowed us to perform numerically less intensive image analysis on a less capable computer which would have otherwise been discarded, and second, the operator conducting image analysis was allowed to work on the collected data in the comfort of his office while the acquisition computer was already collecting a new set of data.
The traditional Unix programming philosophy [6] emphasizes the importance of small, cooperating tools rather than the big monolithic programs. Interpreted script languages like the command shell language, Perl, Python or TCL allow rapid prototyping, and are thus particularly useful in research environment, when the changes in program are frequent
The downside of scripts is however their speed. With the maximal rate of recording about 1 frame/sec, they are really useful only for time-lapse micrograph recording.
Unlike QNX or VxWorks, Linux was not designed as a real-time system. While our current needs in biomedical imaging do not require real-time acquisition at present, we plan to move into that direction. There are other applications like robot controlling [7] that require it already.
One possibility is an extension like RT-Linux, developed at New Mexico Tech [8] or RTAI, developed at the Politechnica di Milano. Either of them endows Linux with real-time capabilities. The idea underlying such extensions is a real-time preemptive scheduler that shares the processor among the Linux kernel and the real-time processes. To honor the real-time constraints, the kernel runs at the lowest priority. The current state of RT-Linux, however, requires that the real-time programs run as kernel modules rather than user-space programs. This imposes certain limitations on them, like e.g. floating point support.
The alternative is to use standard Linux kernel with all its limitations and implement real-time tasks using POSIX threads [9].
A lot of effort is put into making Linux capable of running as an embeddable real-time system. The developers now seem to have agreed on the EL/IX API supported by Cygnus solutions. This fills us with hope that in a not too distant future real-time capabilities will be integrated into the standard Linux kernel, and standard programs will be able to run using real-time scheduling.
A less pressing matter, as we see it right now, is making the driver compliant with the Video4Linux initiative [10]. While standardization of the access to video data on Linux is certainly a worthwhile effort, we believe that our application fits into a different niche and while the conformity is desired, it is not absolutely required.
Consistently with the practice in the Linux community, the software described here is provided using the concept known as the Open-Source Model: free of charge, along with its source code and the right to modify it.
ftp://metalab.unc.edu/pub/Linux/apps/video/dt2851-2.2.1.tar.gz,
1997-2000.
http://www.delet.ufrgs.br/~fetter/ieeesw.ps.gz, 2000.
http://roadrunner.swansea.uk.linux.org/v4l.shtml
Created 2000-10-06 by P. Peterlin
Last update $Date: 2000/10/06 11:36:24 $ by $Author: peterlin $