Browse Prior Art Database

Data Compression Coding for Character Video Transmission

IP.com Disclosure Number: IPCOM000075239D
Original Publication Date: 1971-Aug-01
Included in the Prior Art Database: 2005-Feb-24
Document File: 3 page(s) / 39K

Publishing Venue

IBM

Related People

Atrubin, AJ: AUTHOR [+2]

Abstract

It is frequently desirable to transmit video data from a scanner to a character-recognition unit in a compressed code, to reduce the transmission bandwidth. It is also desirable that a zero-distortion code be employed, so that the scanned pattern may be exactly reconstructed by the recognition unit.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 41% of the total text.

Page 1 of 3

Data Compression Coding for Character Video Transmission

It is frequently desirable to transmit video data from a scanner to a character-recognition unit in a compressed code, to reduce the transmission bandwidth. It is also desirable that a zero-distortion code be employed, so that the scanned pattern may be exactly reconstructed by the recognition unit.

System 10 accomplishes these objectives by a combination of variable-length (Huffman) encoded run-lengths for statistically more probable video run lengths, and directly encoded run lengths for less probable run lengths, using a special bit combination in each code form to signal a change to the other form. Separate, temporally alternating, Huffman codes are used for black and white video, each code being independently optimized for its particular color.

Successive video bits on line 11 enter load control 12 in run sequences of from 1 to 63 bits of the same color, black or white.

The length of the current sequence is determined by six-place binary counter 13, and its color entered as a single bit in B/W register 14.

A type register 15 may also hold a bit to provide an indication of the type of characters being read, e.g., machine-printed or handwritten. The bits stored in units 13-15 are entered into asynchronous buffer memory 16 for successive run sequences, and are then unloaded in the same order to encoder 17 and gates 18.

Each 8-bit byte from buffer 16 accesses a table location in an encoder such as read-only memory (ROM) 17, if this byte specifies a run length which is to be transformed to a Huffman code. The code stored at that location is then sent through gates 18 to output register 19 for serial transmission over output line 20. The length of the code at that location is also stored in ROM 17, and is transmitted through gates 18 to length register 21, and a "Huffman mode" bit is sent to code-load control 22. As each bit is shifted from output register 19 to line 20, the contents of register 21 are decremented; when a zero count is reached, control 22 causes buffer 16 to shift the next byte to ROM 17 and gates 18. If a byte from buffer 16 does not specify a valid address of ROM 17, the Huffman- mode bit will not be generated, and control 22 causes the 6-bit length to be sent directly from buffer 16 through gates 18, to generate a 7-bit direct run-length code in output register 19, and to place a code length of seven into register 21. Control 22 also compares the values of the Huffman-code bit for successive data bytes, and generates in registers 19 and 21 the code-change bit combinations and their lengths, whenever the coding scheme changes from Huffman to run- length or vice versa. Control 22 also generates an initializing code for each video pattern, a special code sequence for direct codes representing different colors, and another special code sequence for patterns which begin in black video, since system 10 assumes that the first data code for each pattern represents...