Scan an image

vdennis

Member
Has anyone played with having Progress call a scanner and then saving the scanned file into a BLOG? -Dennis-
 
sure, you can either use twain to interface with
a scanner, digital camera etc.

or a another approach, maybe a simpler one
setup the scanner to dump the image to a network drive

you can find an example using twain with p4gl
@4gl.fr \ downloads \ tips for progress

and there's tons of info on the web
about the twain standard
 
Thanks for the info. I will have to look at that site. We want to avoid using a seperate file type system as we will be scanning invoices and need to pull the account number from a bar code in the process, create the record, then dump the image into the blob.
 
you want to read the bar code off the image using p4gl ???

progress is a high level business application language
it's not designed for building 3d games or analyzing images

think of a more practical way or process

for example use a bar code scanner gun
as part of the process of filling information about the document
 
You have it right in the last part. We have been using bar scanners for data input from the invoices. I would use the same information to 'id' the invoice record.
 
Hi vDennis,

One of my colleagues used a piece of software which scans in the documents and then using Active X technology parses the image file and searches for the barcode. Upon finding it the software then reads the document ID and automatically stores it on our HP-UX dabase server - it even allows use of a feeder so the user simply puts multiple documents in the scanner, starts the scan and goes to make a brew !!

Alright, the ActiveX had to be purchased, but, we only needed 1 single user license as we have a 'gateway' PC which processes the documents, scans the barcode and stores them on the UNIX server.

Hint : Although we store the images on the database server we don't store the images in the database, but, write a database record which contains the key details, say, invoice number and another field which is a UNIX directory path and uniquely generated filename. The image is automatically ftp'd by the gateway PC to the UNIX server and a database record created which points the client application to the image. The image is then ftp'd down to the users PC - not storing images in the database is personal preference - prevents database getting too big, but, has disadvantages in that additional FTP software is needed to transfer the images to/from the server.

Active X's required :-

1. FTP - images to/from the server
2. Utility for parsing the image and recognising
the barcode.
3. Active X for scanning
4. Font for the barcode to be printed - we also use integration into MS Excel for printing our documents and have a cell which contains the barcode deta, simply formatted with the barcode font - I used code 39 as I found a free one and the info. we wished to hold fwas very straightforward.

There is an initial cost, but, we do alot of scanning and image moving !!

An absolute superb site for Active X's is

www.componentsource.com

Although, they do charge (you do get support though). so it's always worth doing a search over the internet first to see if you can get free software.

Sorry I can't give you any code samples as the code is not licensed to me, but, email me if you want me to give you some more specific details (or at least show you how to start using some of the above mentioned Active X's).

Progress these days can do pretty much anyything and Business Applications these days require more than a few buttons and drop-down boxes so their ActiveX support is quite good. We use them for all manner of things including image manipulation, advanced label printing and even device control !!

Hope this helps.
 
Binary File / Barcode / Storeage

Hi,

Its perfectly possible to perform batch document capture ( using barcodes on the document for ID info ) and do post-capture processing such as colour reduction, image cropping, resizing etc using a couple of active-x controls.

In terms of binary documents and storeage we have implemented the storeage external to the db and use appserver calls to transport the blob between client and server. This eliminates the need for either a shared file-store and/or ftp transfers.

Storing a large amount of blobs in the db will hugely increase the size of db required and dba effort to keep efficient. For example we have one implementation which has a total file store of over 6 Gb but the db that manages it is less than 100Mb. This approach also allows you to take advantage of near-line storeage devices and worm devices for archive ( such a optical disk / dvd ).

Im sure there are simplified examples somewhere of blobs being held in the db that could be adapted for your purposes.

Hope that helps - what your trying to do is perfectly possible with the native 4gl plus a couple of simple active-x components on the client side.
 
If storing blobs in a DB I'd look into compressing the binary data before storing and decompressing before viewing/retrieving. It is possible to use the Zlib (www.zlib.org) compression library for this ... as I've already implemented this.

Later,
Gordon
 
Compression is also an effective means of reducing network transport time if the objects are used in a client/server implementation.

Compression of text files ( such a spool files ) is incredibly effective - however compression of binary files such as jpeg ( which is already compressed/lossy ) isnt going to make a huge difference. IMHO.

We did some time trials and the overhead of the compression is far outweighed by the transport time saved ( on files above around 50kb )

Hope some of all these ramblings is useful ;) ?
 
Correct on JPEG etc.

I just think that it's a useful component to add when storing BLOBs regardless of the format. I was utilizing the compression in a document management system and I performed the compression regardless of the file type. Saves a lot of disk (DB) space and ... as you mentioned ... network traffic. It's very easy to implement and should seriously be considered. Even saving a couple of K on each image is worth it ... if you have thousands of documents.
 
Back
Top