Methods and apparatus for encoding and decoding images

[0001] The present invention relates to image processing and, more particular, to methods for generating, compressing, decompressing and/or preparing images for subsequent processing and display that are well suited for a variety of applications including, e.g., set top box applications.

[0002] The representation of images using digital data has become commonplace. Recent improvements in transmission systems and storage devices have made the use of digital images practical in a wide variety of applications including, for example, cable television.

[0003] The amount of bandwidth available for the delivery of data, e.g., digital images, to customer premises, has increased over time as transmission technology has improved. In addition, the cost for memory and other types of storage which can be used to store digital data has steadily decreased over time. This has resulted in consumer devices with ever increasing amounts of memory.

[0004] Even with recent improvements in transmission and data storage, the relatively large size of digital images and the cost advantages of storing or transmitting digital images continues to encourage the use of data compression prior to the transmission of images and/or the storage of digital images.

[0005] A fair amount of effort has been put into developing image formats and corresponding compression algorithms which are optimized to achieve good data compression for a wide range of image and/or streaming video applications. Various image encoding schemes, also sometimes called compression methods, have developed to a point which image data may be encoded and decoded in multiple passes, with a portion of the image data being encoded or decoded in each pass. Systems which allow for partial decoding of an image can be desirable in streaming applications where a user may wish to see a low resolution image or a portion of an image before downloading the data corresponding to the full high quality image. Unfortunately, while such encoding algorithms work well for many applications, the complexity of such encoding methods can be a disadvantage in applications where there is limited processing power available or it would be desirable to limit the amount of processing power used, e.g., for cost reasons.

[0006] Various data formats and compression algorithms have been developed specifically for the purpose of representing images in a digital format and/or for compressing digital image data. Examples of image data formats and compression algorithms can be found in the JPEG standard, the MPEG standard, and other standards which are known from the commonly used acronyms PNG, BMP and IMG. These compression algorithms often require knowledge of the image location to which particular pixel values correspond with values corresponding to different image locations being grouped and/or processed differently from a compression perspective.

[0007] One particular application where digital images are used involves devices which include an embedded application, e.g., a user interface application, which uses images. A Set Top Box (STB) is an example of a device which normally includes an embedded user interface application. STBs are commonly used in cable television applications. Satellite receivers which are coupled to televisions or other display devices are another example of what may be called a Set Top Box.

[0008] STBs normally include a dedicated rendering circuit, sometimes called a rendering engine, which performs the processing required to prepare an image represented as a set of pixel values for display on a display device, e.g., the display of a TV set or computer monitor. Rendering circuits normally do not perform data decompression operations or image format conversions. Thus, rendering circuits usually expect the image input data to be in a specific format, e.g., RGB format with or without alpha values, for which the rendering circuit was designed. The rendering circuit is normally designed to work with a specific image input format, e.g., a format used for the pixel values that are the data which represents an image to be displayed. The specific input image data format with which the rendering circuit of an STB is designed to work is the native format of the rendering circuit. The native format of the rendering circuit is often called the native image format of the STB. Since the native image format is determined prior to manufacture of the STB, the native image format is a predetermined format with regard to a given rendering circuit and thus set top box which includes the rendering circuit.

[0009] While the rendering circuit requires that data be received by the rendering circuit in a particular format, e.g., the STB's native image format, the rendering circuit will proceed to perform specific image processing operations associated with generating control values which are used to control a particular display device to which the rendering circuit is coupled. Thus, a rendering circuit may generate different control values for a CRT display than it would for an LCD display, e.g., because each of the different types of displays have different light output characteristics.

[0010] In the case of STBs, a general purpose CPU in the STB is often responsible for generating menus from stored image data and for outputting other images which may be loaded into the STB memory such as company logos, error information, etc. This functionality is commonly part of a user interface which may be implemented as a routine that is executed by the general purpose processor within the STB.

[0011] Images used by a user interface are usually relatively small, e.g., each image may be intended to occupy only a portion of a screen as opposed to the full display screen.

[0012] In at least one existing system, images intended for a user interface of a STB are first generated in an image format which uses the same number of bits for each of the Red, Green and Blue color components associated with a pixel, e.g., the image is generated in the RGB 888 format. The generated image is then processed and compressed using a known image standard such as PNG which processes all of the original image bits plus 1 to 8 bits of alpha blending data when present. PNG processing involves subjecting the image data to a complicated series of processing rules along with a well known image compression scheme intended to arrive at an optimized image which can be decoded and displayed in multiple passes. Existing formats such as PNG are widely used because of their relatively small output, ability to display an image prior to full decoding of the image, e.g., show something sooner rather than later, with the complete image being displayed after multiple decoding passes. Set top boxes do not require the ability to display an image in multiple passes and therefore the complexity associated with such processing is wasteful in the context of a STB implementation.

[0013] In existing systems, the user interface in a STB, generally referred to as a Resident Application (“RA”) uses several graphic images of varying shapes and sizes arranged under control of the user interface routine in an arrangement that will be sensible and pleasing to a user when viewed. The images that are used by a STB user interface application are normally created and stored in one of a plurality of well known image formats and then compressed using a video encoding method intended for the particular image format and/or for a wide range of image applications. Accordingly, images used by the user interface of a STB are presently generated and then stored in a well known image compression format such as, e.g., JPEG, PNG, BMP, etc. Since such formats were designed and intended for general image applications they are not necessarily the best format for the STB specific applications and often necessitate the use of specific processor intensive decoding algorithms which produce decoded image formats which are different from the format used by a set top box.

[0014] Accordingly, not only is a fair amount of processing required to decode images encoded using many of the well known encoding algorithms, but additional processing is then often required to convert the decoded image into the image format which is used as the input to the STB's image rendering circuit. This often involves altering the number of bits used to represent color data and/or making other pixel value changes before the image can be supplied to the STB's rendering circuitry.

[0015] In view of the above discussion, it should be appreciated that improvements in image coding and processing which can reduce STB image processing requirements and/or the amount of data required to represent an image used by a STB, e.g., in providing a user interface, would be desirable.

[0016] Image compression and processing techniques that will allow for reductions in processing power required for a general purpose computer in a set top box are particularly desirable because they can allow for less powerful processors to be used which can have the effect of lowering the cost of set top boxes.

[0017] The present invention is directed to methods and apparatus relating to generating and compressing digital images in a manner that is well suited for use with embedded applications where available processor resources may be limited.

[0018] In various embodiments, images are pre-processed to the native embedded image format used by the device which is intended to control the display of the image. The uncompressed image data is then arranged to promote efficient compression by a file compression routine. The arranged image data is then compressed in accordance with the invention using, e.g., a general purpose file compression routine.

[0019] When the compressed image data file is decompressed, the color component information will be in the native format of the device which performs the file decompression operation. If necessary, the uncompressed image data is rearranged. After any required rearrangement, the image data will be in the proper format for further display processing, e.g., processing by an image rendering circuit. Since the image data is created and compressed in the native format of the end device which will use the image data, a complete step of image processing to convert between image formats which commonly occurs today in many devices, is eliminated. Significantly, for many images, e.g., many small images which may be used as part of a user interface of a set top box, the methods of the present invention result in smaller compressed image file sizes than occur when various specialized image encoding techniques are used. In addition, the methods of the present invention tend to be less processor intensive since, among other things, conversion between different color component image formats need not be performed in the end device using the compressed image.

[0020] The methods and apparatus of the present invention are particularly well suited for use in applications where the image format that is used by a rendering circuit of a device which will control the display of the image is fixed and known at the time of encoding. STBs are an example of one application where the methods and apparatus of the present invention may be used.

[0021] Depending on the embodiment, when generating image data, alpha values may be generated in addition to color component values. In one exemplary embodiment, an RGB 565 image format is used for color component values. In one such exemplary embodiment, alpha values, when used, are represented using 8 bits. The RGB 565 image format was chosen for the exemplary embodiment since this is the format used by one known image rendering circuit commonly used in STBs. When used by an image rendering circuit, the alpha value or values corresponding to a pixel of an image is normally supplied with the color component values corresponding to the same pixel. Thus, at the point image data is supplied to a rendering circuit pixel color component information and alpha value information is normally interspersed.

[0022] Alpha values and color component values of an image may be generated together, prior to file compression, e.g., in the format the values would be supplied to a rendering circuit. In accordance with the invention color component values and alpha values are separated from one another and then stored in a file which can be compressed. A file header is normally added to the file which is to be compressed. The file header, in some embodiments, indicates the image type and/or whether the image data includes alpha values.

[0023] Thus, when alpha values are used in accordance with the invention, uncompressed image data is arranged in a file with color component values being grouped separately from alpha values to facilitate efficient data compression by a standard file compression method. The image file is then compressed using a conventional lossless file compression operation such as, e.g., GZIP. During compression, the compression method treats the different types of data in the file to be compressed in the same manner. Thus, unlike specific image encoding algorithms which may compress color component information differently from other types of image information, the file compression method of the present invention does not distinguish between different types of data to be compressed and does not rely on specific image information such as pixel arrangement during the file compression process.

[0024] The compressed file is transmitted to one or more devices, e.g., STBs which can decompress the file when needed.

[0025] In one exemplary embodiment, the compressed image files of the present invention are used by a user interface of a STB. In the exemplary embodiment the user interface controls the retrieval of compressed image files and the processing of the files to generate image data suitable for display.

[0026] The compressed image file is decompressed when needed and the alpha data and color component data is reorganized so that the color component values and alpha value(s) corresponding to individual pixels are grouped together, e.g., the alpha and color component values are interspaced on a per pixel basis prior to the values being supplied to a rendering circuit, e.g., of a STB in the exemplary embodiment.

[0027] Encoding and processing complexity is reduced in accordance with the invention by using a conventional file compression algorithm and working in the native color component format required by the rendering circuit.

[0028] In particular, the amount of processing required to be performed by a processor in the device using the compressed image file is reduced as compared to systems where encoding algorithms optimized for images are used. This is because the general purpose file compression methods used in accordance with the present invention tend to be less complicated and therefore less processor intensive to implement than specialized image encoding algorithms. In addition, since the image data is in the format used by the rendering circuit as opposed to a format used by a specialized image encoding algorithm, the need for performing format conversion operations on color component values is avoided. For example, there is no need to convert from an RGB 888 implementation used by some image encoding algorithms to an RGB 565 format used by rendering circuits of various devices.

[0029] While described in the exemplary context of STBs, the image generation and compression methods of the present invention are well suited to a wide range of applications where images may be used by embedded applications which need to be run on a processor with processing capacity that has been limited by cost or other factors.

[0030] Various additional features and advantages of the present invention will be apparent from the detailed description which follows.

[0040] As discussed above, the present invention is directed to methods and apparatus for generating and compressing images, e.g., images which may be processed by an embedded application such as a user interface of a set top box (“STB”). While not being limited to the STB application, the methods and apparatus of the invention are well suited for STB applications and will be described in the context of a STB example. A STB may be, e.g., a cable box, intended to be used in conjunction with a television set or other type of display device.

[0041] Various features of the invention will now be described with reference to the figures which show exemplary apparatus and methods implemented in accordance with the invention.

[0042] FIG. 1 illustrates a communications system 100, e.g., a cable system, implemented in accordance with the present invention. The cable system 100 includes a cable office 102 which is coupled to a plurality of N customer premises 104 through 104′ via cable 121. Each customer premise 104, 104′ corresponds to a different physical location and includes a corresponding STB 124, or 124′. The STBs 124, 124, are coupled to corresponding display devices 126, 126′, respectively. The display devices may be, for example television sets, monitors or some other form of display which can be used to display images supplied by the set top box 124, 124′.

[0043] The cable office 102 serves as a distribution point for television shows and for images which are to be displayed by the STB 124, 124′ as part of a user interface. The images displayed as part of a STB user interface may include, e.g., all or a portion of images used as menus, from which a STB user can make selections, e.g., via an input device such as a remote control. In some cases, the images used by the STB user interface form a portion of a program guide. Such images which are used as part of a user interface are usually relatively small in size. In addition, the STB 124, 124′ fully decodes such images prior to display.

[0044] The cable office 102 in the exemplary system 100 includes a STB image generation and compression module 108, a data store 114 and a distribution control module 120 which are coupled together as shown. The STB image generation and compression module 108 is responsible for generating and compressing images which are to be used by the user interfaces of STBs 124, 124′. The STB image generation and compression module 108 includes a graphics image generation module 110 which is coupled to a compression module 112. As will be discussed further below, in accordance with the invention the graphics image generation module 110 generates images intended to be used by the STB user interface in the native format of the STB, e.g., in a format that image data is supplied to a rendering circuit included within the STB. In one embodiment of the invention, the uncompressed native format is an RGB 565 format where 5 bits are used for the red component of a pixel, 6 bits are used for the green component of a pixel and 5 bits are used for a blue component of a pixel for a total of 16 bits per pixel. Thus, unlike other image generation systems which generated images using RGB 888 or other common image formats which treat each color element uniformly in terms of the number of bits used to represent the color component, the present invention intentionally generates images in the format used by the STB to reduce the processing which the STB has to perform to display the image.

[0045] The output of the graphics image generation module 110 is supplied to the input of compression module 112. The compression module 112 adds a header to the uncompressed data indicating the image type and whether or not it includes alpha data and then subjects it to compression in accordance with the invention. Compression module 112, separates the color data from the alpha data when present and then compresses the separate sets of color component values (RGB) values and alpha values using any one of a plurality of loss-less data compression methods, e.g., methods which are not specifically designed for encoding image data and do not involve knowledge that the data being compressed corresponds to pixels or even an image.

[0046] In various embodiments, a standard file compression program such as GZIP is used to compress the image file and to produce a compressed image data file. Thus, a file compression program as opposed to an image encoding algorithm is used in accordance with the invention. In contrast to image encoding/compression programs which require knowledge about the image being encoded, the file compression program used does not depend on knowledge about the image being encoded or manner in which the image is represented. The compressed file representing an image generated by compression module 112 includes, in some embodiments, a compressed file header generated by the compression program, the compressed data, a checksum and a file length indicator.

[0047] The compressed image file generated by compression module 112 is stored in compressed image store 116 of the data store 114. Distribution control module 120 controls when compressed images stored in the compressed image storage device 116 and/or stored program content in program storage 118 are retrieved and distributed to one or more STBs. Distribution of the compressed image files may be at predetermined times or in response to some signal communicated from one or more STBs 124, 124′.

[0048] FIG. 2 illustrates, in greater detail then shown in FIG. 1, an exemplary STB generation and compression module 108′ which may be used as the module 108 shown in FIG. 1.

[0049] The module 108′ includes a processor, e.g., CPU 202, input device 206, output device 208, input/output (I/O) interface 210 and memory 212 which are coupled together via a bus 204. The module 108′ may be implemented as a personal computer, dedicated workstation, or some computer system capable of implementing programs used to perform the image generation steps of the present invention. Input device 206 may be, e.g., a keypad, mouse or other type of input device. Output device 208 may be, e.g., a display device used to display images being generated and/or an image generation program such as a drawing program, paint program or other type of image generation program which can create images in the native format of a STB. I/O interface 210 may be, e.g., a bus interface and/or may include a router or other circuitry for coupling the STB image generation and compression module 108′ to one or more potential sources of raw image data to be used in generating images. The I/O interface 210 provides a way for the module 108′ to store information in the compressed image store 116 and to retrieve compressed image data from the store 116, e.g., for use in generating additional images.

[0050] In the FIG. 2 example, the STB image generation and compression module 108′ operates in accordance with the present invention under the control of one or more modules, e.g., programs, stored in memory 212. The modules include a graphics image generation module 110 and a compression module 112 which operate as discussed with regard to FIG. 1. The memory 212 also includes alpha blending information 220 which provides information on alpha values to be used when the graphics image generation module 110 is operating in a mode which produces both color pixel values (e.g., RGB values) and alpha values used to control image blending.

[0051] Alpha values may vary for different portions of a user interface image and/or for a particular portion of the screen for which an image is intended to be displayed. Alpha blending information 220 provides the image generation module information which is used to determine the appropriate alpha values for an image being generated. In some embodiments, where alpha values are used, there can be one 8 bit per pixel alpha data value for each pixel of the image. In one embodiment where alpha values are used, the alpha channel will be fully opaque for a pixel when the pixel value is 0xff and fully transparent when the pixel value is 0.

[0052] The graphic image generation module 110 generates uncompressed images. Each image is normally stored in a separate file for processing by the compression module 112. File 218 represents one uncompressed image data file which may be stored in memory for processing by the graphic image generation module 110. Multiple files 218 corresponding to different images may be stored in memory at any point in time. During the processing of the uncompressed image data file by the compression module 112, a header is added and alpha data, when present, is separated from the color component data. As part of the processing performed by compression module 112, a temporary image data file 223 with alpha data separate from color component data may be generated. The file 223 is subjected to a file compression operation performed by the graphics image generation module 110 to produce a compressed image data file, e.g., compressed image data file 222. The compressed image data file 222 may be stored briefly in memory 212 prior to being supplied to the image store 116 for distribution. Examples of an uncompressed image data file 218, temporary image data file 223 and compressed image data file 222 will be discussed in more detail below with reference to FIGS. 6, 7 and 8, respectively, in the context of flow charts 4 and 5 which are used to explain the method of the present invention.

[0053] FIG. 3 illustrates an exemplary STB 124, implemented in accordance with the invention, which can be used in the system of FIG. 1. The STB 124 includes an input/output (I/O) interface 302, memory 308, a general purpose processor, e.g., CPU 306, and an image rendering processor 310 coupled together by a bus 304. The I/O interface 302 provides a connection to other cable system elements, e.g., the cable office, via a cable connection. The memory 308 includes a user interface module 324, an image data decompression module 326 and an image data processing and/or reordering module 328. In addition to these modules which can be used to control various user interface features, the memory 308 includes a plurality of compressed image data files 320, 322, one or more temporary image data files 323 and one or more uncompressed image data files 319.

[0054] The user interface module 324, when executed by the CPU 306, is responsible the presentation of menus and/or other information to a viewer as part of a user interface. The user interface module 324 determines what image is to be presented and when. When an image is selected to be displayed by the user interface module 324, the compressed image data file, e.g., data file 320 or 322, which stores the image to be processed is retrieved and supplied to the image data decompression module 326. Decompression module 326 performs a file decompression operation to recover the original image data in an uncompressed format. As part of the decompression process, a temporary image data file 323 having a content the same as or similar to the temporary image data file 223 generated during the compression process, is generated as part of the decompression process. The decompressed file includes color pixel data, e.g., a set of RGB values in the native format of the STB and, if alpha values are present, a separate set of uncompressed alpha values. Notably, since the image data was represented in the native format used by the STB and was compressed with a simple file compression routine, it is possible to decompress the compressed image data to obtain image data in the native format used by the image rendering processor 310. Thus, in contrast to previous systems which used image encoding algorithms to compress image data which was in a format that did not match the native image format used by the STB 124, it is possible to decode the image data usually with less processing operations than would be required if a specialized image compression method were used to compress the file. Furthermore, since the image data is in the native format of the STB there is no need to convert the image data from one representation format, e.g., a first number of bits per pixel, to a second format, e.g., which uses a different number of bits per pixel. While color data in the decompressed file is in the native format of the STB, if alpha data is being used as part of the encoding process of the invention it would have been separated from the color data for compression purposes.

[0055] When alpha values are present, the image data decompression module 326 proceeds to call the image data processing/reordering module 328 which is responsible for reorganizing the uncompressed data in the temporary image data file 323 so that the color and alpha data for an individual pixel are stored together rather than in separate sets of color data and alpha data. The reordered data, is stored in the uncompressed image data file 319 which includes data in the native format used to supply image data to the image rendering processor 310.

[0056] The image rendering processor 310, which may be implemented as a dedicated graphic processor chip, requires that image data to be processed for display be supplied in a particular predetermined format which, in most embodiments, allows for the optional use of alpha values in addition to color component values for each pixel of an image in a particular format. The input format of the image rendering processor 310, in this example, is referred to as the native image format of the STB 124. The image rendering processor 310 is responsible for preparing images for display and for loading the prepared images into image buffer 312 which is coupled to a display.

[0057] An exemplary image generation and compression process implemented in accordance with the present invention will now be explained in greater detail with reference to FIG. 4. FIG. 4 is a flowchart showing the steps 400 of an exemplary STB image generation and compression method which may be implemented by the exemplary STB image generation and compression module 108′. The method begins in start step 402 with the graphics image generation module being executed. In step 404 an image is generated in the native image format used by a STB rendering circuit that is included in a STB for which the image is being generated.

[0058] In one exemplary embodiment the image is generated in an RGB 565 format with 5 bits being used to indicate the intensity of the red component of a pixel, 6 bits being used to indicate the intensity of the green pixel component and another 5 bits being used to represent the intensity of the blue pixel component. In cases where alpha information is to be used in conjunction with the color component information, an alpha value is generated for each pixel of the image in addition to the RGB color component values. The RGB values and corresponding alpha value, when present, are normally stored together on a per pixel basis.

[0059] Referring now briefly to FIG. 6, FIG. 6 illustrates an exemplary image 600 which may be represented by the image data generated in step 404. The image 600 includes 4 rows and 4 columns of pixels for a total of 16 pixels, identified as P1 through P16. As is common, the pixels are labeled starting at the top left corner and ending at the bottom right corner of the image 600. In many applications, e.g., progressive display applications, this is the order in which the pixels would be displayed on a display device.

[0060] An exemplary set of image data 700, in the native format of the STB for which the image is intended, includes an image width indicator 706, an image height indicator 708, a bytes per row (row bytes) indicator 710 and a set of pixel data 712.

[0061] In the case of the exemplary image of FIG. 6, the image width indicator 706 would be set to 4 indicating the image is 4 pixels wide and the image height indicator 708 would be set to 4 indicating the image is 4 pixels high. The row bytes indicator is used to indicate the number of bytes used per image row to represent the color component information. If present, the row bytes indicator will not include the alpha value bits. In the case where 16 bits are used per pixel for the color information, given that a byte has 8 bits, the bytes per row indicator would be set to 2 times the number of pixels in the row (2 times the value of the width indicator in this case). The number of bytes per row will be different when the number of bits per pixel is different from the example of 16 bits. In the case of the FIG. 6 example, the bytes per row indicator 710 would be 8 since each row includes 4 pixels and each pixel includes 2 bytes of color information.

[0062] The set of pixel data 712 includes per pixel color data 720 and the corresponding per pixel alpha data 721 with the color and alpha data for each pixel being stored together resulting in a set of data 712 with interspersed color and pixel values arranged in the order in which the pixels appear in the image, e.g., as numbered from top left to bottom right in this particular example. Thus, the color data 722 for pixel P1 is stored first followed by the corresponding alpha data 723 for pixel P1. Color data 724 for pixel P2 follows alpha data 723 for pixel P1 and is, in turn, followed by an alpha value 725 for pixel P2. Next follows color data 726 and alpha data 727 for pixel P3. The arrangement of color data and alpha data continues in the generated set of image data until it ends with the color data 728 and alpha data 729 for the last pixel in the image.

[0063] In embodiments where alpha values are not used, the alpha values 721 would be omitted from the data set 712.

[0064] Having described a set of uncompressed image data that may be generated in image generation step 404, the discussion will now return to the processing performed in the method shown in FIG. 4. In step 406 which follows the image generation step 404, a determination is made as to whether or not the uncompressed image data, e.g., the set of data 700, includes alpha values.

[0065] If the image data includes alpha values, operation proceeds to step 407. In step 407 a file header is generated including image type information and, if not conveyed by the image type, in some cases an indicator value that indicates that alpha values are included in the file. In one embodiment an image type of 0x0001 is used to indicate an image represented in RGB 565 format while the value 0xFF00 is used to indicate an image in RGB 565 format with Alpha values. Other image type values can be used to indicate files corresponding to other types of uncompressed images. Operation then proceeds to step 409 where the alpha values are separated from the pixel color component values so that the pixel color values and alpha values are arranged in separate sets, e.g., with the data in each set being arranged in order as they appear in the image. Operation proceeds from step 409 to step 410.

[0066] If in step 406 it is determined that alpha values are not present in the generated image data, operation proceeds to step 408. In step 408, a file header including an image type indicator and/or an alpha value indicator indicating the absence of alpha values is generated. Operation proceeds from step 408 to step 410.

[0067] In step 410 an uncompressed image file is generated which includes the header and/or alpha value indicator generated in step 407 or 408. In addition, the file includes a set of color pixel values and, if alpha values are present, a separate set of alpha values which correspond to the pixels for which pixel color information is provided.

[0068] FIG. 8 illustrates an exemplary file 800 which may be generated by the processing performed in step 410. The file 800 may be implemented as a sequential array of 16 bit wide data elements as shown in FIG. 8. The file 800 includes much of the information present in the exemplary set of image data 700 but in a rearranged form which is intended to facilitate data compression by a file compression method and with the addition of an image type file header 804. The same reference numbers are used in FIGS. 7 and 8 to indicate the same or similar data in each of the figures. Notably, in the uncompressed image file 800 of FIG. 8, the color pixel values 722, 724, 726, 728 are arranged in a first set of data 812 while the alpha values 723, 725, 727, 828, 830, 729 are grouped together, when present, in a separate set of data 814. In this particular implementation, the alpha data follows the pixel data when stored, e.g., in a memory or on a disk based storage device and is not interspersed with the color component values.

[0069] The image file generated in step 410, is subjected in step 412 to a lossless compression operation, e.g., using any one of a plurality of available file compression routines. In one exemplary embodiment, a file compression program which performs file compression in accordance with the GZIP file compression standard is used. The GZIP file compression standard is described in RFC 1952. This results in a compressed image file such as the exemplary image file 900 shown in FIG. 9. Notably, unlike specifically designed image compression algorithms which rely on complex encoding procedures which rely on knowledge of which portions of the data being encoded represent pixels and/or specific image information, the use of a generalized file compression algorithm normally involves less complex processing since it doesn't distinguish between what different portions of the data file based on the type of information presented. Thus, the file compression method used will compress file header data, width, color pixel data and, if present, alpha pixel data using the same compression procedure regardless of the type of data being compressed. While this would normally result in a less compact representation of image data, by separating color and alpha data, satisfactory compression results have been achieved.

[0070] This is because such general compression algorithms tend to work well when values which are close to one another numerically are stored adjacent or near one another within a file. Alpha values tend to be similar for multiple pixels in the case of images generated for applications such as the user interface of a set top box. RGB color component values corresponding to a pixel also tend to be relatively close to one another making the arrangement of RGB data on a per pixel basis beneficial.

[0071] Interestingly, during actual implementations, it was found that separating R, G and B data into separate groups prior to compression by a file compression algorithm actually tended to increase the resulting compressed file size in many cases. This appears to be the result of color component values changing from pixel to pixel, in many images, more than then the color component values change within a pixel.

[0072] Significantly, it has been found that for small images such as those commonly used to implement a portion of a menu that might be used in a set top box interface, the resulting file 900 is, in many cases, the same or smaller in size than a file created using a conventional image or video compression algorithm rather than a file compression algorithm.

[0073] The exemplary compressed data file shown in FIG. 9 includes a file header 902 which is the file header for the compressed data file and which identifies the file as a file which was compressed according to the utilized file compression method. Following the file header 902 is the compressed file data 904. This compressed file data includes, in compressed form, the full content of the uncompressed image file, e.g., file 800. In addition, the file 900 includes one or more checksums 906 which can be used for detecting and/or correcting errors. At the end of the file is a compressed file length indicator 908 which indicates the length of the compressed file 900. The checksums may extend across data of different types, e.g., with a single checksum being applicable to the compressed representation of the uncompressed file header 804, the compressed representation of the image width and/or pixel data information.

[0074] The compressed image file 900 can be transmitted to various STBs 124, 124′ for storage and use by the STB's user interface module 324. Use of a compressed image file of the present invention, such as the file 900, will now be discussed with regard to the exemplary flowchart of FIG. 5.

[0075] FIG. 5 shows the steps of an image file decompression and image display method performed by a set top box in accordance with one exemplary embodiment of the present invention. The method 500 starts in step 502, e.g., when the user interface module 324 of a STB 124 determines an image is to be displayed. In step 504, the compressed image file, e.g., a file 900 of the type shown in FIG. 9, corresponding to the image to be displayed is retrieved from memory for processing. Next, in step 506 the retrieved image file 900 is subjected to a lossless file decompression operation, e.g., the inverse of the file compression operation used to generate the file 900. This produces a decompressed image file 508, which includes a file type header indicating the image type, a set of color component pixel values and, if alpha values were included with the image, the included alpha values. The recovered file, if it includes alpha values, will have them grouped separately from the color component values. The decompressed image file 508 may be the same as, or similar to, the uncompressed image file 800 generated prior to file compression.

[0076] The decompressed image file 508 is examined in step 510 to determine if it includes alpha values. If it includes alpha values, operation proceeds to step 512. In step 512 the color component values and the alpha values are reorganized to arrange color values and alpha values correspond to the same pixel together, thereby interspersing color component values and alpha values. This step, and step 514 which follows, may be performed by the STB's image data processing/reordering module 328.

[0077] In step 514, the header indicating the image type and/or presence of alpha data is stripped from the image data to produce a recovered set of image values in the native format of the STB 124. The resulting set of uncompressed image data may be the same as, or similar to, the set of image data 700 shown in FIG. 7.

[0078] Thus, in accordance with the invention, by simply decompressing the image file, reordering the contents if alpha values are present, and removing one or more headers, the STB is able to obtain an image in the native format of the image rendering processor. Accordingly, color component format conversions and/or other processor intensive image format conversions are not required before the image data is ready to be supplied to the image rendering processor.

[0079] The set of image data, in the native format of the STB's image rendering processor produced in step 514, is supplied in step 516 to the image rendering processor 310. Then, in step 518, the image rendering processor 310 is operated to process the supplied set of image data and to produce, from the supplied set of image data, a rendered image which is output to the image buffer 312. The display device receives the contents of the image buffer and displays the image in step 520. With the image displayed, processing of the image data stops in step 522. However, the user interface may continue to select other stored images for display and processes them accordingly so that they are displayed at the appropriate time.

[0080] In various embodiments system elements described herein are implemented using one or more modules which are used to perform the steps corresponding to one or more methods of the present invention, for example, file compression, data rearrangement, file header generation, etc. Such modules may be implemented using software, hardware or a combination of software and hardware. Each step may be performed by one or more different software instructions executed by a processor, e.g., CPU.

[0081] At least one system implemented in accordance with the present invention includes a means for implementing the various steps which are part of the methods of the present invention. Each means may be, e.g., an instruction, processor, hardware circuit and/or combination of elements used to implement a described step.

[0082] Many of the above described methods or method steps can be implemented using machine executable instructions, such as software, included in a machine readable medium such as a memory device, e.g., RAM, floppy disk, etc. to control a machine, e.g., general purpose computer with or without additional hardware, to implement all or portions of the above described methods, e.g., in one or more nodes. Accordingly, among other things, the present invention is directed to a machine-readable medium including machine executable instructions for causing a machine, e.g., processor and associated hardware, to perform one or more of the steps of the above-described method(s).

[0083] Numerous additional embodiments, within the scope of the present invention, will be apparent to those of ordinary skill in the art in view of the above description and the claims which follow.