Advice on imaging solution

  • Thread starter Thread starter D Lee
  • Start date Start date
D

D Lee

I am looking for some advice on imaging equipment/software for a
specific application.

I will need to process about 9,000 documents per day. Each document is
8.5" x 5.25". Paper weight is standard NCR paper (one part of a 3-part
carbonless form). Each document has a large (3" x 1") code 39 barcode
in a standard location on each page. The barcode are unique

I need to create an image of each page, and read the barcode. I do not
need to OCR the page. The image would be stored in a databse, the
retreival key would be the barcode number.

Any suggestions?
 
Recently said:
I am looking for some advice on imaging equipment/software for a
specific application.

I will need to process about 9,000 documents per day. Each document is
8.5" x 5.25". Paper weight is standard NCR paper (one part of a 3-part
carbonless form). Each document has a large (3" x 1") code 39 barcode
in a standard location on each page. The barcode are unique

I need to create an image of each page, and read the barcode. I do not
need to OCR the page. The image would be stored in a databse, the
retreival key would be the barcode number.

Any suggestions?
Click to expand...
This will most likely require custom programming. Do you have an adequate
budget?

Best regards,
 
This will most likely require custom programming. Do you have an adequate
budget?

Best regards,
Click to expand...

I do not believe budget will be an issue, as the process that this is
replacing is labour intensive. What I am trying to determine right now
is if the concept is technically feasible.
Doug
 
D said:
I am looking for some advice on imaging equipment/software for a
specific application.

I will need to process about 9,000 documents per day. Each document is
8.5" x 5.25". Paper weight is standard NCR paper (one part of a 3-part
carbonless form). Each document has a large (3" x 1") code 39 barcode
in a standard location on each page. The barcode are unique

I need to create an image of each page, and read the barcode. I do not
need to OCR the page. The image would be stored in a databse, the
retreival key would be the barcode number.

Any suggestions?
Click to expand...
9,000 documents in presumably an 8-hour day, or 16 hours if shift work
is envisaged. 9,000 into 8 hours with no down-time is 3.2 seconds per
document, so right away you will be into multiple workstations to handle
the load.

If you don't use OCR then you will be storing images of the documents,
depending on the document size that could be about 45 kilobytes per page
with 10:1 jpeg compression, if greyscale imaging is nused. (black/white
bit imageing will reduce that figure but is not much good if the copy
has pale writing as in ncr copies). At that, you will be generating
about 400 megabytes per day, say 2 to 3 gigabytes per week, or about 150
gigabytes per year, without the necessary indexing requirements. Backup
will require about 3 times that space, allowing for redundant backups.

This is not a trivial exercise.

A major database like Oracle or similar would be needed, plus
professional advice and installation.

Colin D.
 
Recently said:
I do not believe budget will be an issue, as the process that this is
replacing is labour intensive. What I am trying to determine right now
is if the concept is technically feasible.
Click to expand...
Tough question. It's technically possible, but I suspect that whether or
not it's feasible depends on many other factors.

Best,
 
Does the barcode also have the actual numbers of the barcode under it?

If so, OCR could be involved, to get that number from a scan into text;
and then it would be relatively easy to parse it out as the "title" of
the document with some other text/script tool?

MM
 
9,000 documents in presumably an 8-hour day, or 16 hours if shift work
is envisaged.  9,000 into 8 hours with no down-time is 3.2 seconds per
document, so right away you will be into multiple workstations to handle
the load.

If you don't use OCR then you will be storing images of the documents,
depending on the document size that could be about 45 kilobytes per page
with 10:1 jpeg compression, if greyscale imaging is nused.  (black/white
bit imageing will reduce that figure but is not much good if the copy
has pale writing as in ncr copies).  At that, you will be generating
about 400 megabytes per day, say 2 to 3 gigabytes per week, or about 150
gigabytes per year, without the necessary indexing requirements.  Backup
will require about 3 times that space, allowing for redundant backups.

This is not a trivial exercise.

A major database like Oracle or similar would be needed, plus
professional advice and installation.

Colin D.
Click to expand...

Actually, the storage database is transitory -- I do not need the
image data for long. I want to image the document, process it and
dispose of the image. So that makes the storage issue less of a
concern.

As for processing time, I have seen scanners that claim 75 ppm. So
therefore 9000 images would be 120 minutes. But I realize that adding
barcode reading is unrealistic at that speed. Still even if you halve
the speed, you still end up with a net rate of 37 ppm -- 4 hours of
processing. Which beats the current manual process of 14-15 manhours.
D
 
Does the barcode also have the actual numbers of the barcode under it?

If so,  OCR could be involved, to get that number from a scan into text;
and then it would be relatively easy to parse it out as the "title" of
the document with some other text/script tool?

MM- Hide quoted text -

- Show quoted text -
Click to expand...

Yes the text is there -- but I isnt reading the barcode more reliable?
 
Yes the text is there -- but I isnt reading the barcode more reliable?
Click to expand...

Dunno, depends.
Lots more options with text scanning OCR packages to database.
I suppose barcode reader hardware to database is just as viable. Not
sure which would prove to be faster/cheaper.

MM
 
D Lee said:
Actually, the storage database is transitory -- I do not need the
image data for long. I want to image the document, process it and
dispose of the image. So that makes the storage issue less of a
concern.

As for processing time, I have seen scanners that claim 75 ppm. So
therefore 9000 images would be 120 minutes. But I realize that adding
barcode reading is unrealistic at that speed. Still even if you halve
the speed, you still end up with a net rate of 37 ppm -- 4 hours of
processing. Which beats the current manual process of 14-15 manhours.
D
Click to expand...

http://www.oimaging.co.uk/ may do the software job.
 
Back
Top