This project is read-only.

production scanning

Apr 25, 2007 at 10:07 PM
Edited May 9, 2007 at 9:26 AM
Production Scanning - thoughts on automated or assisted production scanning.

Production scanning for me is closely tied to consistant scanning. Consistant scanning being the ability to aquire a scan today and another in a year with similar results. The frequency of the scaning places a very small role – and a high frequency coupled to similar results may be the product of a solution or it may just be the result of little interference.
I am not going to approach this from in the context of devices that don’t follow the twain specification or that aren’t twain compliant. Consistantcy form a device that doesn’t follow the specification isn’t an immediate concern – thise devices should, if possible, and at the very least won’t be a part of the topic here.
Take ID card scaning for an example. In some cases there may be a requirement that card be scanned at high resolution and other times a low resolution but in either case a scan taken today should match a scan taken in a month or year with tolerance for how the card is placed into the scanner.
Do inconsistant scans cause an unreasonable expense – either in time or money? And, do you require automation?
Maybe you do so little scanning that an extra 5 or 10 minutes per scan doesn’t add up to an unacceptable amout of time. But, if you do enough scanning eventually very little overhead is tolerable. If user error in setting up the vendor’s configuration dialog is a problem or if your time is limited then you need to think about the next couple of questions.
Are you in a position to support a very limited number of devices? Are you able to devote a significant amout of time to each device you support?
These two are almost the same questrion. The idea behind them is that the settings between devices seem to vary radically. Getting familliar with a device takes, in my opinion, a significant amount of time. If you have a small number of devices this time may not be of consequence.
Are your devices used by more than one application or are they used to scan more than one kind of document? If you only have one app that uses the device and you don’t casue the settings to change for the device you may very well get consistant beaviour from the device. If you change the settings on the device either with another application or by using the device to acquire a different image there is a distinct possibility that you will see inconsistant results.
Does the device offer undocumented settings? Sounds like a trick question, I know, but there are several ways to ask a device what capabilites it supports. The twain specification provides for vendors to implement their own custom settings. Sometimes the settings are available from the vendor, other times not. In either case, there is a distinct possibility that the device offers more settings than are documented in the twain specification. These custom capabilities are some cause for concern depending on how thedevice is used in production and bring two questions to my mind.
1) If a one of the custom capabilites are changed inbetween the image you take today and the image you take next month, your odds of getting consistant results are lower.
2) Do any of these custom capabilities offer better utilization of the device either in time or imagequality? The trouble here is that with the vendor’s dialog or application you may see faster aquisition or the imagemay come out at a higher quality. It would be hard to say the vendor isn’t playing by the rules but extending their use of the twain specification. The spec leaves room for custom capabilites for exactly this reason.
Possible solutions.
->Don’t use automation. Use the vendor dialog.
Benifits: If you are consitant in your use of the dialog and the time it takes you to configure the dialog is low you have a very good chance of consistancy.
Drawbacks: Your automation options are restricted to automating the dialog. If you are not consistant in your use of the dialog then you consistanticy will suffer. The time it takes you to setup the dialog.
->Support known devices.
Benifts: The particulars for the device(s) you support will become familliar over time and you consistantcy will probably inprove.
Drawbacks: Full use of the decive with respect to custom capabilites may not ever before be realized.
->Use a profile based approach based on EnableDsUiOnly and CustomDsData.
Benifits: Full custom capability support.
Drawbacks: Not all devices support these capabilities. They are not madatory for lower end devices.