MLx Home | Contents | MLx menu | MLx buttons | Widgets | Index | What's New | Examples
Example: Processing RAE images with MacLispix
This example illustrates some tools in MacLispix for processing RAE images. Steps are in
Comments and results are in normal paragraphs.
The RAE images, once they are read in and tiled, look like this:
except that these images have been reduced to half size for display here. (There is a read & shrink option, which will have the same visible effect - the images will be reduced to half size (half the resolution), with each pixel being a sum of four of the original pixels. In this case, the images are loaded with full resolution - with no pixel summing.)
The information button displays the following information.
"ir3316ca" (UNSIGNED-BYTE 16) (255 256) 127.5 "ir3316si" (UNSIGNED-BYTE 8) (255 256) 63.7 "ir3316ti" (UNSIGNED-BYTE 8) (255 256) 63.7 "ir3316na" (UNSIGNED-BYTE 16) (255 256) 127.5 "ir3316mg" (UNSIGNED-BYTE 16) (255 256) 127.5 "ir3316al" (UNSIGNED-BYTE 16) (255 256) 127.5 "ir3316fe" (UNSIGNED-BYTE 8) (255 256) 63.7
This list says that the images are 255 x 256 pixels square, and that they are of two different types: 8 bit pixels and 16 bit pixels. (The RAE image format stores the images to the precision necessary -- the maximum value for the Si, Ti and Fe images was less than 255, thus not requiring the high order byte. When storing the high order byte the EVANS software omits 32 pixels from the last scan line of the high byte image. To make the images consistent, MacLispix omits the last scan line of both 8 bit and 16 bit images.)
The size in the above list is pixels per row, number of rows. The last scan line - after reading into MacLispix - appears as the pixels along the right border, because the images are transposed from their original order. The images can be (re) transposed in MacLispix by using the pixel ops -> transpose button, but since this example does not compare the images as displayed with other programs, the images will be displayed as read.
Aluminum image as read into MacLispix.
Aluminum image as converted to TIFF and read into NIH Image. Size here is (256, 255)
Here are the minimum and maximum pixel values for all seven images - note that the images with maximum values less than 255 (2^8 - 1) were the images stored as 8 bit arrays.
ir3316ca Min 0 Max 606 ir3316si Min 0 Max 139 ir3316ti Min 0 Max 145 ir3316na Min 0 Max 270 ir3316mg Min 0 Max 322 ir3316al Min 0 Max 874 ir3316fe Min 0 Max 86
All of the images, when displayed in any image processing program that I know of, are scaled to byte pixels (256 gray levels), as these are all the levels that a CRT display typically has, and are more than the eye can discern. How the image data is actually stored in memory, depends on the individual program. In NIH Image, for example, the data is stored as 8 bit data, and scaled back to the 16 bit values (if necessary) in the info window, in other words, NIH Image keeps the data to 8 bit precision only.
For display, this makes no difference. For enhancement or analysis, this might make a considerable difference.
A color overlay looks like this in MacLispix;
This is a 24 bit RGB overlay.
|In NIH Image, but, again, this is an 8 bit COLOR image, which looks a little blotchy because of the limited number of colors.|
Taking the Aluminum image above, the histogram (as read into NIH Image) looks like this:
Note the spiky appearance - this is due to the scaling of the pixel values from 0 - 874 to 0 -255. If the pixel values were scaled upward (stretched) rather than downward, an the histogram would have gaps rather than spikes. An illustration might be beads on a rubber band - when the rubber band is stretched, the beads cannot be subdivided, so gaps will appear between some of them. The opposite sort of thing occurs when the images are scaled downward - some bins get more than their share of counts.
The histogram of the 8 bit version:
And the equivalent histogram of the 16 bit version: