Robert Davis

Re; Slide scanners
On the issue of slide scanners, we've found sometimes that the shading across images created by using fiber optics for reflected light (for whole mounts) often exceed the dynamic range of an 8bit/channel scanner, so that scans of slides look only just adequate at best, even after a bit of enhancement. One could argue that this is an illumination problem, but integrating video-rate CCD cameras that integrate 2-4 frames with reduced illumination seem to give better results sometimes.

Re; DAT vd CD
I was interested to read that you use the Mitsubishi DAT drive. We're considering buying a less expensive video system for more general use in the lab (we have some expensive rigs for cell microinjection/time-lapse), esp. for frog embryos. I've thought about adding rec. CD for image archiving, as well as general backup. Current rec. CD is a bit clumsy, though, since multisession recording requires a new FAT table for each session. So, it's easy to waste a lot of space with useless file pointers. Rec. CD is best done then when one has enough files to fill at least a quarter or third of the disk. Does the DAT drive allow as little as a few images written without wasting a lot of tape space per image? How easy is it to download from the tape?

From Peter; The DAT can store one image or over a thousand on a tape, it makes no difference. It takes time of course to move from image 1 to image 1100, but not so long that you can't sit and wait for it, maybe one minute or so. In terms of downloading I have not resolved how to do this, the Mitsubishi has an RS232 port, but I am not familiar enough with PCs to download the images directly. We usually send the image from the DAT as video to the NeXT frame grabber rather than doing it directly, it looses some reolution but is very easy.

Re; resolution
Your point about better than 640x480 pixels for a frame grabber is good, as it's generally best to overscan the video image a bit, but I wouldn't overdo it with really high resolution. The objective, or whatever imaging lens, mainly, and the camera, limit the overall resolution. Excessive overscanning of the video signal only adds "empty" information and makes for needlessly large image files. It's true that one can magnify the image through hardware or software and see less pixelation with highly overscanned images, but there's really no extra information content, and so it's a subjective thing. Better to use the optics to magnify, with increased resolution at the source.

Color Depth
Do you think 32 bit color is really better than 24 bit color? Most references to eye physiology describe 24 bit color as about all our eyes and brain can distinguish. On the other hand, digital color spaces only approximate all the color that can be coded, so maybe this is why 32 bit color is better????

From Peter; some people swear you cannot tell the difference, some swear you can. My only opinion on the matter is that the files take up only a little more space so why not have the extra information available. As you switch files from one format to another, and one program to another, images can start to look less good. For example in most instances 16 bit images look fine, but as soon as you switch to postscript it is quite obvious that insufficient information is available as the images begin to look blocky. I usually try to store images with as much resolution and depth as storage allows, as you will never know when you may need it.

Mac AV
My understanding of the Mac AV built-in video is that the effective video digitisation is 176 levels per channel, which is then interpolated to 220 levels. Automatic gain control is apparently always enabled, which is bad. There is also hardware gamma correction, which may or may not be turned off through software. So, a true 8 bit or nearly 8 bit rendition is not possible. This info I got from the NIH Image mailing list; it is from someone who apparently examined details of the chipset Apple uses, and so seems trustworthy. So, I wouldn't recommend Mac AV for video microscopy.

Finally, to my knowledge LZW compression is only a lossless block encoding scheme, and so it should not yield any degradation at all. LZW only compresses 2:1 or 3:1 at best, but that's not bad for no information loss.

From Peter; yes thats true. As I understand it LZW works by looking from similar "colors" in adcacent pixels and assigning them a value, so rather than recording 8 contiguous blocks of black; black black black black..... it records 8 x black, no data loss. In 8-bit grey scale there are only 8 options, so files are much much smaller when compressed, as identical shades are often adjacent. In 24 bit color there are over 16 million options, so more shades are assigned and the compression has fewer common colors to code together. This compression is used for program compaction, in which case of course no loss of information is acceptable, so it is a good choice for images if the ratio is sufficient.