WO2001008410A1

WO2001008410A1 - Graphics transcoding scheme for efficient decoding on digital settop decoder

Info

Publication number: WO2001008410A1
Application number: PCT/US1999/017002
Authority: WO
Inventors: Mario Rainville
Original assignee: Morecom, Inc.
Priority date: 1999-07-27
Filing date: 1999-07-27
Publication date: 2001-02-01
Also published as: AU5235199A

Abstract

An encoded graphics image is decoded at the headend of a cable television system, and retransmitted in decoded form or transcoded form to the settop. In one embodiment, the encoded graphic image is converted to a bit map at the headend, and the bit mapped image is transmitted to the settop. In a second embodiment of the present invention, the encoded graphics image is transcoded at the headend, into an alternate file format that is transmitted over the cable network to the settop. The alternate file format is a modified run length encoding which allows the settop to use the color expander feature of its graphics engine to decode and render the graphics file. The settop processor streams the incoming modified run length encoded file format to the color expander of the graphics engine, and the graphics engine performs all other image decoding operations.

Description

GRAPHICS TRANSCODING SCHEME FOR EFFICIENT DECODING ON DIGITAL SETTOP DECODER

Field of the invention

The present invention relates to improving the efficiency of decoding and rendering graphic images such as GIF (Graphics Interchange Format) images in a digital settop decoder.

Background of the invention

Cable television providers are upgrading their networks to digital format to deliver video transmission in digital form. The conversion of cable television systems to digital transmission systems presents an opportunity to make high speed Internet access available to cable TV subscribers over the digital settop box.

However, many of the commercially available digital settops use programmable microprocessors with limited processing capabilities. Typically, a settop box may use a low cost, low performance microprocessor. While those type processors are adequate for simple graphics applications such as implementing an electronic program guide, the limited processing capabilities of such processors cause Internet access to be sluggish, frequently requiring long waits by Internet users browsing the world wide web. It would be desirable to implement a world wide web Internet browser in a digital settop box based on such less powerful microprocessors.

One reason for the slow response of low end processors is the computational burden of decoding graphic images. One type of graphics image format, i.e., the Graphic Interchange Format, or GIF, is a well known graphic image format widely used for image compression on the Internet. The majority of today's WEB content is based on GIF compression for graphics images.

The GIF image format is a compromise between the data compression ratio and the processing power required for decoding. Still, decoding a GIF image requires a substantial amount of computing power. In particular, the GIF format uses Lempe-Ziv (LZW) variable run length encoding. The limited processing capability of low end microprocessors used in many cable television converters and digital settop boxes precludes fast and efficient decoding of LZW encoded GIF images. The resulting GIF decoding bottleneck frequently causes delays, requiring long waits by the Internet users browsing the world wide web, in order to view downloaded images.

Summary of the invention

The present invention is embodied in a method and apparatus for decoding a graphic image at the headend of the cable television system, and retransmitting the image in decoded form or transcoded form to the settop.

In one embodiment, the graphic image is converted to bit map form at the headend, and the bit mapped image is transmitted to the settop. Since the headend processing power is substantially greater than that of the settop, graphic image decoding speed is improved. The loss of data compression caused by decoding at the headend before transmission, does not substantially affect CATV system speed because the loss of data compression is compensated to some extent by the substantial bandwidth of the cable system.

In a second embodiment of the present invention, a graphic image is transcoded at the headend, into an alternate file format that is transmitted over the cable network to the settop. The alternate file format is a modified run length encoding which allows the settop to use the color expander feature of its graphics engine to decode and render the graphics file.

The settop processor need only stream the incoming modified run length encoded file format to the color expander of the graphics engine, and the graphics engine performs all other operations. In such manner, the compromise between the data compression ratio, and the required decoder processor power is optimized for the capability available in the settop box. By using modified run length encoding, the decoding and rendering is performed by dedicated hardware which is widely available on graphics devices in the industry.

Since the color expander is used for graphics image decoding of modified run length encoded images, the central processing unit in the digital settop box is available for other tasks. In addition, since the method does not involve the digital settop box's MPEG2 audio/video decoder, it is then possible to simultaneously display MPEG-2 digital video and decode graphics images .

Description of the figures

Figure 1 is a block diagram of a prior art cable TV system and digital settop box. Figure 2 is a block diagram of a cable TV system and digital settop box in accordance with a first embodiment of the present invention.

Figure 3 is a block diagram of a cable TV system and digital settop box in accordance with a second embodiment of the present invention.

Figure 4 is a program flow chart of the encoding process in a headend transcoder embodying the present invention

Figure 5 is a simplified logic diagram, of a color expander used in conjunction with the present invention.

Figure 6 is a flow chart diagram of a color expander rendering process.

Figure 7 is a flow chart diagram of the main decoder algorithm in accordance with the present invention

Figure 8 is an illustration of the alternate file format of a modified run length encoded image in accordance with the present invention.

Detailed description

Typically, in the prior art, as shown in figure 1, an encoded graphics image file 10 (in this case a GIF encoded image file) , is transmitted over a cable television (CATV) system to a digital settop 14 located at the subscriber location. The GIF image file 10 may be obtained at the headend via a connection (not shown) between the cable television system and the Internet. As used herein, the transmission medium of a CATV system is intended to include, without limitation, all wired communications systems, such as via fiber optics, as well as all wireless communications systems, such as microwave multipoint distribution systems (MMDS) .

In the settop 14, a local processor 16 (central processing unit or microprocessor) decodes the GIF encoded image and stores the resulting bit mapped image in graphics memory 20. The settop display subsystem 22 formats the bit mapped image in graphics memory 20 into an analog video signal (such as NTSC or PAL) for display on a standard television set 24. Also contained in the digital settop 14 is a graphics engine 18, used for other purposes, such as for text to overlay on the screen of television 24.

As indicated, decoding a GIF image places substantial burdens on the local processor 16. Accordingly, GIF image decoding will be slower than desired.

In figure 2, the headend processor (at the CATV headend 26), decodes the received GIF file into a bit map file 28 for transmission on the CATV system 12. In such case, the greater processor power available in the headend 26 decodes a GIF file more quickly than would be the case for the more limited processor 16 in the digital settop 14. Since there is one headend 26 shared by many subscribers, the benefit of headend GIF decoding inures to the benefit of all settops in the CATV system. The tradeoff for requiring less processing power is a need for increased bandwidth. However, the CATV system 12 may use more of its bandwidth to accommodate transmission of the fully decoded and bit mapped GIF image file 28.

The headend 26 includes a receiver, which may be a telephone modem, for receiving a GIF image file 10. The headend 26 also includes appropriate transmitters and modulators to flexibly format and transmit the bit mapped image file 28, either relatively slowly in a low bandwidth channel, or extremely quickly in a very high bandwidth channel or somewhere in between, to strike a compromise between file transfer speed and utilization of CATV system 12 bandwidth resource.

Meanwhile, at the settop 14 in figure 2, the local processor 16 need only stream the received bit mapped image file 28 to the graphics memory 20. As before, the settop display subsystem 22 formats the bit mapped image in the graphics memory 20 into an analog video signal (such as NTSC or PAL) for display on a standard television set 24.

A system using a modified run length code to transcode the GIF file is shown in figure 3. Headend processor (at the headend 30) receives the GIF file 10 and transcodes it into a modified run length encoded file 32 for transmission over the CATV network 12. Although the received file 10 is shown as a GIF encoded file, the present invention may be used with any encoded format graphics file.

At the digital settop 14, the received modified run length encoded file is streamed by the local processor 16 to the graphics engine 18, which is normally available in the settop for other purposes. The encoding process which transcodes the modified run length encoded file 32, is described below in conjunction with figures 4, and 8. The decoding which renders the modified run length encoded file 32 is described below in conjunction with figures 5, 6 and 7.

Encoding process (figures 4 and 8)

In the decoding and transcoding process, the variable length LZW codes from the GIF format are replaced with fixed length codes. The transcoding process allows the target system' s color expander engine to be used for decompression and rendering. The use of the local color expander in the settop graphics engine reduces the amount of processing required by the target system's Central Processing Unit (CPU). The encoding process is shown in figure 4.

The general GIF file format is maintained, except for the following changes:

1) The signature field replaced from "GIF" to "MOR" to signify a modified run length encoded format according to the present invention (step 410 in figure 4)

n) The revision field replaced with the current encoder revision designation (step 414 m figure 4).

in) Global Look Up Color Tables (GCT) and Local Look Up Color Tables (LCT) converted according to the target system format (from RGB888 to RGB555, .e., from 8 bit to 5 bit Red, Green, Blue format as in steps 418 and 424 in figure 4).

V) The variable length LZW codes are replaced by fixed length codes m accordance with the format described n Table 1, below (steps 430, 432, 434, 436 in figure 4).

In figure 4, an input GIF file 400 is examined field by field, at step 402 where each next field is fetched. If the next field is an end of file field at step 404, the encoder program closes the data output stream at 406. Otherwise, the next field is examined at step 408.

If the next field is a signature field, the encoder program writes the encoder signature, "MOR" to the output stream at step 410, and the processing continues by fetching the subsequent input field at step 402. Otherwise, the presently fetched field is further examined at step 412.

If the next field is a version field, the encoder program writes the encoder version number of the present version of the encoder program to the output stream at step 414, and the processing continues by fetching the subsequent input field at step 402. Otherwise, the presently fetched field is further examined at step 416.

If the next field is a global color table (GCT) field, the encoder program converts the GCT from 8 bit format (256 gray shade values for each of red, green and blue) to 5 bit format (32 gray shade values for each of red, green and blue), at step 418, and writes the converted GCT to the output stream at step 420. Conversion from 8 bit to 5 bit consists of dropping the 3 least significant bits. The latter color reduction method is selected for its simplicity. However, other, more complex methods for reducing the number of bits in the color representation may be used. The processing continues by fetching the subsequent input field at step 402. Otherwise, if the next field is not a GCT field, the presently fetched field is further examined at step 422.

If the next field is a local color table (LCT) field, the encoder program converts the GCT from 8 bit format to 5 bit format at step 424, writes the converted GCT to the output stream at step 426, and the processing continues by fetching the subsequent input field at step 402. Otherwise, if the next field is not an LCT field, the presently fetched field is further examined at step 428. Conversion of the GCT and LCT at the headend encoder saves processing steps at the settop.

If the next field is an LZW field, the encoder program decodes the LZW encoding 430 of the GIF input stream to form a fully decoded pixel map 432 of the GIF input image. The bit mapped image 432 is then re-encoded (transcoded) as a modified run length encoded image 434. The compressed data 434 from the re-encoding process is written to the output stream at step 436, and the processing continues by fetching the subsequent input field at step 402. Otherwise, the presently fetched field is kept intact and written to the output stream at step 438. Processing continues at step 402 until the end of file is encountered at step 406

The format of the compressed stream syntax of the modified run length encoded image file is illustrated in figure 8, and further detailed in Tables 1 and 2 below.

As shown in figure 8, the first field is a byte count (expressed in a fixed length 4 byte field) for the entire message. Thus, the decoder knows in advance how many bytes will define the image.

The next two fields, by way of illustration, comprise a run length encoded pair, i.e., Code 100 and Value 1. The interpretation of a the Code/Value pair is that the pixel Value 1 is to be repeated 100 times. The run length encoded pair (Code/Value) may be followed by another encoded pair having any Code between 1 and 250, and any pixel Value within the pixel range. The Code 0 is reserved for a transparent pixel. The remaining 5 Code values between 251 and 255 are reserved for sequences of single pixels between 4 and 8 bytes long. In particular, for the Code value of 255 in figure 8, the next 4 bytes (1.1, 1.2, 1.3, 1.4) are 4 colors for 4 different pixels in a row. The foregoing is an illustrative example only. In general, the coding for any specific image may be different from the this example. The specific illustration of data types in figure 8 is generalized in the tables 1 and 2 below.

Table 1 Compressed data format

Each Code in the table is followed by 1 to m Values. The variable m is determined by the value of each Code as described in Table 2

BYTECOUNT: Number Code <31:0>

The byte count is the total number of bytes in the coming sequence excluding the byte count field. The total is n. Since the code-value is not always a one to one relation, the number of bytes is not always two times the number of codes.

Code n

The CODE field specifies the meaning of subsequent Value fields.

Table 2 Code field description

Note 1:

Extended compression codes are used to improve the compression ratio of the file under conditions where fixed code run length encoding is not efficient, such as when there many successive different pixels in the input stream.

For example, Code 255 means that the next 4 bytes are for 4 different single pixels in a row. If the 4 different pixels were encoded using run length encoding it would require 8 bytes (4 Values and 4 byte counts) . However, by using a unique expansion code just for the situation where 4 different pixel are in a row, only 5 bytes are required to encode the image, i.e., one dedicated Code = 255, followed by the 4 different pixel values, thereby saving 3 data bytes over what run length encoding could achieve .

By similar analysis, the use of extended compression codes (254, 253, 252, and 251) for 5, 6, 7 and 8 different single pixels in a row, results in data savings of 4, 5, 6 or 7 bytes respectively. In practice, most of the savings occur in situations where 4 to 6 bytes occur as different single pixels in a row.

Value n

Table 3 Value field description

Decoding process

As indicated, the encoding process is designed to take advantage of the color expander feature of the target decoder. Using the present modified run length encoded format, the local processor does not have to modify or process the received data. Instead, the local processor in the settop merely needs to stream the received data to the color expander as the graphics engine.

COLOR EXPANSION PROCESS

Figure 5 illustrates a simplified block diagram of a color expander. The color expansion process is traditionally used for text rendering. The present modified run length encoded format is a compressed format that makes efficient use of the color expander. Color expansion is widely used in the graphics industry and the main purpose of the color expander is to render text as well as graphic fill operations. The color expander normally assists the local processor to render text with different colors. The present system uses the color expander to decode and render graphics.

The main building blocks of a color expander are shown in figure 5. The color expander increases (expands) the number of bits in each pixel representation. For example, an input pixel may be represented as an 8 bit value to designate one of 256 colors. The actual color (i.e., the amount of red, green and blue) is typically obtained by translating the pixel value to RGB via a look up table (LUT) . Each color is thus represented in graphics memory 506 as three values of red, green and blue (RGB) . The color expander of figure 5 expands the 8 bit input pixel value to 24 bit RGB (for 8 bit color resolution) or 15 bit BGB (for 5 bit color resolution) .

Color registers 502 and 504 are coupled to two inputs of a multiplexer, 510 (MUX) . The local processor will typically load the color registers before the expansion process. The illustrated basic color expander has two color registers 502, 504 but it could support more.

An address register 508 contains the destination address where output pixels from MUX 510 will be written into graphics memory 506. The color expander needs the address values X and Y to be loaded into address register 508 at the beginning of the operation, which will then automatically increment the XY address value after each data transfer.

An index register 512, an offset register 516 and a pixel counter 514, control the operation of the color expander. The index register 512 contains the index of the color to be written in the graphics memory 506. The least significant bit(s) output of the index register 512 is coupled to the selection input S of multiplexer 510. For this example, the expander has two colors so each bit in the index register will select either register color 0 or register color 1. If the color expander supports more than two colors, the number of bits in the color expander are used to select the color register. For example to support 4 colors, pairs of bits in the index register will select a color via a 4 input multiplexer having a 2 bit selection input.

In general, the index register 512 width is equal to the local processor bus width. A single write to the index register 512 will trigger the color expander to process the number of pixels pointed to by the index register for each count of the pixel counter 514. For example, if the color expander has two color registers and the index is a 32 bits register, a write to the index register will automatically write 32 pixels in the destination graphics memory 506.

An offset register 516 accounts for the situation where the total number of pixels to be written is not an exact multiple of the index register width. The offset register 516 is used to tell the hardware how many pixels are to be skipped. For example, if 34 pixels have to be written and the index register 512 is 32 bits wide, the offset register 516 value will be programmed to be equal to 30, so that only two pixels will be written into graphics memory 506 on the first pass. The offset register 516 is generally reset after the first pass in such manner that all subsequent writes to the index register will account for the full number of pixels in the graphics memory.

The transparency feature (Code 0) is useful for text rendering or other image overlay. When transparency is enabled, the color expander is set to transparent mode so when a transparent pixel (input code 0) is encountered, the XY destination is not written in to graphics memory 506 with either register colors 502 or 504, thereby allowing the background to stay intact.

In the first embodiment where the GIF image is fully decoded at the headend, and transmitted via the CATV as in a bit mapped file format, the LUT Value n,m is stored directly in graphics memory 506 via a bypass connection 503. In such case, the color expander is not used when the image file is a non-compressed bit mapped file.

IMAGE DECODING

Decoding is accomplished in the color expander. Figure 7 is an overall flow chart diagram of the decoding process which controls the color expander of figure 5 as one of the steps (738 in figure 7). As indicated above, the local processor in the settop simply streams the incoming compressed (modified run length encoded) data to the color expander.

First, to start the color rendering process 602, the local processor reads the modified run length encoded file, including the Codes and Values, interprets them and to set up the color expander registers (512, 514 and 516 in figure 5) accordingly. The color expander's color registers are changed for each different pixel Value coming in from the compressed stream. Based on the number of pixels that have to be written into graphics memory, the local processor programs the color expander' s offset and then starts the index register for the number of times required by the compressed data. In particular, step 604 indicates the setup required for each input Code and Value. The color register 1 value is set to (LUT Value n,m), which is the RGB color value derived from looking up the received Value n,m in the appropriate color table. - The address register is set equal to the desired graphics memory location, which is generated locally within the settop. The register offset is set equal to the remainder after the input Code is divided by 32, and the number of passes is set equal to the input Code divided by 32, plus 1.

After the setup steps 604, the number of passes is checked at step 606. If the number of passes is greater than or equal to zero, the index register (in the case of two color registers) is set to all l's (OxFFFFFFFF) . For a 4 color register, the color register is composed of 2 bit data fields, leading to index values. For example a OxFFFFFFFF value will address color register 3 and a value 0x55555555 will address color register 1. The number of passes then decrements by 1 at step 608, and the loop continues the color expansion process until the number of passes is less than 1, and thereafter exits at step 610. On the first pass, the color expander will skip the specified number of pixels in the offset register.

As stated above, an overall flow chart for decoding the received transcoded encoded image file is shown in figure 7. First, the number count is set equal to the byte count of the incoming modified run length encoded data file 710 at step 712. The byte count is checked at step 714, and the program will exit at step 716 when the byte count equals zero.

If the byte count is not equal to zero at step 714, the next Code n is fetched at step 718. If the received Code n is greater than 0 and less than 250 (between 0 and 250) , at step 720, the next Value is fetched at step 724, and the register color (color 1 in the color expander) is set to a value obtained from a color look up table (LUT) . At that time, a number (used as a program index) is set = 1 at step 726. This number value is used to control the number of different pixels are to be expanded at step 736.

If the received Code n is greater than 250 (indicating an extended compression code) at step 722, the m Values are fetched at step 728. The color register is set equal to the successive m values and the program index number is set equal to 259 - Code n, at step 730. As an example, if the Code n value is 254, the number (program index) will be set to 5 (259- 254) meaning that 5 different pixels will be expanded in step 738.

If the received Code n is equal to zero (indicating a transparent pixel) at step 722, the color expander is set to transparent mode, so that pixels are not written into graphics memory the color is set equal to the background value in steps 732 and 734, and the program index number is set equal to 1.

Once the registers are setup, the program index number is checked at step 736. If the number is greater than or equal to 1, the color expander renders the image as per the flow chart of figure 6, at step 738. Thereafter, the program index number decrements at step 740, and the loop through step 738 repeats the color expansion process as per figure 6 until the program index number is less than one (i.e. decrements to zero). The byte count in the main program loop is checked at step 714. The decoding and rendering process is repeated for the next received Code n, until the byte count = zero, at which point the image decoding process ends at step 716.

At this point, the graphics memory in the settop (506 in figure 5, 20 in figure 3) contain a decoded graphics image corresponding to the original input GIF image (400 in figure 4, 10 in figure 3) received at the headend of the CATV system. In such manner, an image is rendered at the settop using a modified run length encoded format which was transcoded at the encoder from an original input encoded graphics image.

Claims

What is claimed is:

1. In a CATV system having a headend transmitter, and a settop decoder at a subscriber location, said settop decoder including a local processor and a graphics memory, a method for transmitting an image received at said headend in an encoded format, to said settop at said subscriber location, said method comprising:

receiving said encoded format image at said headend;

decoding said encoded format image at said headend to form a decoded bit mapped image;

transmitting said decoded bit mapped image over said CATV to said settop;

receiving said decoded bit mapped image at said settop to form a received bit mapped image; and

storing said received bit mapped image in said graphics memory to form a decoded image at said settop.

2. A CATV system for distributing an encoded image signal on a transmission medium between a CATV headend and a CATV subscriber location, said CATV system comprising:

a headend transmitter at said CATV headend, the output of said headend transmitter being coupled to said transmission medium;

an image decoder having a decoded output image signal coupled to the input of said CATV headend transmitter;

a digital settop decoder at a subscriber location;

a central processing unit at said digital settop decoder coupled to said CATV transmission medium;

a graphics memory coupled to said central processing unit and adapted for storing said decoded output image signal; and

a display subsystem coupled to said graphics memory.

3. In a CATV system having a headend transmitter, and a settop decoder at a subscriber location, said settop decoder including a local processor and a local color expander graphics engine including a graphics memory, a method for transmitting an image received at said headend m an encoded image format, to said settop at said subscriber location, said method comprising:

receiving said encoded image at said headend;

transcoding said encoded image at said headend to form a transcoded image;

transmitting said transcoded image over said CATV to sa d settop;

receiving said transcoded image at said settop;

decoding said transcoded image m said color expander to form a decoded image at said settop to form a decoded image; and

storing said decoded image in said graphics memory.

4. A method in accordance with claim 3, wherein said encoded image is a Graphics Intechange Format image (GIF encoded image), and said GIF encoded image is transcoded from a GIF encoded image to a modified run length encoded image.

5. A method in accordance with claim 3, wherein said encoded image is transcoded to a modified run length encoded image which includes first and second fields, said first field defining a sequence of adjacent colors corresponding to a number of different single pixels in a row and said second field corresponding to the number of pixels in said sequence of adjacent colors corresponding to said number of different single pixels in a row of said decoded image.

6. A method in accordance with claim 5, wherein said modified run length encoded image includes third and fourth fields, said third field defining a pixel value and said fourth field for corresponding to the number of times said pixel value is to be repeated in one row of said decoded image.

7. In a CATV system having a headend transmitter, and a settop decoder at a subscriber location coupled to said headend transmitter by a CATV transmission medium, said settop decoder including a local processor and a local color expander graphics engine including a graphics memory, an apparatus for transmitting an image received at said headend in an encoded image format, to said settop at said subscriber location, said apparatus comprising:

means for receiving said encoded image at said headend; means for transcoding said encoded image at said headend to form a transcoded image;

means for transmitting said transcoded image over said CATV transmission medium to said settop;

means for receiving said transcoded image at said settop;

means for decoding said transcoded image in said color expander to form a decoded image at said settop; and

means for storing said decoded image in said graphics memory.

8. An apparatus accordance with claim 7, wherein said encoded image is a GIF encoded image, and said GIF encoded image is transcoded from a GIF encoded image to a modified run length encoded image.

9. An apparatus in accordance with claim 7, wherein said encoded image is transcoded to a modified run length encoded image which includes first and second fields, said first field corresponding to a sequence of adjacent colors corresponding to a number of different single pixels in a row and said second field defining the number of pixels in said sequence of adjacent colors corresponding to said number of different single pixels in a row of said decoded image.

10. An apparatus in accordance with claim 9, wherein said modified run length encoded image includes third and fourth fields, said third field defining a pixel value and said fourth field for corresponding to the number of times said pixel value is to be repeated in one row of said decoded image.

11. A CATV system for distributing an image signal on a transmission medium between a CATV headend and a CATV subscriber location, said CATV system comprising:

a graphic image transcoder having a transcoded output image signal coupled to the input of said CATV headend transmitter;

a digital settop decoder at a subscriber location;

a graphics engine included a color expander coupled to said central processing unit and adapted for decoding said transcoded output image signal using said color expander to form a decoded image output signal;

a graphics memory coupled to said graphics engine and adapted for storing said decoded output image signal; and

a display subsystem coupled to said graphics memory.

12. An apparatus in accordance with claim 11, wherein said image signal is transcoded from a GIF encoded image to a modified run length encoded image.

13. An apparatus in accordance with claim 11, wherein said encoded image signal is transcoded to a modified run length encoded image which includes first and second fields, said first field defining a sequence of adjacent colors corresponding to a number of different single pixels in a row and said second field defining the number of pixels in said sequence of adjacent colors corresponding to said number of different single pixels in a row of said decoded image.

14. An apparatus in accordance with claim 13, wherein said modified run length encoded image includes third and fourth fields, said third field defining a pixel value and said fourth field for defining the number of times said pixel value is to be repeated in one row of said decoded image.