Automated Imaging Microscope System
Because this project started before Linux 2.2, which has frame grabbers built into the kernel, we are using the Matrox meteor frame grabber, which has support at www.gnofn.org/~marksu/meteorman.html. The mvid program which comes with the driver was a useful starting point. We integrated it with Tcl/Tk. This allows us to make snapshots, view real-time video at variable frame rates and sizes over our network and get measures such as “how dark is it?” or “how much detail is there?” by directly accessing frame-buffer memory.
Real-time video is useful for manual focus to check whether autofocus is working, for setting boundaries of the scan, and of course, for just joking around by taking pictures of staff members. The “meteor” driver sends out a signal whenever a new image is available. If we're ready, we will send the image out using XPutImage and XSync. If the previous image isn't done, we ignore the frame entirely.
While shape is important, size and color are simpler to use as heuristics. We take a single image, then use sliders to select the colors which we consider to be a cell. If it is big enough and the right color, it must be a cell. This isn't a very sophisticated technique; it isn't much of a refinement over “thresholding”, where anything sufficiently dark is counted.
Currently, we use Tcl/Tk to select the ranges of RGB color which will be allowed. In the future, it may be useful to select regions in HSV color space.
The simplicity of the algorithm means cells can be counted “on the fly”; during the scan, the algorithm is performed on each field of view. The cells on the boundaries are counted multiple times, but we know where the boundaries are and can ignore them.
It would theoretically be possible to do this job without any computer at all. A technician could look at each slide, 0.2 mm at a time, and count every cell he saw. Looking at 2mm by 2mm sections, this would require exhaustive work for the 100-odd fields covered by a typical mouse hypothalamus. Fatigue could introduce bias. It would be easy to count a given marginal case one way when wide awake and another when tired—but people are good at image processing, computers aren't. People make mistakes when they are tired; computers make mistakes all the time. Still, even if absolute numbers are biased, we hope that relative numbers will still show useful differences.
There are currently two interfaces to the physical “scanner”: one for grabbing an overview (see Figure 3) of the entire slide, at 25 bits per inch (i.e., the microscope's objective is moved 1mm at a time, and the average color at that point is saved), and another for grabbing a specified region on the slide. In the second case, because of the low speed of directory listings (ls takes quite a bit of time if there are 2000 files), a directory is created for every column scanned. Figure 4 shows the interface used to scan in a rectangular region. The user can use the cursor keys to move the slide, and then select the boundaries.
One planned refinement is to scan in only those areas which we think may have useful content. If locations (x,y), (x+1mm,y), (x,y+1mm), (x+1mm,y+1mm) are all blank, it is reasonable (given the size of our samples) to ignore (x+0.5mm, y+0.5mm).
The optimal refinement would be to store only the regions which actually have useful content. In our case, we are interested in only the hypothalamus. An empty area is near this, which could conceivably be automatically recognized; if so, we could discard thousands of frames of less-important data.
It would be nice to store the entire slide in a standard image format such as JPEG or TIFF, but for some reason, 12,5000x50,000-pixel images are difficult to process at 24 bits per pixel (18GB per image seems a little excessive). Storing each frame individually using JPEG uses 10-50KB per frame; more for detailed ones, less for blanks. If only images with useful detail are saved, it should get under 650MB/slide, in which case each slide might be stored on a CD-ROM.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- August 2015 Issue of Linux Journal: Programming
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development