VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]
|
VOICE Home Page: http://www.os2voice.org |
June 2002
[Newsletter Index]
|
| By Manfred Agne © June 2002 |
About two years ago, I began getting interested in a slide scanner. I already had a flatbed scanner from Microtek, the Scanmaker 630 which is supported by ImpOS 2.1. I knew that Microtek also made a slide scanner, the 35t+. A quick look showed that ImpOS also had drivers for this type of scanner. I also read some hardware reviews in c't (a German computer magazine), and the scanner appeared to perform reasonably well, although other, more expensive scanners produced slightly better results. However, the Microtek ScanMaker was the only scanner that seemed to have OS/2 support. Since I already had ImpOS, there were no additional costs over the price of the scanner.
The package that I received included the scanner itself, a printed manual, a short SCSI cable (25pin sub-D to 50-pin centronics style), an Adaptec SCSI card for ISA bus (OS/2 drivers included in Warp and eCS), a film stripe holder, several slide frames, and the CDs with the Windows and MacIntosh software. Then, there was a color reference slide and a color calibration software for Windows which came on two 1.44" floppies. The reference slide is presently useless under OS/2, but don't throw it away - maybe we can find some use for it in the future (don't even ask...). By the way, the image shown below wasn't scanned with the scanner - it was taken with a cheap webcam. The scanner's quality is much better, of course.
Hardware installation was dead easy: I set the SCSI ID to an unused value, put the ScanMaker 35t+ on the SCSI bus between the ScanMaker 630 and the Advansys SCSI controller and started the PC. However, quite unexpectedly, I had trouble under OS/2: The latest ImpOS drivers did not recognize the scanner! After some experiments, I rebooted to Win98. I installed the software that came with the scanner (basically an updated version of the software that I already had gotten with the flatbed scanner), and scanned my first test image. The scanner did work, but after a few successful scans, all I got was garbage data. I contacted the supplier, and they sent me a replacement scanner. Meanwhile, I had asked for help in c.o.o.apps, c.o.o.misc, and de.c.o.o.apps, and some kind soul had sent me older ImpOS drivers for the scanner. The older drivers do not attempt to determine whether the hardware is there - they also load when the scanner is off. This is a good thing, since it eliminates the point of failure of the newer drivers, and in fact, the 35t+ works nicely with these drivers. Just to be clear on that point: The hardware failure was totally unrelated to the driver problems under OS/2.
Here's a scan of the color calibration target provided with the scanner. Click on the image to load the full size image (800k JPG).
The scanner has a physical resolution of 1950 x 1950 pixels, and that's what I'm using for my scans. For a normal slide (36mm x 24mm), the scanned image has about 2760 x 1840 pixels, which produces a bitmap of about 13MB. If I save the images as JPGs at "90%" quality, I get an average size of slightly more than 1MB. Unfortunately, I haven't been able to find a test slide which would allow me to measure the resolving capabilities of the scanner, but I can tell you that the scans revealed defects in my images that I didn't notice before. Thus, the resolution is good enough for me :-)
The Windows software that comes with the scanner appears to work reasonably well, although I must admit that I don't know why anybody would want to use an OCR program with a slide scanner. I haven't really tested the Windows software with difficult scans. There's also some MacIntosh software, but I have no idea how good it is.
Of course, I bought the scanner to use it under OS/2, and especially with ImpOS. I will not say much about ImpOS in general at this point - the software hasn't changed in the last few years, and you can read more about it in Voice Newsletter 07/2001 - ImpOS/2 revisited. ImpOS has the basic scanning capabilities, but it is also lacking in some respects. For example, ImpOS does not have a histogram tool, and negative inversion is not possible. However, as I already said in that article, ImpOS has the big advantage that its capabilities can be expanded with REXX, and I started writing some add-ons. While I wrote the present article, I managed to complete a first version of the add-on which is now available as Bibertools from Hobbes. It adds a few new features to ImpOS, including a new scanning interface, a histogram tool (ie. a tool which shows how many pixels of a given R, G, B value are present in the image), and a function to invert scanned negatives.
The ScanMaker 35t+ is apparently also supported by the OS/2 version of SANE, (a port of the Linux scanner drivers), but I haven't tried this so far. It should also be possible to adapt my ImpOS add-ons so that they work with SANE. If someone needs this, drop me a note :-)
I did some experiments with the scanner, first because I'm a curious person, and also because I felt that I needed to know more about the capabilities and weaknesses of the hardware in order to obtain optimum results. The context menu of ImpOS's scan preview window provides access to a two-page settings notebook, where we find sliders for "brightness" and "contrast". Generally speaking, brightness and contrast can be adjusted either in the scanner or in the final image data. Best results are obtained if brightness and contrast are adjusted via the scanner (ie. before the image data are reduced from the scanner's internal 30bit representation to the 24bit representation which is transferred to the PC), and it turns out that these two sliders do it that way. I scanned the central part of the horizontal greyscale bar in the color target with different settings and used one of my own REXX procedures to generate histograms for the red, green, and blue color components of the scans:
The images were scanned with a medium contrast setting (0%), and the respective brightness settings were -50%, 0%, and +50%. As you can see, the whole histogram is shifted from lower to higher intensities (ie. from left to right) when the brightness is increased. However, the shape of the histogram remains pretty much the same, which is what we would expect. Also, the shift is the same for all three colors, ie. the brightness setting does not influence the color balance. Very good!
In this case, the images were scanned with a medium brightness setting (0%), and the respective contrast settings were -50%, 0%, and +50%. The histogram is expanded with increasing contrast, with a medium brightness (128 of 256) remaining almost unaffected. Again, the stretching factor appears to be the same for all three colors, which means that the contrast setting does not influence the color balance. This gives us the possibility to correct at least for some under- or overexposure in the film material without having to worry about RGB balance.
You will probably also have noticed that the red and green histograms show eight distinct peaks - they correspond to the eight grey levels present in the scanned part of the greyscale bar. These peaks are hardly visible in the blue histogram, and the following image shows why. This is a contrast enhanced scan of five different grey levels from the color calibration target's greyscale bar, separated into the red, green, and blue color channels (from top to bottom). Clearly, the blue component has much higher noise than the red and green component. I guess that's because the lamp's intensity in the blue is rather low, and therefore, the scanner is preset to use high internal amplification in the blue part of the spectrum. This increases the noise.
There's little that we can do about this weakness, and it is likely that other scanners have a similar problem. However, if you find this really annoying, it is still possible to scan the same slide more than once, and average over the individual scans in order to reduce the noise level. NETPBMA has a command line program that can average over two scans:
ppmmix -0.5 SCAN1.PNM SCAN2.PNM >OUTPUT.PNM
PNM is the lossless bitmap file format used by the NETPBMA programs. ImpOS can read and write PNM files, and with a few lines of REXX, this can be used to automatically average over an almost arbitrary number of scans - powers of two (2, 4, 8, 16 scans) are easier to implement:
ppmmix -0.5 SCAN1.PNM SCAN2.PNM >AVERAGE12.PNM
ppmmix -0.5 SCAN3.PNM SCAN4.PNM >AVERAGE34.PNM
ppmmix -0.5 AVERAGE12.PNM AVERAGE34.PNM >OUTPUT.PNM
Don't forget to delete the temporary files ;-) Of course, scanning more than once takes more time, and more than two or four scans per image would make sense only in exceptional cases. Probably I should also mention that I had some problems with this when I used the scanner on my old 233 Mhz Pentium class computer together with heavy multitasking. Apparently, detection of the vertical starting position of the scan relies on the cooperation of the computer, and if the CPU was doing other things when the starting point was reached, the image could shift slightly upwards or downwards. Of course, this is of no importance whatsoever during the "normal" use of the scanner. But if we are overlaying individual scans, the vertical shift of some scans by a few pixels causes problems. However, with no especially demanding processes running concurrently, the procedure worked nicely, and on the new machine (AthlonXP 1600+) there are no alignment problems at all. The ScanMaker 35t+ is really accurate, and all scans of the same image end up in the same position. Of course, the faster processor helps with the image processing, too :-)
As I said before, ImpOS does not allow the inversion of scanned negatives. Of course, there is an inversion function which works with scanned black and white negatives, but as it does not remove the orange mask of color negatives it is pretty useless in most cases. I tried to find some other solution, but this seemed to be one of the few things that were just not possible with native OS/2 programs. However, the histogram tool (which I wrote for this article) turned out to be the crucial component for the inversion of scanned color negatives, and with the help of some REXX plus the VIO-based NETPBM utilities, it is indeed possible to solve this problem. I won't go into the technical details here, but you'll find an integrated inversion function in the previously mentioned Bibertools.
For comparison, here is a scanned negative (top left), the output of ImpOS/2's "invert" procedure (top right), the negative as scanned and inverted by the Win32 software (bottom left), and the output of my own image inversion routine (bottom right):
The output of my own inversion procedure is a bit darker than what I get under Windows, but that's only because I prefer it like that. Under OS/2, the software uses user-defined film profiles to remove the orange mask, and you are free to adjust them to your needs. This should also allow us to generate profiles with correction for color (im)balance caused by film aging or lighting conditions. For the time being, I'm pretty happy with this result. It's also nice to know that I can implement further improvements, if I find them necessary.
Of course, there are some weaknesses. The most important one is that the ScanMaker cannot really deal with severely underexposed slides. They can be so dense that virtually no light comes through, and it is almost impossible to get a decent scan from the remaining image signal, even with tricks like averaging over several scans. I don't see any possibility to overcome that weakness, except maybe to fit the scanner with a brighter lamp, or even better a lamp with adjustable brightness. But that would require extensive hardware modifications. Secondly, the scanner has a noisy fan, but that could be a problem of my particular model. If I remember correctly, the scanner that I received first (the one that died after a few scans) was much quieter. The resolution (1950 dpi nominally) is low compared to more recent models which go up to 4000dpi. I don't know whether any of these newer models can be used under OS/2.
Overall, I would say the Microtek ScanMaker is a good film scanner for OS/2,
and it is well worth the money I spent on it. At least for me, the possibility to
control its operation via REXX far outweighs the few weaknesses of the hardware.
Unfortunately, the ScanMaker 35t+ seems to have disappeared from the market a few
months ago (sorry to be late with this article), but from time to time, used scanners
are still being sold on Ebay, and most of them appear to be almost new. My own scanner
has now done well over 10,000 scans, and so far, it doesn't show any sign of wear.
If you buy a used scanner, make sure you get the "35t+", as opposed to
the earlier "35t". Although that one should work under OS/2 as well, I
have read pretty bad comments about the hardware, especially concerning mechanical
stability and wear.
References:
|
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org