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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Profiles and RC Files
- Astronomy for KDE
- On Your Marks, Get Set...Gutsy Gibbon!
- Understanding Ceph and Its Place in the Market
- SoftMaker FreeOffice
- Maru OS Brings Debian to Your Phone
- Git 2.9 Released
- OpenSwitch Finds a New Home
- Snappy Moves to New Platforms
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide