These and other more detailed and specific features of the present invention are more fully disclosed in the following specification, reference being had to the accompanying drawings, in which:
In the following description, for purposes of explanation, numerous details are set forth, such as flowcharts and system configurations, in order to provide an understanding of one or more embodiments of the present invention. However, it is and will be apparent to one skilled in the art that these specific details are not required in order to practice the present invention.
In one embodiment, the present invention is implemented in a document processing system 10, as shown in
As known in the art, a conventional document processing system 10 includes transport hardware 11 with various processing options. The various processing options, when installed, become an integral part of that system's transport mechanism. As the document passes through one of the installed subsystems, the hardware for that installed subsystem performs whatever function it was designed to perform.
Operationally, documents are physically processed through the transport hardware 11 of the document processor under the control of track control PC 12. Track control PC 12 provides sorter control of the document transport hardware 11, and includes track applications, such as inclearings, proof of deposit, and remittance operations, and operating system software, which in one embodiment is WINDOWS NT®, WINDOWS 2000®, or WINDOWS XP®-based system software. Other embodiments may use operating systems including but not limited to UNIX, Mac OS and proprietary operating systems. The system software also may include Unisys Common Application Programming Interface, or CAPI, which is an application programming interface that enables the same application software to be used across multiple transport platforms. The image capture subsystem 13 provides image server and capture capabilities and interfaces with the document transport hardware 11 to receive images moved by document transport and to store them in appropriate files 14 (e.g., FIM, RIM, FI2, RI2). The image capture subsystem 13 generally comprises both hardware and software, including imaging module hardware 15, having a camera subsystem for capturing images, and an image capture server (ICS) PC 16 for processing and storing the images. The details of the document processing system 10 can have various forms, such as those described in U.S. Pat. No. 7,167,580 assigned to Unisys Corporation.
The image capture subsystem 13 of the document processing system 10 shown in
Light reflected off of the document moving in the track 11 is reflected back and input to the image lift function 21. The image lift function 21 serves two basic functions. First it converts the light input reflected from the document into the camera subsystem into analog electrical signals and then digitizes them into a digital number representative of the physical brightness of an individual pixel. For example, 0 may represent pure black; 255 may represent pure white; and 1 thru 254 may represent various shades of gray that correspond to the light/darkness of an individual pixel. A scanned document will include a large number of such pixels. As an example, a document that is physically 6 inches wide by 3 inches tall when scanned at 200 dots per inch will consist of 6×200×3×200=720,000 pixels. In one embodiment, the image lift function 21 can be performed by a camera subsystem, which may be implemented in a camera printed circuit board.
It will be appreciated that the image capture subsystem 13 may not have a priori knowledge of the actual size of the document or exactly when it will pass through the document processing system 10. This is a second functionality that the image lift function 21 provides; that is, the image lift function 21 performs a document framing function. Document framing includes finding the right and left bounds of the document as it passes in front of the camera. For example, if a document is moving through the document track 11 and passing horizontally in front of a vertically oriented scanner used to detect the light level reflected back into the image lift function 21, the scanner should be physically tall enough to capture light from the tallest possible document that the document processing system 10 is designed to accommodate. However, it is not until the entire document has physically passed in front of the scanner that the image capture subsystem 13 is able to fully define the outermost boundaries of the electronic representation of the image. For this reason, the image lift function 21 typically has some form of memory storage, depicted in
After the image data has been stored in the memory 22, the processor function, depicted in
The memory 22 may comprise a memory integrated circuit having memory cells arranged in pages, such as a paged, DDR SDRAM (double-data-rate synchronous dynamic random access memory). Although DDR SDRAM is preferred, other examples of paged memory may include fast paged mode DRAM and EDO DRAM.
The DDR memory 22 in this embodiment has a page width of 2K (i.e., 2048 bytes) and the expected, maximum pixel width of the image, M, is 2K or greater. If no changes were made to the conventional transposition algorithm, every pixel written to the DDR memory 22 during capture would incur a page hit, while there would be excessive performance margins on the READ side where relatively no page hits occur. To balance this situation, during transposition the image processor partitions an M×N area of the memory 22 into a plurality of column groups, with each column group comprising a plurality of columns (e.g., 256 columns per group).
Control circuitry used to route pixel data from the Image Lift (21) to Memory (22) is designed in logic and may be implemented in an FPGA (Field Programmable Gate Array). The partitioning logic variously described herein is executed by controlling the memory write and memory read addressing. Write and read addresses are then routed to the DDR SDRAM controller, which may also be implemented in the FPGA, to store and fetch pixel data from the paged DDR.
Write Operation. Referring to
Read Operation. According to this embodiment, rows no longer consist of 2048 consecutive pixels. Instead, the rows are arranged in 8 groups of 256 consecutive pixels with gaps of 256xN (x40000) between each group. Therefore, the READ portion of the transposition scheme can fetch 256 pixels before incurring DDR page hits, instead of being able to get all 2048 pixels in a row without penalty. Even though this would appear to be a READ performance degradation as compared to traditional schemes, the memory (with the transposition scheme) implemented according to this embodiment can still extract data faster than downstream image scaling and compression can process this data. Therefore, such READ performance degradation will not typically impose a negative affect on overall system performance. Also, the transposition scheme provides significant performance relief on the WRITE side at the minimal expense of READ performance, by offloading some of the WRITE side paging overhead to the READ side until desired system performance is achieved. Since the READ side paging already had significant margin to spare, there is minimal effect on system performance.
The WRITE performance can be increased even further by partitioning the M (=2048)×N (=1024) section of memory into sixteen, 128-column groups. With that configuration, bursts of sixteen pixels can be WRITTEN into DDR without crossing page boundaries. In some circumstances, 256 column groups will offer the best solution for the image processing system. Different systems having different memory configurations, scanning parameters, or other characteristics may dictate alternative partitioning parameters. Also, it is again noted that although this embodiment partitions a 2048x1024 section of memory other sizes may of course be provided. The ordinarily skilled artisan will readily recognize, or, through simulation or the like, may readily optimize partitioning for any system and any sectioning of memory.
Determining Top Left Pointer Location. In one embodiment, the data from the scan system is put into memory in a fashion that allows the system to achieve a higher throughput than a system that does not employ the column group approach. The control processor 16 in the system 10 is able to pull out the portion of the scanned image in the memory 22 that is of interest. This will be the full document from edge to edge with any overscan required to allow downstream image functions like scaling and compression to work properly. The hardware can be set to fill extra scan lines (e.g., 40 lines) after the document to allow these downstream image functions to work on up to 40 pixel wide boundaries.
The direction of scan influences the reference pointer to determine the left corner of the transposed image to be compressed. When the scanning is done in the left to right direction, the upper left corner of the image memory is located at the top of the first column group. When scanning in the right to left direction, the upper left corner of the image memory is found in the last column group within 256 bytes of the end. This depends on the number of columns in the image. The desired top location can be moved to the location corresponding to the top row of the image by the calculation below:
TopLeftDesired=PtrMaxTopLeftLocation−(ColumnGroupWidth*((MaxHeightN−1)−TopRowOfImage)
The following additional calculations may be used to calculate the actual pointer to the left corner of the image to be compressed in the right to left direction. From this pointer location, the pointer is moved the appropriate number of columns to skip over any data which is not part of the desired image as a result of hardware data overscan.
The difference in width between the actual width captured and the desired image width is calculated as follows:
WidthDifference=TotalCapturedWidth—DesiredImageWidth
This width difference will modify the TopLeftDesired position in one of two ways. These two ways depend on the amount of columns in the last column group after the entire image has been captured. The formula for determining this value is:
The remainder of:(TotalCaptureWidth−1)/ColumnGroupWidth Or, simply, (TotalCaptureWidth−1)&(ColumnGroupWidth−1)
If this value is less than or equal to the WidthDifference, then an entire column group needs to be moved, and the pointer needs to be positioned in this column group. The TopLeftDesired position would be moved to the right by the formula:
TopLeftDesired=TopLeftDesired+((ColumnGroupWidth*MaxHeightN) (ColumnGroupWidth−1)+WidthDifference)
Otherwise the pointer is just moved by the amount of the width difference:
TopLeftDesired=TopLeftDesired+WidthDifference
In one embodiment, the DDR is a Micron 512 Mb DDR SDRAM, commercially available from Micron Technologies, and the DDR core/controller is a DDR2 SDRAM Controller Version 3.2.1 from the Megacore IP Library, which is downloadable from Altera Corporation. The paging performance using the Micron DDR and Altera IP DDR controller, based on simulation, is as follows:
1) Micron DDR performance, 9 clock cycles of overhead for every Double word (32 bits) Read or Write on a new, 2K page; and,
2) Micron DDR performance, 1 clock cycle for every Double word (32 bits) Read or Write within a 2K page.
In an imaging system using the conventional transposition scheme, a raster scanned image was READ from memory in MAX_WIDTH, horizontal rows (every 2048 pixels in a MAX_WIDTH row are on the same DDR page). The performance was as follows:
WRITE SIDE 9 CYCLE, PAGING OVERHEAD—once for every 1 WRITE to DDR; and
READ SIDE 9 CYCLE, PAGING OVERHEAD—once for every 2048 READS from DDR.
In an imaging system using the transposition scheme, a vertically scanned image can be captured and written into memory in 256 address increments (every 8 writes cross a DDR page boundary), and the raster scanned image can be READ from memory in MAX_WIDTH, horizontal rows (every 256 pixels in a MAX_WIDTH row are on the same DDR page). The following performance can be achieved:
WRITE SIDE 9 CYCLE, PAGING OVERHEAD—once for every 8 WRITE to DDR
READ SIDE 9 CYCLE, PAGING OVERHEAD—once for every 256 READS from DDR
In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the present invention. One skilled in the relevant art will recognize, however, that an embodiment of the invention can be practiced without one or more of the specific details, or with other apparatus, systems, assemblies, methods, components, materials, parts, and/or the like. In other instances, well-known structures, materials, or operations are not specifically illustrated or described in detail to avoid obscuring aspects of embodiments of the present invention.
The embodiments of the present invention produce and provide systems and methods for capturing and transposing vertically scanned documents in an imaging system. Although the present invention has been described in considerable detail with reference to certain embodiments thereof, the invention may be variously embodied without departing from the spirit or scope of the invention. Therefore, the following claims should not be limited to the description of the embodiments contained herein in any way.
This application claims priority from U.S. Provisional Patent Application Ser. No. 60/795,863, entitled SYSTEM AND METHOD FOR CAPTURING AND TRANSPOSING VERTICALLY SCANNED DOCUMENTS IN AN IMAGING SYSTEM, filed on Apr. 28, 2006, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60795863 | Apr 2006 | US |