GB2168871A - Image run length coding and decoding - Google Patents

Abstract

A digitised video signal is compressed by a form of run-length coding which provides high definition edges and allows run-lengths to be at any video level. Portions of video at constant level are coded as a run-length code (at times t0, t2, t4) which is an 8 bit number with the most significant bit 1 and the remaining bits denoting the number of pixels in the run (up to t1, t3, etc). A special run-length code, all ones, denotes a run length to the end of the current line. At the end of a run, a pixel mode code (at t1, t3 etc) has most significant bit zero and the remaining bits denoting the number of ensuing pixel codes, such as codes 1 2 3 4 and 5 following t1. The pixel codes are any of the 8 bit numbers. The coded data is decoded by responding to a run-length code to maintain the digital values at the value established by the most recent pixel code for as many pixels as specified by the run-length code. On the other hand, when a pixel mode code is received the specified number of pixels are read out sequentially from the memory storing the compressed data. <IMAGE>

Description

SPECIFICATION Image run length coding and decoding The present invention relates to methods and apparatus for run length coding of image data and subsequent decoding thereof. Virtually all image data is highly redundant and run length coding is a well known technique for reducing the amount of data in a digitally coded representation of an image. For example, group 3 facsimile apparatus using a one dimensional coding scheme transmits black and white run length codes alternately. Schemes of this nature are suited to black and white transmissions of text and line drawings but are not suited to reproduction of high quality images with many intermediate tones.

The present invention is concerned in the first place with a method of run length coding which is suitable for handling high quality image material. Aithough the invention may be implemented in real time (subject to a processing delay of a few scanning lines) it is particularly useful for efficient storage of high volume, batch generated image data. By way of background to such an application, the present applicants contemplate generating a complex television symbol by combining two frames of colour information representing fixed foreground and background images with cyclically changing, high definition frames each of which is effectively digitized to 8-bit accuracy throughout 576 active picture lines, each having an active line width of 720 pixels.The frames sequence may consist of 600 frames and the amount of data to be stored would be impossibly vast on a direct pixel by pixel basis. Application of the present invention allows each frame to be stored within 8K bytes of EPROM memory, so that all 600 frames are stored in 4.8 M bytes.

According to the present invention there is provided a method of run length coding of digitized data representing pixel-by-pixel image densities of an image, wherein runs of constant density pixels are converted into first codes denoting the run lengths, and runs of changing density pixels are coded as corresponding pixel codes preceded by second codes, distinguishable from the first codes, and denoting the number of ensuing pixel codes.

Preferably, the density of each run of constant density pixels is denoted by the last preceding pixel code.

Effectively pixel and run-length modes alternate, distinguished by the second and first codes respectively. Within pixel mode the pixel codes do not have to be distinguished and so it is possible to use all available code combinations as pixel codes, one subset thereof as the first codes and a mutually exclusive second subset as the second codes. An example of a system using 8-bit codes (256 pixel codes) will be described. The second codes all have bit 7 (most significant bit) = 0 while the first codes all have bit 7 = 1.

Pixel mode This mode is defined by the following byte: Oppp pppp The 7-bit number, P = ppp pppp, specifies the number of pixels to be defined. It must be in the range of 0 to 127. The following P bytes will be read directly as pixel codes.

Using the pixel mode is the only way of defining levels in the system, since there is no 'command' byte for turning the image on or off.

It is important to note that for practical reasons of reading the data serially from memory a run-length of 1 pixel is implied before the pixel definitions. This is because 1 clock period is needed to read the pixel count P before the pixel data can be read to the output. In most cases this can be catered for by reducing a previous run-length by 1 pixel.

Run-length mode This mode is defined by the following byte: 1 rrr rrrr The seven bit number, R = rrr rrrr, defines the run-length required. It must be in the range 0 to 126 (note that 127 is not included). The number R will cause a run-length of R+1 for much the same reasons as the dummy pixel in 'pixel mode'.

Run-length mode does not define any particular level for the output data, it simply asks for a 'hold' for so many pixels. It will always hold the data defined by the last definition of the last pixel mode. This means that data does not need to be defined at the beginning of a line if it is to be the same as that at the end of the previous line. This will often be the case. It is worth noting that the data held can be at any level; it is not restricted to ON or OFF.

End of line The function "Continue to End of Line" (EOL) is defined by the following byte: 1111 1111 This byte appears like a run-length definition for 127 pixels, but in fact implies a total run to the end of the line. The data output will only be reset by blanking and the next line-start pulse. Exactly the same principles of holding the last pixel definition apply as for the run-length mode. This method means that a series of blank lines, for example at the top or bottom of the screen require only a single definition and can be followed by as many EOLs as required, one per line.

Example As an example consider the following requirement.

pixels 0 to 100 inc. - 0 pixels 10 to 104 inc. - 2, B, D, F pixels 105 to 300 inc. - F pixels 301 to 305 inc. - C, 9, 5, 3, 1 pixels 306 to 400 inc. - 1 pixels 401 to 719 inc. - 0 (till end of line) For the code we shall assume that the current level is already at 'O' The code needed in consecutive bytes in hex is as follows: E3 - RL def. for (99 + 1) pixels (RL def.= Run length definition) 04 - PX def. for 1 hold + 4 pixels (PX def.

Pixel Count definition) 02 - px data 1 = 2 (px data = pixel code) 08 - px data 2 = 8 OD - px data 3 = D OF - px data 4 = F (to be held) FE - RL def for (126+1) pixels C3 RL def for (67+1) pixels 05 - PX def for 1 hold + 5 pixels OC - px data 1 = C 09 - px data 2 = 9 05 - px data 3 = 5 03 - px data 4 = 3 01 - px data 5 = 1 (to be held) DD - RL def for (93+1) pixels 01 - PX def for 1 hold + pixel 00 - px data 1 = 0 FF - EOL - hold 0 til next line start.

Note that in general the atual hex code for a run-length is 2 less than required. This is because a run is always 1 greater than the code, and most runs are followed by Pixel definitions, which themselves generate a run of 1 to precede the pixel data.

The invention is moreover concerned with apparatus for decoding run length coded data generated by the method of the invention, as defined in claim 6 below.

The invention will be described in more detail by way of example with reference to the accompanying drawings in which: Figure 1 shows diagrams contrasting conventional run-length coding with coding according to the invention, Figure 2 is a schematic diagram of apparatus for effecting the run-length coding according to the invention, Figure 3 is a flow chart for the coding algorithm, Figure 4 is a block diagram of apparatus for decoding the data, and Figure 5 is a more detailed block diagram of part of the apparatus.

Figure 1(a) illustrates conventional run-length coding in which it is only possible to code a black and white, two-level video waveform into run lengths codes denoting the lengths of alternating "ON" and "OFF" intervals corresponding to black and white respectively. As illustrated, a first run-length code specifies white level from to up to t1 a second run-length code specifies black level from t, up to t2 and so on. In contrast to this, Figure 1(b) illustrates application of the invention to code a quantised video waveform representing a whole range of tones from black to white. It is assumed that the waveform is initially at a constant, low level and this is specified by a run-length code at to.At t1, one clock period before the end of the run, a code is given commanding pixel mode and specifying the number of pixels to follow, here illustrated as five pixels labelled 1 to 5. The levels of these pixels are given by five pixel codes. The fifth pixel is actually the first part of a run at a new level, specified by a run-length code at t2. At t3 an other pixel mode code is given, specifying just two pixels. At t4 another run-length code is given. It will be seen that run lengths can be at any arbitrary level, as specified by the last preceding pixel code.

Moreover, the run-length has to be specified as two pixels shorter than the actual run length because the first pixel of the run is given by the last pixel code and the last pixel of the run arises automatically in the clock period occupied by the pixel mode code.

The apparatus required to code data by the method according to the invention is illustrated in Figure 2 and comprises a pixel data store 10, a computer 11 which operates on the data in accordance with an algorithm described below, and a coded data store 12 receiving the data from the computer as coded by the use of the algorithm. The pixel data store is a memory mapped store containing the digital pixel value for every one of the pixels in an image frame.

The algorithm performed by the computer is illustrated in Figure 3. Initially (test 13) the computer tests to see whether data repeats until the end of the line. Since the store 10 is memory mapped, it is very simple for the computer to perform this test by checking to see whether the stored values are constant up until the last value in the current line in the store 10. If the test is met, the EOL code already described above is written into the next location in the store 12 and the computer proceeds to test the next line in the store 10. After sending the EOL code (block 14) a test 15 is made to see if the last line has been processed/ if not, the algorithm goes back to its initial point again.

If the test 13 is not met, a test 16 is made to determine if there is a data repeat of at least four pixels.

This merely consists in testing four consecutive memory positions in the store 10 for equality. If the test is met, the computer counts the number of consecutive memory locations containing the same value (block 17) and then sends to the store 12 the corresponding RL code or codes. More than one RL code will be required if the run-length value exceeds 126. After sending the RL code or codes (block 18) the computer goes back to test 13. When both test 13 and test 16 fail, the computer counts memory locations in the store 10 (block 19) until either it finds four consecutive locations holding the same value or it comes to the end of the current line.The computer then sends to the store 12 firsstly a PX code identify ing the number of pixels counted (block 20) and then the data stream (block 21) consisting of the specified number of pixel codes themselves, which are simply copied serially from the store 10 to the store 12. The algorithm then reverts to the test 13.

It is clear that, unlike the store 10, the store 12 is not memory mapped. It has to be regarded simply as a continuous serial store whose contents become meaningful only when decoded by the apparatus to be described below. In order to provide an aminated display, the data in the pixel store 10 can be repeatedly processed and then subjected to the algorithm described above to create a succession of coded frames in the data store, e.g. 600 frames for the example already mentioned above.

Turning then to the apparatus illustrated in Figure 4, each coded frame is allocated 8K bytes of a 4.8 M byte sequence memory 22 utilising 16K EPROMs arranged on ten store cards, each accommodating 32 of the EPROMs. The memory 22 can be regarded as composed of 8K pages, each of which is capable of storing one coded frame (although the actual length of a coded frame is variable). The data in the memory 22 is utilised in conjunction with data in a fixed memory 23 storing both a foreground frame and a background frame in full colour. For convenience, the EBU digital format is used with the video signal sampled as three separate components, Y, Cb and Cr, each digitised to 8 bit accuracy. Cb and Cr are similar to the PAL signals U and V. The luminance signal Y is sampled at 13.5 MHz and each of the chrominance signals at 6.75 MHz.In EBU format, the digital signals are multiplexed into a 27 MHz data stream of the form CB Y Cr Y Cb Y Cr. However, in the memory 23 the luminance and chrominance samples are stored in parallel and clocked out at 13.5 MHz. One of the aforementioned store cards, populated with 28 EPROMs, is used for each of the foreground luminance FG - Y, the foreground chrominance FG - C (Cb and Cr alternating), the background luminance BG - Y and the background chrominance BG C.

Basic operation of the apparatus is as follows. The contents of the four cards of the fixed memory 23 are read out in parallel during every field period. A controller 24 provides a 19 bit address to all cards of the fixed memory and this address is incremented once for every clock period during the active portion of each line. A clock generator 25 is provided with standard mixed syncs input and generates a 13.5 MHz two phase clock signal, line start and field start pulses LS and FS and a signal O/E distinguishing between odd and even frames. The controller 24 also supplies a 24 bit address to the sequence memory 22.

This address selects the correct 8K page within the memory 22 and is incremented as required and as explained in more detail below to read out data to the controller 24 which decodes the data and provides 8 bit output data on a cable 26. This data is the decoded digital data representing the original image pixel by pixel. For the purposes of the present embodiment the data is interpreted as two 4 bit keys used to control multiplication of the foreground and background luminance components in a multiplier 27. The four most significant bits are used as the foreground key and the least significant bits are the background key. Within the multiplier 27, the keys are decoded by PROMs to produce 8 bit background and foreground multipliers. The signals from the multipliers are fed to a combiner 28 which adds the background and foreground luminance signals from the multiplier and adds the foreground and background chromi nance signals. Luminance and chrominance are blanked to appropriate levels during line blanking and field blanking intervals under control of a digital mixed blanking signal DMB from the controller 24. Finally the chrominance signal Cb, Cr, Cb . . is demultiplexed. The resulting luminance and two chrominance signals are applied to a three channel digital to analog converter 29 and thence to a matrix 30 which provides R, G and B colour signals.

Figure 5 is a more detailed diagram of the controller 24. Various items receive the 13.5 MHz clock CK, including a timing circuit 31 which also receives the sync information LS, FS and O/E and generates the DMB signal. The timing circuit 31 also controls an address generator 32 which incorporates a 19 bit counter for the fixed address, which is reset at the beginning of each field and incremented during every clock period, except during line and field blanking intervals. The address generator 32 also includes a frame counter providing the most significant bits of the 24 bit sequence address so as to address the correct 8K page within the sequence memory 22. Within the selected page, the addresses advance in an irregular manner. as determined by the data read out from the memory.

The data is fed to a buffer and latch circuit 33 which can furnish the data to a decoder PROM 34, a counter 35 and an output register 36. This register provides the decoded output on the line 26. The heart of the controller is the decoder PROM 34 which is a PROM coded to act as a customised logic array. The decoder 34 respond to the code in the circuit 33, a signal from the timing circuit 31, a signal from the counter 35 and its own state to provide signals on lines 37, 38 and 39. The signal on the line 37 determines whether or not data is clocked from the circuit 33 to the output register 36. The signal on the line 38 is a HOLD signal used to inhibit read-out from the sequence memory 22 during run mode. The signal on the line 39 is fed to the address generator 32 to inhibit any change of the sequence address during run mode.

Operation of the controller is as follows. Assume firstly that a run-length code is held in the buffer and latch 33. The decoder 34 responds by freezing the current code in the output register 36 and preventing further readout from the sequence memory 22 by the signals on the lines 38 and 39. The current sequence address within the address generator 32 is frozen. The seven least significant bits of the run length code are transferred to the counter 35 which is enabled to count down the run-length in response to the clock pulses Ck. The counter signals to the decoder 34 when its contents reach zero. The decoder then allows the next byte to be read from the sequence memory 22 into the buffer and latch 33. If this is another run-length code, the same sequence of operations is repeated.On the other hand, if it is a pixel definition code the seven least significant bites are again transferred to the counter 35 but the address generator 12 and sequence memory 22 are enabled to transfer pixel codes into the buffer and latch circuit 33 and thence into the output register 36. The counter 35 is again enabled to count down and, when the number in the counter 35 reaches zero, the decoder 34 is enabled to interpret the next code as a runlength code or a pixel count code.

If a run-length code is the EOL code, the decoder 34 ignores the counter 35 and terminates the current run only at the end of the current line, as signalled from the timing circuit 31. All of the functions of the decoder 34 are straightforward logical functions'of the inputs thereto. These inputs are treated as addresses and, for every possible address, the contents of the PROM are programmed to provide the required combination of output signals. The decoder PROM 34 may be a TBP 28 S42 device with eight address inputs and eight data outputs.In a practical implementation, of the eight address inputs, one may be the most significant bit from the buffer and latch 33 (for distinguishing run-length and pixel count codes), one may be a signal from the counter 35 (or a decoder connected thereto) to signal when the counter is empty, one may be an EOL signal provided by a gate connected to the buffer and latch 33 to decode the value 11111111, one may be a line sync signal from the timing circuit 31 and say three may be latched outputs fed back from the decoder PROM itself.

The overall principle of operation will be readily understood. In run-length mode, the contents of the output register 36 are frozen for the requisite number of clock pulses counted by the counter 35 (or until end of line) and the sequence address also remains frozen. During pixel mode, the sequence address advances and values are clocked out of the sequence memory 22 firstly into the buffer and latch 34 and thence into the output register 36.

Claims (6)

1. A method of run length coding of digitized data representing pixel-by-pixel image densities of an image, wherein runs of constant density pixels are converted into first codes denoting the run lengths, and runs of changing density pixels are coded as corresponding pixel codes preceded by second codes, distinguishable from the first codes, and denoting the number of ensuing pixel codes.

2. A method according to claim 1, wherein the density of each run of constant density pixels is denoted by the last preceding pixel code.

3. A method according to claim 1 or 2, wherein the pixels pertain to a raster of scanning lines and runs of constant density up to the end of a line are denoted by a specific one of the first codes, regardless of the run length.

4. A method according to claim 3, wherein successive lines of constant density are coded solely as a succession of repeats of the said specific first code.

5. A method according to any of claims 1 to 4, wherein the first and second codes are mutually exclusive sub-sets of the pixel codes.

6. Apparatus for decoding run-length coded data generated by the method of claim 1, comprising a memory for storing the first and second codes and pixel codes, an output register, a source of clock pulses, a counter and control means responsive to each first code to inhibit read-out from the memory and to hold the contents of the output register for a number of clock pulses determined by the first code and responsive to each second code to enable read-out from the memory to the output register for a number of clock pulses determined by the second code.