Automated Imaging Microscope System

The Aging Research Centre (ARC) is
developing an Automated Imaging Microscope System (AIMS) to enable
researchers to view the three-dimensional cellular organization of
a region of tissue from a series of microscope slides. AIMS employs
a computer-controlled microscope that can move a microscope slide
along the X and Y axes, so that the field of view can be moved in
equal increments. The microscope also has an autofocus mechanism. A
CCD camera captures images, one field of view at a time. Using a
magnification of 400 power, a typical slide contains 25,000 fields
of view; perhaps 7000 of those fields contain something of
interest. By using the thousands of individually captured images,
the system is able to reconstruct a very high-resolution image of
the entire slide.

AIMS analyzes each of the thousands of images and identifies
and stores the following attributes for each cell it was instructed
to identify: X,Y and Z coordinates for each desired cell type,
amount of each stain in the cell, type of each stain in the cell,
color of each stain in the cell and type of cell.

When AIMS has processed multiple layers of a tissue block,
the system will be able to reconstruct a three-dimensional map of
the cells in that block. In an experiment where there are two
groups of animals and the researcher wishes to compare tissues from
the two groups, AIMS will be able to compare three-dimensional
structures as well as cell counts.

The Implementation

The system has two very different functions: acquisition and
analysis. When we designed the system, we started on both ends
simultaneously, attempting to analyze images captured from other
sources, then working on our own data. Because we hope for the
system to be used by biology researchers, not UNIX gurus, a decent
user interface is one of the primary goals. We chose Tcl/Tk for the
ease with which a GUI can be developed. The easily modifiable
prototypes are useful. Various commands, written in C (but with
Tcl/Tk interfaces) are used to control physical devices.

Physically, the system consists of an optical microscope, a
CCD camera and three stepper motors hooked to the parallel port.
The stepper motors move a microscope slide around the stage under
computer control; basically, we have a 60,000bpi scanner.

Stepper Motors

The stepper motors are driven by Darlington-pair transistors
(see
http://www.doc.ic.ac.uk/~ih/doc/stepper/
for a discussion on stepper-motor control). This allows for great
control, at the expense of hefty timing requirements. In the Linux
kernel, we can find floppies driven every three to eight
milliseconds. Empirically, given the load on our motors, we can
sometimes move more than twice a second. We've hooked them up to
the parallel port. The parallel port has eight data lines and four
control lines which can be used for output. This is just sufficient
to control three stepper motors at four controls/motor. If we
needed more motors, we would have to use a different type of
controller. Figure 1 shows the microscope looking at the focus
mechanism. Figure 2 shows the circuit driving the motors. It uses
two ULN2003A chips and is powered by a spare computer power
supply.

Figure 1. The Microscope

We need to do a lot of moving, so speed is very important.
Using nanosleep seems the
simplest, if not the best, alternative. Combined with real-time
priority, this causes the motors to move with a nice smooth hum.
The other alternative, using the real-time clock at 2048KHz,
doesn't allow as precise a control over speed. The major problem
with this approach is the way nanosleep handles its delays. A
busy-wait prevents any other task from running. RTLinux does seem
like a better solution, although we haven't investigated that yet.
The older usleep call is a poor
choice, as it has 10ms granularity.

Figure 2. Circuit that Drives Motors

The greatest problem is figuring out the speed to move the
motor. The speed at which a stepper motor is capable of moving
depends on the load placed on it, and this load varies depending on
the friction in the stage. A speed that works at one location may
not work at all at another. Empirical experimentation seems
necessary.

We can move in three dimensions. Not only can we view the
entire slide, we can change the focus. A jury-rigged solution seems
to work—move up and down, and pick the image with the most detail.
We assume the one with the most detail is the most focused.
Technically, “detail” is based on a “busyness” function. For
each pixel, find the difference in intensity between each of its
neighbors, then sum the absolute value of those differences.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.