Advice on imaging solution

[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?

 

[Neil Gould]

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?

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

Best regards,

 

[D Lee]

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

Best regards,

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

 

[Colin_D]

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?

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.

 

[Charlie Hoffpauir]

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

Doug,

Based on what I've read, it's not only feasible, but apparently
already in use in many locations, or at least something very similar.
Check out this (and related) products...
http://www.simpleindex.com/Features/barcode_recognition.asp

 

[Neil Gould]

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.

Tough question. It's technically possible, but I suspect that whether or
not it's feasible depends on many other factors.

Best,

 

[MoiMoi]

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

 

[D Lee]

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.

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

 

[D Lee]

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 -

Yes the text is there -- but I isnt reading the barcode more reliable?

 

[MoiMoi]

Yes the text is there -- but I isnt reading the barcode more reliable?

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

 

[dennis@home]

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

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