Random accessible image data compression

By using a fixed-length compression algorithm in the image data block to compress each two-dimensional block to form a compressed block that can be accessed randomly, the problem that image data compression in the prior art is difficult to achieve random access, and the data access efficiency is improved.

CN119484855APending Publication Date: 2025-02-18IMAGINATION TECH LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202411630906.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2019-09-05
Filing Date
2020-08-21
Publication Date
2025-02-18

AI Technical Summary

Technical Problem

The prior art is difficult to realize random access when compressing image data, resulting in inefficiency in the rendering unit when accessing color data in the frame buffer.

Method used

Each two-dimensional block in the image data block is compressed separately using a fixed-length compression algorithm to form the header and body of the compressed block, allowing random access to each value in the compressed block without decompressing the entire block.

Benefits of technology

It is realized that without losing compression efficiency, the rendering unit is allowed to randomly access various values ​​in the image data block, thereby improving the efficiency of data access.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119484855A_ABST
    Figure CN119484855A_ABST
Patent Text Reader

Abstract

The invention relates to randomly accessible image data compression. Disclosed are a method and a compression apparatus for compressing a block of image data, the block of image data comprising a plurality of picture element values, each picture element value being divisible into at least a first value and a second value, such that the block of image data comprises a two-dimensional block of the first value and a two-bit block of the second value, the method includes: compressing a first data set including all or a portion of a two-dimensional block of a first value according to a first fixed length compression algorithm to generate a first compressed block; compressing a second data set including all or a portion of the two-dimensional block of the second value according to a second fixed length compression algorithm to generate a second compressed block; and forming a compressed block of the image data block based on the first compressed block and the second compressed block.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application of a Chinese patent application filed on August 21, 2020, with application number 202010851053.X and invention name “Randomly Accessible Image Data Compression”. Technical Field

[0002] The present application relates to methods and systems for compressing and decompressing image data, such as but not limited to pixel data. Background Art

[0003] Data compression, whether lossless or lossy, is desirable in many applications where data is stored in and / or read from memory. By compressing data before storing it in memory, the amount of data transferred to memory can be reduced. An example of data for which data compression is particularly useful is image data. The term "image data" is used herein to refer to two-dimensional data having a value corresponding to each pixel or each sample position of an image, the image being generated as part of a rasterization process on a graphics processing unit (GPU). Image data includes, but is not limited to, depth data to be stored in a depth buffer, pixel data (e.g., color data) to be stored in a frame buffer, texture data to be stored in a texture buffer, and surface normal data to be stored in a surface normal buffer. These buffers can be any suitable type of memory, such as a cache memory, a separate memory subsystem, a storage area in a shared memory system, or some combination thereof.

[0004] GPU can be used to process data in order to generate image data. For example, GPU can determine the pixel value (e.g., color value) of the image to be stored in the frame buffer, which can be output to the display. GPU usually has a highly parallelized structure for processing large blocks of data in parallel. There is huge commercial pressure to make GPU (especially those GPUs intended to be implemented on mobile / embedded devices) run at a lower power level. Contrary to this, it is hoped that higher quality rendering algorithms can be used on fast GPUs, which thus puts pressure on relatively limited resources (memory bandwidth). However, increasing the bandwidth of the memory subsystem may not be an attractive solution, because moving data in and out of the GPU, or even moving data within the GPU, consumes most of the power budget of the GPU. For central processing units (CPUs) and GPUs, the same problem may be faced.

[0005] Figure 1An exemplary graphics rendering system 100 that can be implemented in an electronic device such as a mobile / embedded device is shown. The graphics rendering system 100 includes a host CPU 102, a GPU 104, a memory 106 (e.g., graphics memory), and a display 108. The CPU 102 is configured to communicate with the GPU 104. Data, which may be compressed data, may be transferred in either direction between the GPU 104 and the memory 106. Images (e.g., pixel data) rendered by the GPU 104 may be stored in the memory 106 and displayed on the display 108 via the display interface 116.

[0006] GPU 104 includes a rendering unit 110, a compression / decompression unit 112, and a memory interface 114. Graphics rendering system 100 is arranged so that data can be passed in either direction between (i) CPU 102 and rendering unit 110; (ii) CPU 102 and memory interface 114; (iii) memory interface 114 and memory 106; (iv) rendering unit 110 and compression / decompression unit 112; (v) compression / decompression unit 112 and memory interface 114; and (vi) memory 106 and display interface 116. In some examples, graphics rendering system 100 may be further arranged so that data can be passed to and from compression / decompression unit 112 to display interface 116, and so that data can be passed from display interface 116 to display 108.

[0007] In operation, GPU 104 processes each region of image data one by one. Each region may, for example, represent a rectangular (including square) portion of a rendering space (i.e., a two-dimensional space representing, for example, an image region to be rendered). Rendering unit 110 may perform scan conversion and rasterization of graphics primitives (e.g., but not limited to, triangles and lines) using known techniques such as Z-test and texture mapping. Rendering unit 110 may include a cache unit to reduce memory traffic. Some data is read or written to memory 106 by rendering unit 110 via memory interface 114 (which may include a cache), but for other data, such as data to be stored in a buffer (e.g., a frame buffer), data is preferably transmitted from rendering unit 110 to memory interface 114 via compression / decompression unit 112. Compression / decompression unit 112 reduces the amount of data to be transmitted to memory 106 via an external memory bus by compressing the data.

[0008] The display interface 116 sends the data defining the complete image to the display 108. The uncompressed image may be accessed directly from the memory 106. The compressed data may be decompressed via the compression / decompression unit 112 and sent to the display 108 as uncompressed data. In an alternative example, the compressed data may be read directly by the display interface 116, and the display interface 116 may include logic for decompressing the compressed data in a manner equivalent to the decompression by the compression / decompression unit 112. Although shown as a single entity, the compression / decompression unit 112 may include multiple parallel compression and / or decompression units for enhanced performance reasons.

[0009] As known to those skilled in the art, the rendering unit 110 may generate a set of one or more color values ​​(e.g., RGB or RGBA) for each pixel in the rendering space, and store the color values ​​in a frame buffer. The set of color values ​​of a frame may be referred to herein as color data, image data, frame buffer data, or simply frame data. The rendering unit 110 may also generate other image data, such as depth data, surface normal data, lighting data, etc., and may store those image data values ​​in one or more buffers in a memory. In some cases, these buffers may be referred to as frame buffers, while in other cases, the term "frame buffer" may be reserved for buffers storing color values ​​or storing data to be sent to a display. In some graphics rendering systems, the image data values ​​stored in a buffer for a particular rendering may be used by the rendering unit 110 to render one or more subsequent frames. For example, the color values ​​generated by a rendering may be used as texture values ​​when rendering one or more subsequent frames, and the surface normal values ​​generated for a geometric model in a rendering may be used to apply lighting effects to the same model during rendering one or more subsequent frames.

[0010] Because image data (e.g., color data) can be quite large, the memory bandwidth associated with writing the image data to and reading the image data from the buffer in memory can be a significant portion of the total memory bandwidth of the graphics processing system and / or GPU. Therefore, the image data is typically compressed by compression / decompression unit 112 before being stored in the buffer, and decompressed by compression / decompression unit 112 after being read from the buffer. Because image data often includes color data, the compression method can be designed to accommodate specific characteristics of color image data. In other examples, the compression method can be designed for different characteristics of depth data or surface normal data.

[0011] Known lossless methods for compressing color data, such as those described in the applicant's British patents 2451911, 2530312 and 2530311, are configured to divide the color data into blocks and compress each block individually in a manner that requires the entire block to be decompressed together. For example, in these compression methods, the color values ​​of an 8x8 pixel block may be compressed together. Then, in order to access any specific color value in the block, the entire 8x8 pixel block must be decompressed.

[0012] However, rendering unit 110 typically does not need all of the data (e.g., color values) in a block to render subsequent frames. For example, rendering unit 110 may only need color values ​​associated with a few pixels in a block. Therefore, having to decompress the entire block just to access a small number of color values ​​in the block may make it inefficient for rendering unit 110 to access color data in the frame buffer.

[0013] Attempts have been made to address this problem by caching decompressed blocks, but in many cases having a cache does not significantly improve the efficiency of accessing data (e.g., color values) in the frame buffer. Other attempts to address this problem have included reducing the block size (e.g., reducing the block size to 4x4 blocks of color values), but it has been found that the inefficiency caused by having to decompress an entire block in order to access the color values ​​of a few pixels exists at any block level, and the smaller the block, the less efficient the compression.

[0014] The embodiments described below are provided by way of example only and are not intended to be limiting of implementations that address any or all of the disadvantages of known image data compression and / or decompression methods. Summary of the invention

[0015] This Summary is provided to introduce some concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0016] A first aspect provides a method for compressing an image data block, the image data block comprising a plurality of image element values, each image element value being divisible into at least a first value and a second value, so that the image data block comprises a two-dimensional block of the first value and a data block of the second value, the method comprising: compressing a first data set comprising all or part of the two-dimensional block of the first value according to a first fixed-length compression algorithm to generate a first compressed block by: identifying common basic information of the first data set; and identifying a fixed-length parameter for each first value in the first data set, the length of the fixed-length parameter being zero, one, or more than one bit; compressing a second data set comprising all or part of the two-dimensional block of the second value according to a second fixed-length compression algorithm to generate a second compressed block by: identifying common basic information of the second data set; and identifying a fixed-length parameter for each first value in the first data set, the length of the fixed-length parameter being zero, one, or more than one bit. base information of the first data set; and a fixed length parameter identifying each second value in the second data set, the length of the fixed length parameter being zero, one or more than one bit; and forming (208) a compressed block of the image data block based on the first compressed block and the second compressed block by the following operations: forming a header of the compressed block, wherein the header includes common base information of the first data set and common base information of the second data set, information indicating the size of the fixed length parameter of each first value in the first data set, and information indicating the size of the fixed length parameter of each second value in the second data set; and forming a body of the compressed block, wherein the body includes the fixed length parameter of each first value in the first data set and the fixed length parameter of each second value in the second data set, wherein the size of the first data set is different from the size of the second data set.

[0017] A second aspect provides a compression device for compressing an image data block, the image data block comprising a plurality of image element values, each image element value being divisible into at least a first value and a second value, so that the image data block comprises a two-dimensional block of the first value and a two-dimensional block of the second value, the compression device comprising: a header generation unit configured to identify the length of a fixed-length parameter and common basic information for compressing a first data set according to a first fixed-length compression algorithm, the first data set comprising all or part of the two-dimensional block of the first value, identify the length of the fixed-length parameter and common basic information for compressing a second data set according to a second fixed-length compression algorithm, the second data set comprising all or part of the two-dimensional block of the second value, and form a header of the compressed block, the header comprising the common basic information of the first data set and the common basic information of the second data set, Information indicating the size of the fixed length parameter for the first data set and information indicating the size of the fixed length parameter for the second data set; and a body generation unit, which is configured to: identify the fixed length parameter of each first value in the first data set according to a first fixed length compression algorithm, each first value in the first data set can be obtained from the common basis information of the first data set and the fixed length parameter of the first value, identify the fixed length parameter of each second value in the second data set according to a second fixed length compression algorithm, each second value in the second data set can be obtained from the common basis information of the second data set and the fixed length parameter of the second value; and form a body of the compressed block, wherein the body includes the fixed length parameter of each first value in the first data set and the fixed length parameter of each second value in the second data set.

[0018] A third aspect provides a computer-readable storage medium having computer-readable instructions stored thereon. When the computer-readable instructions are executed at a computer system, the computer system executes the method as described herein.

[0019] A fourth aspect provides a computer-readable storage medium having stored thereon a computer-readable description of a compression device as described herein, which, when processed in an integrated circuit manufacturing system, enables the integrated circuit manufacturing system to manufacture an integrated circuit including the compression device. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Examples will now be described in detail with reference to the accompanying drawings, in which:

[0021] Figure 1 is a block diagram of an exemplary graphics rendering system;

[0022] Figure 2 is a flow chart of an exemplary method for compressing a block of image data;

[0023] Figure 3is a schematic diagram showing an exemplary image data block including data for a plurality of color channels;

[0024] Figure 4 is a schematic diagram showing a channel block divided into a plurality of sub-blocks;

[0025] Figure 5 is a graph showing the percentage of color channels having common color values ​​for an exemplary benchmark;

[0026] Figure 6 is a schematic diagram showing a set of color values ​​falling into two clusters;

[0027] Figure 7 is a schematic diagram illustrating modular arithmetic;

[0028] Figure 8 is a graph showing the number of delta bits used to compress an 8x8 channel block / sub-block using an initial value and delta compression algorithm for an exemplary benchmark test;

[0029] Fig. 9 is a graph showing the number of delta bits used to compress a 16x16 channel block / sub-block using an initial value and delta compression algorithm for an exemplary benchmark test;

[0030] Fig.10 is a graph showing the number of delta bits used to compress a 32x32 channel block / sub-block using an initial value and delta compression algorithm for an exemplary benchmark test;

[0031] Fig.11 is a schematic diagram showing a second set of color values ​​falling into two clusters;

[0032] Fig.12 is a schematic diagram showing compression of an exemplary channel sub-block using a lookup table compression algorithm;

[0033] Fig.13 is a graph showing the distribution of channel color values ​​for unique channel blocks for a plurality of applications;

[0034] Fig.14 is a graph showing distribution of compression algorithms for a plurality of applications when the compression algorithms include an initial value and incremental compression algorithm, a predetermined color compression algorithm, and a lookup table compression algorithm;

[0035] Fig.15 is a schematic diagram of a first exemplary compressed block format when a channel block is not divided into sub-blocks before compression;

[0036] Fig.16 is a schematic diagram of a second exemplary compressed block format when a channel block is not divided into sub-blocks before compression;

[0037] Fig.17 is a schematic diagram of an exemplary compressed block format when a channel block is divided into sub-blocks before compression;

[0038] Fig.18 is a schematic diagram of an image data block, where each channel block is divided into multiple sub-blocks;

[0039] Fig.19 is a flow chart of a first exemplary method for selecting a fixed length compression algorithm for compressing a channel block / sub-block;

[0040] Fig. 20 is a flow chart of a second exemplary method for selecting a fixed length compression algorithm for compressing a channel block / sub-block;

[0041] Fig.21 is a schematic diagram of a channel block divided into multiple levels of blocks;

[0042] Fig. 22 is a flow chart of an exemplary method for selecting a block of channel blocks to be compressed;

[0043] Fig.23 is a schematic diagram of an exemplary header of a compressed block when a layered compression scheme is used;

[0044] Fig.24 is a block diagram of an exemplary compression unit for compressing a block of image data;

[0045] Fig.25 Is used for use Figure 2 A block diagram of an exemplary decompression unit for decompressing a compressed block of compressed image data in a method;

[0046] Fig.26 It is to use Figure 2 A flowchart of an exemplary method for decompressing a compressed image data block;

[0047] Fig. 27 is a graph showing the size of a compressed block of image data compared to the size of an uncompressed block of image data for various compression schemes used for benchmarking;

[0048] Fig.28 is a graph showing the percentage of channel blocks having common color values ​​for a number of different benchmarks;

[0049] Fig.29 is a graph showing the size of a compressed block of image data compared to the size of an uncompressed block of image data for various compression schemes for a number of different benchmarks;

[0050] Fig.30is a block diagram of an exemplary computer system in which the compression unit, decompression unit, and / or compression / decompression unit described herein may be implemented; and

[0051] Fig.31 is a block diagram of an exemplary integrated circuit manufacturing system for producing an integrated circuit embodying a compression unit, a decompression unit, or a compression / decompression unit described herein.

[0052] The accompanying drawings show various examples. It will be appreciated by the skilled person that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the accompanying drawings represent an example of boundaries. In some examples, it may be the case that an element can be designed as multiple elements, or multiple elements can be designed as one element. Where appropriate, common reference numerals are used throughout the accompanying drawings to indicate similar features. DETAILED DESCRIPTION

[0053] The following description is given by way of example to enable those skilled in the art to make and use the invention. The invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art. The embodiments are described by way of example only.

[0054] As described above, compressing image data on a block basis in a manner that requires decompressing the entire block to access individual values ​​makes it difficult for logic that randomly accesses the image data (such as rendering logic) to access the data efficiently. Therefore, there is a need for a lossless method of compressing image data that allows random access to the compressed data (i.e., individual values ​​in a compressed block can be accessed without having to decompress the entire block).

[0055] Thus, methods and systems are described herein for compressing a block of image data so that individual values ​​of the block can be decompressed without having to decompress the entire block. Specifically, methods and systems are described herein for compressing a block of image data that includes a plurality of image element values ​​(e.g., color values) that are divisible into at least a first value and a second value (e.g., a first channel color value and a second channel color value) such that the image data includes at least a two-dimensional block of first values ​​(e.g., a two-dimensional block of color values ​​for a first color channel) and a two-dimensional block of second values ​​(e.g., a two-dimensional block of color values ​​for a second color channel). The term "image element value" is used herein to refer to a unit of particular image data. Thus, the image element value depends on the type of image data. For example, for color data, the image element value is a pixel value or a color value (e.g., which may be defined by a set of channel color values); for depth data, the image element value is a depth value; for surface normal data, the image element value is a depth value; for surface normal data, the image element value is a surface normal direction (e.g., which may be defined by a set of values ​​representing a unit vector or one or more angles); and for texture data, the image element value is a texel value (e.g., which may be defined by a color value or a set of color values).

[0056] In the methods and systems described herein, each two-dimensional block of values ​​is compressed separately using one or more fixed-length compression algorithms. Specifically, in the methods and systems described herein, one or more two-dimensional blocks of values ​​are compressed by compressing all or a portion of a two-dimensional block of values ​​using a fixed-length compression algorithm, wherein the values ​​in the two-dimensional block (or a portion thereof) are represented by common base information and a fixed-length parameter for each value in the block (or a portion thereof), and the length of the fixed-length parameter is zero, one, or more than one bit. A compressed block of image data is then formed from the common base information and the fixed-length parameter. By compressing a two-dimensional block (or a portion thereof) of values ​​using a fixed-length compression algorithm, all values ​​in the two-dimensional block (or the portion thereof) are represented using the same number of bits, so that the portion of compressed data associated with a particular value can be easily identified.

[0057] In some exemplary methods and systems described herein, image data is divided into one or more blocks (e.g., 32x32 blocks of image elements, 16x16 blocks of image elements, or 8x8 blocks of image elements), and the values ​​in the blocks (e.g., each color channel) are represented by a fixed number of bits in any two-dimensional block. For example, if the image data is color data including color values ​​for four channels numbered 0 to 3, and the image data is divided into 8x8 pixel blocks, then each channel 0 color value in a particular 8x8 pixel block will be represented by the same number of bits b0, each channel 1 color value in the 8x8 pixel block will be represented by the same number of bits b1, each channel 2 color value in the 8x8 pixel block will be represented by the same number of bits b2, and each channel 3 color value in the 8x8 pixel block will be represented by the same number of bits b3. Therefore, if all bits associated with the same pixel are packed together to form a pixel data unit, then each pixel data unit will have b0+b1+b2+b3 bits. If the pixel data units of the block are then packed together in pixel order to form a block data unit, then i th The start point of a pixel data unit of a pixel (where the first pixel is numbered 0) is located i*(b0+b1+b2+b3) bits from the start point of the block data unit.

[0058] The specific bits of the pixel data unit corresponding to a specific color value can then be determined from b0, b1, b2, b3 and the ordering of the channels in the pixel data unit. For example, if the bits of each channel are packed together in the pixel data unit in channel order, then the bits corresponding to the color value of channel 0 are the first b0 bits in the pixel data unit; the bits corresponding to the color value of channel 1 are the b1 bits starting from bit b0; the bits corresponding to the color value of channel 2 are the b2 bits starting from bit b0+b1; and the bits corresponding to the color value of channel 3 are the last b3 bits starting from b0+b1+b2. Therefore, the compressed blocks generated by the methods and systems described herein are randomly accessible.

[0059] In the exemplary compression and decompression methods and systems described below, blocks of image data are blocks of color values ​​(e.g., pixel color values), and each two-dimensional block of values ​​is associated with one of the color channels of the pixel color. For example, where the pixel color values ​​represent four-channel RGBA data, there will be a two-dimensional block of values ​​corresponding to each of the R (red), G (green), B (blue), and A (alpha) color channels. However, the use of pixel color values ​​is for example only, and it should be understood that the compression and decompression methods and systems can operate on any type of image data, such as depth data, lighting data, or surface normal data.

[0060] In addition, although in the following examples, each image element value (e.g., pixel value) is composed of multiple different values ​​(e.g., each pixel value includes a first channel color value, a second channel color value, etc.), and the image data is divided into two-dimensional blocks of values ​​according to each different value (e.g., one two-dimensional block of values ​​includes a first channel color value, another two-dimensional block of values ​​includes a second channel color value, etc.), in other examples, the image data can be divided into two-dimensional blocks of values ​​in another way. In some cases, each image element value can be a single different value (e.g., a depth value), and the single different value can be divided into smaller chunks or parts for forming a two-dimensional block of values. For example, if the image element value is a multi-byte value, then the first two-dimensional block of values ​​can include the first byte of each image element value (e.g., depth value), and the second two-dimensional block of values ​​can include the second byte of each image element value (e.g., depth value). In other cases, each image element value may include multiple different values ​​(e.g., color values ​​for each color channel in multiple color channels), but the image data may not be divided into two-dimensional blocks of values ​​according to each different value. For example, if each image element value includes the color channel value of the first 10 bits, the color channel value of the second 10 bits, the color channel value of the third 10 bits, and the color channel value of 2 bits, then the image data can be divided into two-dimensional blocks of values ​​according to each byte, rather than dividing the image data into two-dimensional blocks of values ​​according to each channel. Specifically, the first two-dimensional block of values ​​can include the first byte of each image element value, and the second two-dimensional block of values ​​can include the second byte of each image element value. In another example, the top eight bits of each 10-bit color channel value can form a block, and the final block can be formed by the two lowest bits of each channel. For example, the first two-dimensional block of values ​​can include the first 8 bits of the first color channel value, the second two-dimensional block of values ​​can include the first 8 bits of the second color channel value, the third two-dimensional block of values ​​can include the first 8 bits of the third color channel value, and the fourth two-dimensional block of values ​​can include the last two bits of each color channel. It will be apparent to those skilled in the art that these are merely examples, and the image element values ​​can be divided into multiple values ​​in another way to form two-dimensional blocks of values.

[0061] In some cases, each image element value may be divided into multiple multi-bit values. In other words, each image element value may be divided into multiple sub-values, each of which includes at least two bits or is formed by at least two bits. For example, where each image element value is divided into a first value and a second value, such that the image data block includes a two-dimensional block of the first value and a two-dimensional block of the second value, each first value may be a multi-bit value (i.e., a value including more than one bit or being formed by more than one bit), and each second value may be a multi-bit value (i.e., a value including more than one bit or being formed by more than one bit). In some cases, the image element value may be divided into eight-bit (i.e., byte) values. For example, as described above, each image element value may be divided into sub-values ​​along a byte line (e.g., the first eight bits of the image element value may form a first value, the second eight bits of the image element value may form a second value, and so on). Splitting image element values ​​into multi-bit values, as opposed to single-bit values, can allow the compression methods and systems described herein to more efficiently compress two-dimensional blocks of values ​​(e.g., first values ​​(e.g., first color channel values) or second values ​​(e.g., second color channel values)), and thereby more efficiently compress image data blocks including the two-dimensional blocks of values ​​because it reduces the number of two-dimensional blocks of values ​​(which reduces header overhead) and allows the use of some of the more complex fixed-length compression algorithms described below to compress two-dimensional blocks of values.

[0062] Reference now Figure 2 , which shows an exemplary method 200 for compressing a block of image data. The method 200 begins at step 202, where a block of image data to be compressed is received. In this example, the block of image data is a block of color values ​​or pixel values.

[0063] As known to those skilled in the art, the data defining a digital image (e.g., a frame) includes a set of one or more color values ​​for each pixel, which can be used to determine the color of the pixel. The set of color values ​​for a pixel can include a color value for each color channel. The number of channels is usually based on the format of the image. For example, if the image is in RGB format, there are three color channels—red, green, and blue, and each pixel has a red value, a green value, and a blue value. Similarly, if the image is in RGBA format, there are four channels: red, green, blue, and opacity (or α), and each pixel has a red value, a green value, a blue value, and an opacity (or α) value. The color values ​​for each channel can be understood to form a two-dimensional array or block.

[0064] For example, Figure 3Exemplary image data 300 for a 32x32 pixel RGBA digital image is shown. Image data 300 includes a two-dimensional block of 8-bit color values ​​for each channel, which may be referred to herein as a channel block. Specifically, image data 300 includes: a 32x32 block 302 of 8-bit color values ​​for channel 0 (i.e., the red channel); a 32x32 block 304 of 8-bit color values ​​for channel 1 (i.e., the green channel); a 32x32 block 306 of 8-bit color values ​​for channel 2 (i.e., the blue channel); and a 32x32 block 308 of 8-bit color values ​​for channel 3 (i.e., the opacity channel). The color at each pixel (which may be referred to herein as a pixel color value) is determined by the different channel color values ​​associated with the pixel (i.e., the channel 0 color value, the channel 1 color value, the channel 2 color value, and the channel 3 color value associated with the pixel).

[0065] An image data block is a portion of the image data corresponding to a two-dimensional pixel block in the image. Thus, an image data block includes a two-dimensional block of color values ​​for each color channel. An image data block may be of any suitable size. For example, an image data block may include color values ​​for a 32x32 pixel block, a 16x16 pixel block, or an 8x8 pixel block. In the case where the compression is used to compress frame buffer data in a graphics processing system that implements slice-based rendering, an image data block may correspond to a slice (e.g., a 32x32 pixel block corresponding to a 32x32 pixel slice), to a group of slices (e.g., a 32x32 pixel block corresponding to four 16x16 pixel slices), or to a portion of a slice (e.g., a 16x16 pixel block corresponding to one quarter of a 32x32 pixel slice). Once an image data block has been received, method 200 proceeds to step 204.

[0066] In step 204, the image data block is divided into channel blocks. For example, if the image data block is received in step 202 Figure 3 The image data block 300 shown in FIG. Figure 3 304, 306, and 308 are shown. Once the image data blocks are divided into channel blocks, method 200 proceeds to step 206 where the channel blocks are compressed individually. Except for areas of constant color (e.g., background or transparent color) for which specific compression techniques will be described below, rendered images typically do not contain many pixels with the same pixel color value (a color determined from the color values ​​of each channel). However, many pixels (particularly those that are in close proximity to each other) may have one or more similar channel (e.g., red, green, blue, or opacity) color values. Therefore, compressing the image data blocks on a per-channel basis may allow for more efficient compression of the image data because those portions of the image data that are more likely to be similar are compressed together.

[0067] In step 206, one or more of the channel blocks are compressed by compressing one or more data sets of the channel block using a fixed length compression algorithm to generate one or more compressed channel blocks. In some cases, the entire channel block can be compressed so that the compressed data set is the entire channel block. In other cases, the channel block can be subdivided into channel sub-blocks so that the compressed data set includes one or more channel sub-blocks. The term channel sub-block is used herein to refer to a portion of the channel block that is smaller than the channel block in at least one dimension. For example, Figure 4 As shown in , if the channel block 402 is a 32x32 block of color values, the channel block 402 may be subdivided into 8x8 sub-blocks 404 of sixteen color values, and one or more of the 8x8 sub-blocks 404 may be compressed using a fixed length compression algorithm.

[0068] As known to those skilled in the art, a fixed length compression algorithm is a compression algorithm in which each item (e.g., color value) in a set of items (e.g., a channel block / sub-block of color values) being compressed is represented by the same number of bits in a compressed format. Thus, by compressing a channel block / sub-block using a fixed length compression algorithm, each color value in the block / sub-block is represented by the same number of bits in the compressed block, which allows easy identification of the bits associated with any particular color value in the channel block / sub-block. Thus, using a fixed length compression algorithm allows the compressed blocks to be randomly accessible.

[0069] The fixed length compression algorithm is configured to compress a block or sub-block of values ​​by (i) identifying common base information for the block; and (ii) identifying a fixed length parameter for each value such that an initial value can be obtained from the common base information and the fixed length parameter. For example, a fixed length compression algorithm can identify a common initial value for a block or sub-block and identify a fixed length increment value for each value in the block or sub-block, the fixed length increment value representing the difference between the common initial value and the value. An exemplary fixed length compression algorithm that can be used to compress a channel block / sub-block is described below.

[0070] When the whole channel block is compressed as a whole, only a single group of common basic information is generated for this channel block, and a fixed length parameter is generated for each color value in the channel block. For example, if the channel block is a 32x32 block of color values, only a single group of common basic information is generated for this channel block, and a fixed length parameter can be generated for each color value in this channel block. In contrast, when the channel block is divided into a plurality of sub-blocks and one or more of the channel sub-blocks are compressed, a group of common basic information is generated for each compressed sub-block. For example, a 32x32 channel block can be divided into four 16x16 channel sub-blocks, and if two sub-blocks in these sub-blocks are compressed, common basic information and fixed length parameters are generated for each compressed sub-block in two compressed sub-blocks.

[0071] When a channel block is divided into channel sub-blocks and a plurality of channel sub-blocks are compressed, it is not necessary to use the same fixed length compression algorithm to compress each sub-block. For example, a first fixed length compression algorithm can be used to compress a first channel sub-block, and a second different fixed length compression algorithm can be used to compress a second channel sub-block of the same channel. As described in more detail below, this allows each channel sub-block to be compressed by the most suitable fixed length compression algorithm for the channel sub-block.

[0072] Similarly, under the situation that all or part of a plurality of passage blocks are compressed, need not use identical compression algorithm for all passage blocks.For example, can use the first fixed length compression algorithm to compress the first sub-block of the first passage block, and can use different second fixed length compression algorithms to compress the first sub-block of the second passage block.As described in more detail below, because different passages have different characteristics, this allows each passage to be compressed by the most suitable fixed length compression algorithm for this passage.

[0073] Once one or more of the channel blocks have been compressed, method 200 proceeds to step 208 .

[0074] In step 208, compressed blocks of image data are generated from the compressed channel blocks generated in step 206. In some cases, the compressed blocks may include a header and a body. The header includes information identifying the size or length of the fixed length parameters for each compressed channel block / sub-block and common base information for each compressed channel block / sub-block. For example, for each compressed channel block / sub-block, the header may include: (i) a length or size field (which may also be referred to as a format field herein) indicating the length of the fixed length parameters for the compressed channel block / sub-block; and (ii) a common base information field including the common base information for the compressed channel block / sub-block. The body includes the fixed length parameters for each compressed channel block / sub-block and the initial color values ​​for any uncompressed channel block / sub-block.

[0075] Under the situation that a kind of compression channel block / sub-block in multiple fixed length compression algorithms can be used, for each compression channel block / sub-block, the header can also include the information of the fixed length compression algorithm that indication is used to compress described channel block / sub-block.In some cases, each compression channel block / sub-block can have independent compression algorithm field, and this compression algorithm field indication is used to compress the compression algorithm of this channel block / sub-block.But, in other cases, the information of the fixed length compression algorithm that indication is used to compress channel block / sub-block can be incorporated in another field.For example, in some cases, can use length or size field to indicate which kind of compression algorithm has been used (for example, length or size field can be set to a certain value to indicate that the first fixed length compression algorithm has been used, and it is set to another value to indicate that the second different fixed length compression algorithm has been used).

[0076] The header may also include information indicating which (if any) channel blocks / sub-blocks are not compressed. In some cases, each channel block / sub-block may have a separate compression / decompression field that indicates whether the channel block / sub-block is compressed. However, in other cases, the information indicating that the channel block / sub-block is not compressed may be incorporated into another field. For example, in some cases, a length or size field or a compression algorithm field may be used to indicate that the channel block / sub-block is not compressed. Figure 15 to Figure 17 An exemplary format for a compressed block is described.

[0077] As mentioned above, the main body includes the fixed length parameters for each compressed channel block / sub-block and the initial color value for any uncompressed channel block / sub-block. Fixed length parameters and / or initial color values ​​can be stored in the main body in any manner that allows random access to fixed length parameters and / or initial color values. In some cases, as described in more detail below, the fixed length parameters and / or initial color values ​​of each pixel can be stored together in the pixel data unit. For example, when the image data includes the color values ​​of four channels numbered 0 to 3, each pixel data unit can include the fixed length parameters / initial color values ​​of channel 0, the fixed length parameters / initial color values ​​of channel 1, the fixed length parameters / initial color values ​​of channel 2, and the fixed length parameters / initial color values ​​of channel 3. In these cases, the pixel data unit can allow any order of random access to the pixel data unit (and therefore allow random access to its fixed length parameters / initial color values) to be stored in the main body. In some cases, when the channel block is divided into sub-blocks before compression, the pixel data unit of each sub-block can be stored together. For example, if the channel block is divided into 8x8 sub-blocks, the pixel data elements of each 8x8 image data sub-block may be stored together.

[0078] Exemplary Fixed-Length Compression Algorithm

[0079] We will now describe Figure 2 An exemplary fixed length compression algorithm that may be used to compress channel blocks / sub-blocks in step 206 of method 200 is shown.

[0080] exist Figure 2 The first exemplary fixed-length compression algorithm that can be used to compress channel blocks / sub-blocks in step 206 of method 200 is referred to herein as a common value compression algorithm. In this compression algorithm, if all color values ​​in a channel block / sub-block are the same, all color values ​​of the block / sub-block can be efficiently represented by a single copy of the color value. Although a rendered image does not typically contain many pixels with the same pixel color value (a color determined from the color value of each channel), many pixels (particularly those that are closely adjacent to each other) may share one or more common channel (e.g., red, green, blue, or opacity) color values. For example, in the case where the image data is in RGBA format, it is very common for many pixels to have the same opacity (or α) value. Therefore, in the common value compression algorithm, the common base information is a common color value, and the fixed length parameter has a length of zero bits (i.e., the fixed length parameter is not stored).

[0081] As known to those skilled in the art, there is a set of standard benchmarks that are used to measure the graphics performance of a device. The benchmarks provide content, like games, to the device and measure the performance of the device in response to the content, and are used to benchmark the graphics performance of the device. Figure 5 The percentage of blocks with common channel color values ​​for various block sizes in the Manhattan 3.0 benchmark is shown. Specifically, Figure 5 The number of 8x8 blocks, 16x16 blocks, and 32x32 blocks having common color values ​​for each of the R, G, B, and A channels is shown. Figure 5 It can be seen that about 20% of the 8x8 blocks have common color values ​​for channel 0 (red channel) and channel 1 (green channel); 30% of the 8x8 blocks have common color values ​​for channel 2 (blue channel); and 80% of the 8x8 blocks have common color values ​​for channel 3 (opacity channel). Figure 5 It can be seen that as the block size increases (e.g., to 16x16 and 32x32), the number of blocks with common channel color values ​​decreases. However, even at a block size of 32x32, 60% of the blocks have a common color value for channel 3 (the opacity channel). Therefore, by identifying those blocks with a common channel color value and using a single copy of that color value to represent all color values ​​for the block, significant bandwidth savings can be achieved.

[0082] exist Figure 2A second exemplary fixed length compression algorithm that can be used to compress the channel block / sub-block in step 206 of method 200 is referred to herein as an initial value and incremental compression algorithm. In this compression algorithm, each color value is represented by a common initial value and a single incremental value having a fixed number of bits. Each incremental value indicates the difference between the color value and the initial value. The number of incremental bits is based on the range of color values ​​in the block. Specifically, the number of incremental bits representing a range k is Table 1 shows the number of incremental bits required to represent a range up to 255. It can be seen that the smaller the range of color values ​​in a block / sub-block, the fewer bits can be used to represent those color values.

[0083] Table 1

[0084] scope Increment Bit [0,1] 1 [0,3] 2 [0,7] 3 [0,15] 4 [0,31] 5 [0,63] 6 [0,127] 7 [0,255] 8

[0085] In some cases, if the number of bits used to represent the range is less than the number of bits representing the original color value, then the initial value and delta compression algorithm may be considered a suitable compression algorithm. For example, if the original color value is 8 bits, then if the range can be represented with 7 bits or less, then the initial value and delta compression algorithm may be considered suitable.

[0086] The compressed color value can be easily decompressed by adding the incremental value of the color value to the original value.

[0087] In some cases, the minimum color value or the maximum color value in the block / subblock is used as the initial value. This allows all incremental values ​​to be positive or all incremental values ​​to be negative, which can simplify the decompression calculation. In other cases, the middle value in the range (e.g., the average value or the midpoint of the range of values) can be used as the initial value, and one bit of the incremental value can be used as a sign bit.

[0088] In all other cases, the increment value is determined as the color value multiplied by the initial value modulo 2. x It may be more efficient to use the difference between , where x is the number of bits used to represent the color value. This may allow more efficient representation of blocks / sub-blocks of color values ​​in a range that are clustered at the ends of the color value range. For example, if each color value is 8 bits allowing for a minimum color value of 0 and a maximum color value of 255; and if Figure 6 As shown, the color values ​​of the channel block / sub-block fall into two clusters 602 and 604, wherein the minimum value of the first cluster 602 is 0, the maximum value of the first cluster 602 is 20, and the minimum value of the second cluster 604 is 235, the maximum value of the second cluster 604 is 255, then, the range 606 of the values ​​in the block / sub-block is 255, so that 8 incremental bits are required to represent the range.

[0089] However, if you use modular arithmetic (i.e., modulo 2x =2 8 =256), the 8-bit range [0, 255] is regarded as a circle, such as Figure 7 As shown, two paths can be taken from one number in the range to another number in the range. Specifically, a clockwise path 702 can be taken when a value is added to the first number; or a counterclockwise path 704 can be taken when a value is subtracted from the first number. For example, to get from 255 to 0, 1 can be added to 255 (i.e., (255+1) mod 256 = 0), or 255 can be subtracted from 255 (i.e., (255-255) mod 256 = 0).

[0090] The range of a set of values ​​can then be represented as any path on the circle that encompasses all the numbers in the set. For example, Figure 6 The range of the example set of values ​​shown in FIG. 6 that fall into two clusters (a first cluster 602 with a minimum value of 0 and a maximum value of 20, and a second cluster 604 with a minimum value of 235 and a maximum value of 255) can be represented as a path from 0 to 255 that results in a range of 255 requiring 8 increment bits; or the range (in Figure 6 608) can be represented as a path from 235 to 20, which achieves a range of 41 requiring only 6 increment bits. Therefore, if the initial value is set to 235 and 6 increment bits are used to represent the difference between the color value and the initial value modulo 256, this exemplary set of values ​​can be represented more efficiently.

[0091] It will be apparent to those skilled in the art that these are merely examples and other suitable values ​​may be used as initial values.

[0092] Therefore, in the initial value and incremental compression algorithm, the common base information is the initial value, and the fixed length parameter for each color value is the incremental value.

[0093] Reference now Figures 8 to 10 , these figures show the percentage of channel blocks represented by each number of incremental bits per channel when compressing image data in RGBA format with 8-bit color values ​​using the initial value and incremental compression algorithms in the Manhattan 3.0 benchmark. Specifically, Figure 8 shows the percentage of 8x8 channel blocks represented using 0-8 increment bits; Fig. 9 shows the percentage of 16x16 channel blocks represented using 0-8 increment bits; and Fig.10 The percentage of a 32x32 channel block represented using 0-8 increment bits is shown. Figure 8It can be seen that approximately 80% of the 8x8 channel blocks overall can be compressed using the initial value and incremental compression algorithms (and the common value algorithm when all color values ​​in the channel block are the same).

[0094] exist Figure 2 The third exemplary fixed length compression algorithm that can be used for compressing channel block / sub-block in step 206 of method 200 is the variant of initial value and incremental compression algorithm, and is referred to as multi-initial value and incremental compression algorithm in this article.It is not that there is a single initial value, but that there are multiple initial values, and each color value is represented by common initial value, individual index and incremental value, and the individual index identifies a common initial value in the common initial value, and the incremental value indicates the difference between the color value and the identified initial value.The color value in the channel block / sub-block is gathered into two or more groups, so that the scope of the color value in this channel block / sub-block is very large, but when the scope in each cluster is very small, multi-initial value and incremental compression algorithm may be suitable.Therefore, in multi-initial value and incremental compression algorithm, common basis information is multiple initial values, and the fixed length parameter of each color value is the index and incremental value of identifying one of the initial values.

[0095] For example, Fig.11 An example is shown where the color values ​​can be between 0 and 255, and the color values ​​in a channel block fall within two clusters 1102, 1104 (a first cluster 1102, where the color values ​​are between 25 and 50, and a second cluster 1104, where the color values ​​are between 215 and 240). The range of all color values ​​in the channel block is 240-25=115, which will require 7 increment bits according to Table 1. Alternatively, using the modulo 256 operation as described above, the range of all color values ​​in the channel block is (50-215) mod 256=91, which, although less than 115, still requires 7 increment bits according to Table 1. However, the range of each cluster is only 25, which will only require 5 increment bits according to Table 1. Therefore, if there are two initial values, one for each cluster 1102, 1104, and the increment of each color value is calculated from one of the initial values, each color can be represented by a 5-bit increment value. For example, 25 and 215 can be stored as initial values ​​0 and 1, respectively, and then for each color value falling in the first cluster 1102, an index 0 is stored, along with a 5-bit incremental value indicating the difference between the color value and the first initial value (i.e., 25 in this example); and for each color value falling in the second cluster 1104, an index 1 is stored, along with a 5-bit incremental value indicating the difference between the color value and the second initial value (i.e., 215 in this example).

[0096] exist Figure 2A fourth exemplary compression algorithm that can be used to compress a channel block / sub-block in step 206 of method 200 is referred to herein as a lookup table compression algorithm. In this compression algorithm, each unique color value in a channel sub-block is stored in a lookup table, and then a fixed length index pointing to the table is generated for each color value in the block / sub-block. This approach is suitable for situations where only a small number of different color values ​​may appear, such as in a black and white image.

[0097] For example, Fig.12 As shown, if the channel sub-block 1202 includes only three color values: 0, 128, and 255, then according to the lookup table compression algorithm, these three values ​​will be placed in the lookup table 1204, and each color value in the block will be represented by an index pointing to the lookup table as shown at 1206. Specifically, Fig.12 As shown, if color value 0 is stored at index 0 of lookup table 1204, color value 128 is stored at index 1 of lookup table 1204, and color value 255 is stored at index 2 of lookup table 1204, then each zero is represented by index 0, each 128 is represented by index 1, and each 255 is represented by index 2.

[0098] Thus, in a lookup table compression algorithm, the common basis information is a lookup table of unique color values, and the fixed length parameter for each color value is an index into the lookup table.

[0099] exist Figure 2 A fifth exemplary compression algorithm that can be used to compress the channel block / sub-block in step 206 of method 200 is referred to herein as a predetermined color compression algorithm. In this compression algorithm, there are a small number (e.g., one to four) of predetermined color values, and if all color values ​​in the block are the same and match one of the predetermined color values, information identifying one of the predetermined colors (e.g., an index, etc.) is stored instead of storing the color value.

[0100] In some cases, there may be only a single predetermined color value. In these cases, identifying that a predetermined color compression algorithm is used also identifies the predetermined color. In other words, in these cases, a predetermined color value compression algorithm can be used to identify a specific color value.

[0101] In other cases, there may be a plurality of predetermined color values ​​(which may be stored in memory). In these cases, in addition to identifying that a predetermined color compression algorithm is used to compress a channel block / sub-block, information identifying one of the plurality of predetermined color values ​​is also stored. Such identification of a particular color value of the plurality of predetermined color values ​​may take any suitable form. For example, in some cases, an index identifying a particular color value may be stored.

[0102] In some cases, a predetermined color compression algorithm can be used to compress an entire block of image data (e.g., all channels of a block). For example, in some cases, an application can set each pixel to a clear color value to clear the frame buffer before making any draw calls. A specific clear color value is typically a specific combination of channel color values. For example, for an 8-bit ARGB format per channel, a clear color value may be 00FFFFFF (hexadecimal), where the first two hexadecimal values ​​correspond to channel 0, the next two hexadecimal values ​​correspond to channel 1, the next two hexadecimal values ​​correspond to channel 2, and the last two hexadecimal values ​​correspond to channel 3. Clear color values ​​are typically stored in memory, so it is not necessary to store clear color values ​​in the compressed block. Therefore, in these cases, a predetermined color value compression algorithm may be used to indicate that each pixel in the block has a clear color value. It will be apparent to those skilled in the art that this is merely an example, and a predetermined color compression algorithm may be used to identify another pixel color value.

[0103] In another example, it is also possible or alternatively possible to have a plurality of frequently used predetermined special pixel color values. For example, in some cases, in the case of using an ARGB format of 8 bits per channel, 00000000 (hexadecimal) and FF000000 (hexadecimal) can be defined as special pixel color values ​​as they are commonly used. In these cases, if it is determined that all pixels in a block have the same color value, and it is one of the predetermined color values ​​(or a clear color value), a predetermined color compression algorithm can be used to compress this block by storing information (e.g., an index) identifying one of the predetermined pixel color values. This enables very efficient compression of blocks in which each pixel of the block has the same special pixel color value.

[0104] In some cases, in addition to or in lieu of using a predetermined color compression algorithm to compress an entire block of image data (e.g., all channels of a block) (which may be referred to herein as a predetermined pixel color compression algorithm), a predetermined color compression algorithm may be used to compress individual channel blocks / sub-blocks of the image data block (which may be referred to herein as a predetermined channel color compression algorithm). Specifically, there are one or more predetermined channel color values ​​(e.g., 8-bit channel color values) instead of one or more predetermined pixel color values ​​(e.g., 32-bit pixel color values), and if all color values ​​in a channel block / sub-block are the same and match one of the predetermined channel color values, then the predetermined color compression algorithm may be used to compress the channel block / sub-block. This may allow more blocks to be compressed efficiently than if compressed at the pixel level.

[0105] The predetermined channel color compression algorithm is most effective when the predetermined channel color value is the most common channel color value in a unique channel block (i.e., a channel block in which all color values ​​are the same). In some cases, the predetermined channel color value may be fixed for the graphics processing system (i.e., the same predetermined channel color value is used for any and all applications running on the graphics processing system). In other cases, the predetermined color channel color may be application-specific. For example, the graphics processing system may include a memory (e.g., a register) that may be used to dynamically identify the predetermined channel color value to be used for a particular application. In some cases, a portion (e.g., two) of the predetermined channel color values ​​may be fixed, and another portion (e.g., two) of the predetermined channel color values ​​may be programmable or dynamically selectable.

[0106] For example, Fig.13 The distribution of color values ​​for an 8x8 channel block with unique color values ​​(i.e., all color values ​​in the 8x8 block are the same) for a number of different applications is shown. Fig.13 As can be seen in , most of the unique 8x8 channel blocks have a color value of 00 (hexadecimal) or FF (hexadecimal). Therefore, if the predetermined channel color value is set to 00 (hexadecimal) and FF (hexadecimal), a large number of unique color channel blocks can be compressed efficiently using the predetermined channel color compression algorithm. In addition, since the pixel color values ​​of 00000000 (hexadecimal), FFFFFFFF (hexadecimal), 00FFFFFF (hexadecimal) and FF000000 (hexadecimal) are very common, this will also cover common pixel color values.

[0107] However, it can be seen that the next highest color value of a unique channel block is application specific. For example, FD (hexadecimal), F1 (hexadecimal) and EE (hexadecimal) are channel color values ​​commonly used in "Angry Birds" application, but are not channel color values ​​commonly used in other application programs. Similarly, A6 (hexadecimal) and 96 (hexadecimal) are channel color values ​​commonly used in "Leanback" application, but are not channel color values ​​commonly used in other application programs. Therefore, if the number (for example, two) of predetermined channel color values ​​is programmable, the number of blocks that can be compressed using this method can be increased so. For example, in some cases, there may be four predetermined channel color values-two of the predetermined color values ​​can be fixed to 00 (hexadecimal) and FF (hexadecimal)-and two of the predetermined color values ​​can be (for example, via register setting) programmable. For example, when running "Angry Birds", the two programmable predetermined color values ​​may be set to FD (hex) and F1 (hex), and when running "Leanback", they may be set to A6 (hex) and 96 (hex). In some cases, the two programmable predetermined color values ​​may have default values ​​that are common to many applications, such as, but not limited to, 0F (hex) and 01 (hex).

[0108] Reference now Fig.14 , which shows the distribution of fixed-length compression algorithms when compressing 8x8 channel blocks using one of the following fixed-length compression algorithms: initial value and incremental compression algorithms (in Fig.14 "DeltaBitx" in the example, where the number x represents the number of delta bits used); a predetermined pixel color compression algorithm, where the predetermined color value is a clear color value (in Fig.14 ); a predetermined channel color compression algorithm, wherein there are four predetermined channel colors 00 (hexadecimal), FF (hexadecimal), 0F (hexadecimal) and 01 (hexadecimal) (in Fig.14 "ConstBytex" in , where the number x indicates which of the four predetermined channel color values ​​numbered 0 to 3 is used); and a lookup table compression algorithm (in Fig.14 (referred to as "TableEntryBitx" in the example, where the number x represents the number of index bits). Since "TableEntryBit0" (i.e., a lookup table compression algorithm with zero index bits) is equivalent to the common value compression algorithm, the notation "TableEntryBit0" is used in this example to indicate that the common value compression algorithm is used.

[0109] Therefore, in the predetermined color value compression algorithm (pixel color value version or channel color value version), the common basis information is information identifying one of the one or more predetermined colors, and the fixed length parameter has a length of zero bits (ie, the fixed length parameter is not stored).

[0110] It will be apparent to those skilled in the art that these are merely exemplary fixed-length compression algorithms. Figure 2 Any fixed-length compression algorithm capable of randomly accessing compressed data of any color value may be used in method 200 .

[0111] Example compressed block format

[0112] We will now describe Figure 2 An exemplary format of a compressed block generated by method 200 is shown.

[0113] Reference now Fig.15 , which shows a first exemplary format of a compressed block 1500 of image data, where the channel blocks are not divided into sub-blocks prior to compression (i.e., each channel block is compressed in its entirety or not compressed). In this example, there are four channels, and therefore four channel blocks, however, it will be apparent to those skilled in the art that this is merely an example, and the methods and techniques described herein can be applied to image data having a different number of channels.

[0114] The exemplary compression block 1500 includes a header 1502 and a body 1504. The header 1502 includes information indicating which channel block is compressed and includes, for each compressed channel block, information indicating the fixed length compression algorithm used to compress the channel block, the size or length of the fixed length parameters, and common base information for the channel block. The body 1504 includes the original or uncompressed color values ​​of each uncompressed channel block and the fixed length parameters of each compressed channel block.

[0115] exist Fig.15 , header 1502 includes length or size fields 1506, 1508, 1510, 1512 for each channel block, which length or size fields indicate whether the channel block is compressed, and if so, the compression algorithm used to compress the channel block and the length or size of the fixed length parameter. Fig.15In the example shown, each length or size field 1506,1508,1510,1512 is 4 bits, 0 ("0000" (binary)) indicates that the corresponding channel block is compressed using a common value compression algorithm; any digit between 1 ("0001" (binary)) and 7 ("0111" (binary)) indicates that the corresponding channel block is compressed using an initial value and an incremental compression algorithm, and the parameter length (that is, the number of incremental bits) is equal to the digit; and 8 ("1000" (binary)) indicates that the corresponding channel block is not compressed, and the original or initial color value of the channel block is included in the compressed block. This is summarized in Table 2.

[0116] Table 2

[0117]

[0118] Therefore, in Fig.15 In the example shown, the length fields 1506, 1512 of channels 0 and 3 are set to eight ("1000" (binary)), indicating that channels 0 and 3 are not compressed; the length field 1508 of channel 1 is two ("0010" (binary)), indicating that channel 1 is compressed using an initial value and incremental compression algorithm and that the length of the fixed length parameter is two bits; and the length field 1510 of channel 2 is set to zero ("0000" (binary)), indicating that channel 2 is compressed using a common value compression algorithm and that the fixed length parameter is zero bits (i.e., the fixed length parameter is not stored for this channel block).

[0119] The header 1502 also includes common base information fields 1514, 1516 for each compressed channel block, which indicate common base information that, combined with a fixed length parameter for the color value, can be used to obtain the original or initial color value. In this example, only channels 1 and 2 have been compressed, so the header 1502 only includes common base information fields 1514, 1516 for channels 1 and 2. The common base information is typically based on a fixed length compression algorithm used to compress the channel block. In this example, channel 1 is compressed according to an initial value and incremental compression algorithm, so the common base information field 1514 includes an initial value (e.g., a minimum color value); and channel 2 is compressed according to a common value compression algorithm, so the common base information field 1516 includes a common color value.

[0120] Body 1504 includes color values ​​for any uncompressed channel block and fixed length parameters for any compressed channel block. Color values ​​and / or fixed length parameters may be stored in body 1504 in a manner that enables random access to fixed length parameters and / or color values ​​associated with any pixel. In some cases, such as Fig.15As shown, fixed length parameters and / or color values ​​corresponding to the same pixel are packed together to form pixel data unit 1518. Fig.15 In the example shown, channels 0 and 3 are uncompressed, and channels 1 and 2 are compressed, so each pixel data unit 1518 includes an uncompressed color value for channel 0, a fixed length parameter for channel 1, a fixed length parameter for channel 2, and an uncompressed color value for channel 3. However, in this particular example, since channel 2 is compressed using a common value compression algorithm, the fixed length parameter has 0 bits, so no fixed length parameters are actually stored for channel 2. The pixel data units 1518 can be stored in the body 1504 in any order. For example, the pixel data units 1518 can be stored in a block in Morton (or Z) order or scan line order.

[0121] Reference now Fig.16 , the figure shows that according to Figure 2 A second exemplary format of a compressed block 1600 of image data generated by method 200 of the present invention is shown, wherein the channel block is not divided into sub-blocks before compression (i.e., each channel block is compressed in its entirety or not compressed). Fig.15 As in the example of , there are four channels, and therefore four channel blocks, however, it will be apparent to those skilled in the art that this is merely an example, and the method and technique can be applied to image data having a different number of channels. The exemplary compression block 1600 includes a header 1602 and a body 1604. Fig.15 Similar to the compressed block 1500, the header 1602 includes information indicating which channel blocks are compressed, and for each compressed channel block includes: information indicating the compression algorithm used to compress the channel block, the size or length of the fixed length parameters, and common base information of the channel block; and the body 1604 includes the original or uncompressed color value for each uncompressed channel block and the fixed length parameters for each compressed channel block.

[0122] In this example, header 1602 includes compression algorithm fields 1606, 1608, 1610, 1612 for each channel block. Each compression algorithm field 1606, 1608, 1610, 1612 indicates whether the corresponding channel block has been compressed, and if compressed, it indicates a specific fixed-length compression algorithm used to compress the channel block. In this example, the compression algorithm field is two bits, and 0 ("00" (binary)) in the compression field of the channel block indicates that the channel block is not compressed (and the original initial color value is stored), and any other value indicates that the channel block is compressed, as well as a specific fixed-length compression algorithm used to compress the channel block. Specifically, in this example, 1 ("01" (binary)) indicates that a common value compression algorithm is used to compress the channel block; 2 ("10" (binary)) indicates that an initial value and incremental compression algorithm is used to compress the channel block; 3 ("10" (binary)) indicates that a lookup table compression algorithm is used. This is summarized in Table 3.

[0123] Table 3

[0124]

[0125] exist Fig.16 In the example shown, compression algorithm fields 1606, 1608, 1610, and 1612 indicate that channels 0 and 3 are uncompressed, and channels 1 and 2 are compressed using a common value compression algorithm, and an initial value and incremental compression algorithm, respectively. If a channel block is uncompressed, then the body includes the original or uncompressed color values ​​for the block, as described in more detail below.

[0126] exist Fig.16 In the example of , header 1602 also includes a length or size field 1614, 1616 for each compressed channel block, which indicates the length or size of the fixed length parameter. In this example, only channels 1 and 2 have been compressed, so header 1602 only includes length or size fields 1614, 1616 for channels 1 and 2. In this example, the length or size fields 1614, 1616 are three bits, which can be used to indicate a size or length ranging from 0 bits to 7 bits. Specifically, channel 1 has a fixed length parameter of 0 bits (that is, it is compressed using a common value compression algorithm, so no fixed length parameter is stored), and channel 2 has a fixed length parameter of 3 (that is, the fixed length parameters are all 3 bits). However, it will be apparent to those skilled in the art that this is only an example, and the length or size fields 1614, 1616 can have any suitable number of bits and / or formats. In some cases, for blocks compressed using a common value compression algorithm, there may be no length or size field, because the length of the fixed length parameter is known to be zero bits from the compression field.

[0127] The header 1602 also includes common base information fields 1618, 1620 for each compressed channel block, which indicate common base information that, combined with a fixed length parameter for the color value, can be used to obtain the original or initial color value. In this example, only channels 1 and 2 have been compressed, so the header 1602 only includes the common base information fields 1618, 1620 for channels 1 and 2. The common base information is typically based on the fixed length compression algorithm used to compress the channel block. In this example, channel 1 is compressed using a common value compression algorithm, so the common base information field 1618 of channel 1 includes a common value; and channel 2 is compressed using an initial value and incremental compression algorithm, so the common base information field 1620 of channel 2 includes an initial value.

[0128] picture Fig.15 Like the body 1504 of the RGB color space, the body 1604 includes color values ​​for any uncompressed channel blocks and fixed length parameters for any compressed channel blocks. The color values ​​and / or fixed length parameters may be stored in the body 1604 in a manner that enables random access to the fixed length parameters and / or color values. In some cases, as described above, the fixed length parameters and / or color values ​​corresponding to the same pixel are packed together to form the pixel data unit 1622. Fig.16 In the example shown, channels 0 and 3 are uncompressed, and channels 1 and 2 are compressed, so each pixel data unit 1622 includes an uncompressed color value for channel 0, a fixed length parameter for channel 1, a fixed length parameter for channel 2, and an uncompressed color value for channel 3. However, because channel 1 is compressed using a common value compression algorithm, the fixed length parameter has a length of 0 bits, so no fixed length parameter is stored for channel 1. The pixel data units 1622 can be stored in the body 1604 in any order. For example, as described above, the pixel data units 1622 can be stored in a block in Morton (or Z) order or scan line order.

[0129] Reference now Fig.17 , which shows an exemplary format of a compressed block 1700 of image data, wherein each channel block is divided into four sub-blocks, and each sub-block may be compressed or uncompressed. In this example, there are four channels, and therefore four channel blocks, however, it will be apparent to those skilled in the art that this is merely an example, and that the method and technique may be applied to image data having a different number of channels. For example, Fig.18As shown, the image data block 1800 may include RGBA image data of a 16x16 pixel block. The image data 1800 may be divided into four 16x16 channel blocks 1802, 1804, 1806, 1808, i.e., a 16x16 block 1802 of color values ​​of channel 0 (red channel); a 16x16 block 1804 of color values ​​of channel 1 (green channel); a 16x16 block 1806 of color values ​​of channel 2 (blue channel); and a 16x16 block 1808 of color values ​​of channel 3 (opacity channel). In this example, before compression, each channel block 1802, 1804, 1806, 1808 is divided into four 8x8 sub-blocks: sub-block zero 1810, 1820, 1830, 1840; sub-block one 1812, 1822, 1832, 1842; sub-block two 1814, 1824, 1834, 1844; and sub-block three 1816, 1826, 1836, 1846.

[0130] Similar to Fig.15 and Fig.16 The compressed blocks 1500 and 1600, Fig.17 The compressed block 1700 includes a header 1702 and a body 1704. The header 1702 includes information indicating which sub-blocks are compressed, and for each compressed sub-block includes: information indicating the compression algorithm used to compress the sub-block, the size or length of the fixed length parameter, and the common basis information of the sub-block; and the body 1704 includes the original or uncompressed color values ​​of the uncompressed channel sub-block and the fixed length parameters of the compressed channel sub-block.

[0131] Fig.17 The header 1702 is similar to Fig.16 The header 1602 is that it includes: compression algorithm fields 1706, 1708, 1710, 1712, 1714, 1716, 1718, 1720, 1722, 1724, 1726, 1728, 1730, 1732, 1734, 1736; length or size fields 1738, 1740, 1742, 1744, 1746, 1748; and common base information fields 1750, 1752, 1754, 1756, 1758 and 1760. However, in Fig.16 In the case where the header 1602 includes only a single set of compression algorithm fields, length or size fields, and common base information fields, Fig.17 The header 1702 includes a set of compression algorithm fields, length or size fields, and common basic information fields for each sub-block of image data. Each set of compression algorithm fields, length or size fields, and common basic information fields works in the same manner as Fig.16The compression algorithm field, length or size field, and common base information field are the same, except that they describe the compression of the channel sub-block, rather than describing the compression (or uncompression) of the channel block. Specifically, for each sub-block of the image data, there is: a compression algorithm field for each channel, which indicates whether the channel sub-block has been compressed, and if compressed, by which algorithm; a length or size field for each compressed channel sub-block, which indicates the length of the fixed length parameter of each compressed channel sub-block; and a common base information field for each compressed channel sub-block, which includes the common base information of the compressed channel sub-block.

[0132] It will be apparent to those skilled in the art that this is merely an exemplary format for header 1702, and that header 1702 may take any suitable format. Fig.15 As described above, the header may include a set of length or size fields and a common base information field for each sub-block, instead of the reference Fig.16 As described above, the header includes, for each sub-block, a set of compression algorithm fields, a length or size field, and a common base information field.

[0133] Fig.17 The body 1704 of includes fixed length parameters for each compressed channel sub-block and initial color values ​​for each uncompressed channel sub-block. The fixed length parameters and / or initial color values ​​may be stored in the body 1704 in a suitable manner that enables random access to them. In some cases, for example, in Fig.17 In the example shown, fixed length parameters and / or initial color values ​​are grouped by sub-block to form sub-block data units 1762, 1764, 1766, 1768. In each sub-block data unit 1762, 1764, 1766, 1768, fixed length parameters and / or color values ​​associated with the same pixel may be packed together to form a pixel data unit 1770, as described above with respect to Fig.15 and 16 For example, if for a particular sub-block, channels 0 and 1 are uncompressed, and channels 2 and 3 are compressed, then each pixel data unit for the sub-block may include an initial uncompressed color value for channel 0, an initial uncompressed color value for channel 1, a fixed length parameter for channel 2, and a fixed length parameter for channel 3.

[0134] To improve memory usage and bandwidth efficiency, the sub-block data units 1762, 1764, 1766, 1768 may be packed together. The sub-block data units 1762, 1764, 1766, 1768 may be packed at any granularity, such as but not limited to bytes or 4-byte words (i.e., the next sub-block may start at the next byte after the previous sub-block ends, or the next sub-block may start at the next 4-byte word after the previous sub-block ends).

[0135] Although the start of each sub-block data unit 1762, 1764, 1766, 1768 can be determined from the length information and / or the compression algorithm information, in some cases, the header 1702 may also include an offset field for each sub-block, which indicates the location (e.g., address) at which the sub-block data unit 1762, 1764, 1766, 1768 of the sub-block begins within the body. This may allow for more rapid location of compressed data for a particular sub-block, however, this increases the size and complexity of the header 1702. In some cases, the offset field may indicate an address offset relative to the start of the body 1704 where the corresponding sub-block data begins. Using an offset, as opposed to an actual address, allows a smaller number of bits to be used to specify the address of a sub-block data unit.

[0136] It will be apparent to those skilled in the art that these are based on Figure 2 An exemplary format of a compressed block generated by method 200 is shown, and the compressed block may take any suitable form.

[0137] Dynamic selection of fixed-length compression algorithms

[0138] In some cases, the color values ​​in the channel block / sub-block can be dynamically selected based on the diversity of color values ​​in the channel block / sub-block. Figure 2 In the step 206 of the method 200 of , a fixed length compression algorithm for compressing a channel block / sub-block is used. For example, in some cases, before compressing a channel block / sub-block, the color value of the channel block / sub-block is analyzed to generate one or more diversity statistics, and the diversity statistics indicate the diversity of the color value in the channel block / sub-block. Then, based on the diversity statistics, one of a plurality of fixed length compression algorithms is selected for the channel block / sub-block. The diversity statistics may include, but are not limited to, the number of unique color values ​​in the channel block / sub-block, the range of the color value in the channel block / sub-block (or statistics that can determine the range from it, such as minimum color value and maximum color value), and / or any other suitable statistics.

[0139] Reference now Fig.19, which shows a first exemplary method 1900 for dynamically selecting a fixed length compression algorithm for compressing a channel block / sub-block. In this exemplary method 1900, a common value compression algorithm or an initial value and incremental compression algorithm can be used to compress a channel block / sub-block. Method 1900 begins at step 1902, at which a channel block / sub-block (e.g., a 32x32 or 16x16 block of color values ​​of a channel) is received. Once a channel block / sub-block has been received, method 1900 proceeds to step 1904, at which diversity statistics are generated for the received channel block / sub-block. In this example, the diversity statistics may include a range of color values ​​in the channel block / sub-block (or statistics from which a range can be determined, such as the minimum color value and the maximum color value in the block / sub-block). The range can be determined using any suitable method, such as, but not limited to, the above-mentioned modulus method. Once the diversity statistics are generated, method 1900 proceeds to step 1906, at which it is determined whether the range is zero (i.e., all color values ​​in the channel block / sub-block are the same). If this scope is zero, then in step 1908, select the common value compression algorithm to compress channel block / sub-block. However, if this scope is not zero (indicating that there are at least two different color values ​​in channel block / sub-block), determine in step 1910 whether this scope can be represented by the increment bit less than original color value or initial color value, so. For example, if original color value or initial color value is each 8 bits, determine whether this scope can be represented by less than 8 bits, so. If in step 1910, determine that this scope can be represented by the increment bit less than original color value or initial color value, then can select initial value and increment compression algorithm to compress channel block / sub-block in step 1912. However, if in step 1910, determine that this scope can not be represented by the increment bit less than original color value or initial color value, then in step 1914, determine not to compress channel block / sub-block.

[0140] Reference now Fig. 20, the figure shows a second exemplary method 2000 for dynamically selecting a fixed length compression algorithm for a channel block / sub-block. In this exemplary method 2000, any one of a common value compression algorithm, an initial value and an incremental compression algorithm, and a lookup table compression algorithm can be used to compress a channel block / sub-block. Method 2000 begins at step 2002, at which a channel block / sub-block (e.g., 32x32 or 16x16 block of the color value of a channel) is received. Once a channel block / sub-block has been received, method 2000 proceeds to step 2004, at which a diversity statistic is generated for the received channel block / sub-block. In this example, the diversity statistic can include the range of the color value in the channel block / sub-block (or can be determined from it, for example, the statistics of the range of the minimum color value and the maximum color value) and the number of unique color values ​​in the channel block / sub-block. This range can be determined using any suitable method, such as but not limited to the above-mentioned modulus method. Once the diversity statistics of the channel block / sub-block have been generated, the method 2000 proceeds to step 2006, in which it is determined whether the number of unique color values ​​in the block / sub-block is one (i.e., all color values ​​in the channel block / sub-block are the same). Since the range will also be zero when there is only one unique color value in the channel block / sub-block, this determination can also be based on the range. If it is determined in step 2006 that there is only one unique color value in the block / sub-block, then in step 2008, a common value compression algorithm is selected. However, if it is determined in step 2006 that there is more than one unique color value in the channel block / sub-block, the method 2000 proceeds to step 2010.

[0141] In step 2010, determine whether the number of unique color values ​​exceeds a threshold value (e.g., 2, 3, or 4). If in step 2010, determine that the number of unique color values ​​does not exceed the threshold value, then in step 2012, select a lookup table compression algorithm to compress channel blocks / sub-blocks. However, if it is determined that the number of unique color values ​​does exceed the threshold value, then method 2000 proceeds to step 2014, at which step, determine whether the scope can be represented by bits less than the original color value or the initial color value. For example, if the original color value or the initial color value is each 8 bits, determine whether the scope can be represented by bits less than 8 bits. If in step 2014, determine that the scope can be represented by bits less than the original color value or the initial color value, then the initial value and the incremental compression algorithm can be selected in step 2016 to compress channel blocks / sub-blocks. However, if in step 2014, determine that the scope cannot be represented by bits less than the original color value or the initial color value, then in step 2018, determine not to compress channel blocks / sub-blocks.

[0142] It will be apparent to those skilled in the art that these are examples only, and any suitable criteria and / or method may be used to select a fixed length compression algorithm for compressing a channel block / sub-block. For example, in some cases, a compression algorithm that allows a channel block / sub-block to be represented by a minimum amount of data may be selected to compress the channel block / sub-block. For example, in some cases, if Fig. 20 If step 2010 of method 2000 determines that the number of unique color values ​​does not exceed the threshold value, the total amount of data (including the data in the lookup table and the index for each color value in the channel block / sub-block) stored using the lookup table compression algorithm can be determined instead of directly proceeding to step 2012, and compared with the total amount of data (including common basic information (e.g., initial value) and incremental value for each color value in the channel block / sub-block) stored using the initial value and incremental compression algorithm. If it is determined that the total amount of data stored in the channel block / sub-block using the lookup table compression algorithm is less than the total amount of data stored in the channel block / sub-block using the initial value and incremental compression algorithm, then the method can proceed to step 2012. However, if it is determined that the total amount of data stored in the channel block / sub-block using the lookup table compression algorithm is greater than or equal to the total amount of data stored in the channel sub-block using the initial value and incremental compression algorithm, then the method can proceed to step 2016.

[0143] Although the above-mentioned methods for selecting a fixed-length compression algorithm to compress a channel block / sub-block (e.g. Fig.19 and Fig. 20 The method of 1900 and 2000) is described as forming Figure 2 200, but in other examples, may be independent of Figure 2 The method 200 uses the described method to select a fixed length compression algorithm for a channel block / sub-block or for another data block.

[0144] Layered Compression

[0145] Generally, the larger the size of the compressed block / sub-block, the simpler the header of the compressed block can be, and thus the less header overhead. However, the color values ​​will be more diverse in larger channel blocks / sub-blocks, so the number of bits required to represent the color values ​​in larger channel blocks / sub-blocks is generally higher. Figure 8-10As shown in , the percentage of channel blocks / sub-blocks that require a higher number of incremental bits increases for channel block / sub-block sizes of 16x16 pixels and 32x32 pixels compared to channel block / sub-block sizes of 8x8 pixels. Experiments have shown that in the Manhattan 3.0 benchmark, the total compressed data size when using the initial value and incremental compression algorithm increases by 8% each time the compression block size increases. Specifically, in the Manhattan 3.0 benchmark, compressing channel blocks using the initial value and incremental compression algorithm in 8x8 blocks reduces the size of the image data by 61% relative to the uncompressed image data; in 16x16 blocks, the size of the image data is reduced by 54%; and in 32x32 blocks, the size of the image data is reduced by 46%. Therefore, in general, the smaller the size of the compressed block / sub-block, the better the compression. However, there will be some channel blocks that can be compressed well using larger block sizes.

[0146] Therefore, in order to improve compression efficiency without losing the ability to efficiently represent large blocks of similar color values, in some cases, a hierarchical compression scheme can be implemented, which may also be referred to as a multi-level compression scheme in this article. In the hierarchical compression scheme, blocks of channel blocks that are compressed together (i.e., as a unit) are dynamically selected from multiple block sizes. For example, it can be dynamically determined whether to compress a 32x32 channel block into a 32x32 block or into sixteen 8x8 blocks, rather than determining in advance that the 32x32 channel block is divided into sixteen 8x8 blocks that are compressed one by one. In some examples, non-square block sizes can be used. For example, block sizes of 32x16, 16x32, 16x8, or 8x16 can also be considered.

[0147] In some cases, there may be more than two compression sizes or compression levels to choose from. For example, a 32x32 channel block can be compressed at a 32x32 block level, a 16x16 block level, or an 8x8 block level. In these cases, any combination of lower level blocks can be used to compress the channel block. For example, a 32x32 block can be compressed into any combination of a 32x32 block or a 16x16 block and an 8x8 block. For example, a 16x16 block can be compressed into a unit, while other 16x16 blocks can be compressed into 8x8 blocks.

[0148] In these cases, Figure 2 The method 200 also includes selecting a block to be compressed for each channel block. Generally, the higher the diversity of color values ​​in the channel block, the smaller the size of the compressed block, and the lower the diversity of color values ​​in the channel block, the larger the size of the compressed block.

[0149] Any suitable criteria may be used to select blocks of a particular channel to be compressed. In some cases, blocks of a particular channel to be compressed may be selected by starting with a maximum block size, determining whether the channel can be appropriately compressed at that size, and if not, dividing the block into a plurality of sub-blocks, and if the sub-block is not the minimum block size, repeating the method for each sub-block (i.e., determining whether the sub-block can be compressed at that block size, and if not, dividing the block into a plurality of sub-blocks) until an appropriate compression algorithm is selected for each sub-block, or a minimum block size has been reached.

[0150] For example, Fig.21 A channel block 2100 is shown, which includes a 32x32 block of color values ​​that can be divided into four 16x16 sub-blocks 2102-0, 2102-1, 2102-2, 2102-3, each of which can be divided into four 8x8 sub-blocks 2104-0, 2104-1, 2104-2, 2104-3, 2104-4, 2104-5, 2104-6, 2104-7, 2104-8, 2104-9, 2104-10, 2104-11, 2104-12, 2104-13, 2104-14, 2104-15. In this example, any combination of 32x32 blocks, 16x16 blocks, and 8x8 blocks can be used to compress the channel block 2100. In this example, first determine whether the 32x32 channel block can be suitably compressed to a 32x32 block. If determine that the channel block can be compressed to a 32x32 block, compress this 32x32 block. However, if determine that the channel block can not be suitably compressed to a 32x32 block, so the 32x32 block is divided into four 16x16 blocks, and determine whether this block can be suitably compressed for each 16x16 block. If any 16x16 block can be suitably compressed, so compress this 16x16 block. However, if any 16x16 block can not be suitably compressed to a 16x16 block, so this 16x16 block is divided into 8x8 blocks and compression (or do not compress) 8x8 blocks. In some cases, determine whether the size of the fixed length parameter based on this channel block / subblock can be suitably compressed at this block size.

[0151] For example, this may result in the entire 32x32 block being compressed together, each 16x16 block being compressed together, one to three 16x16 blocks (e.g., blocks 2102-0, 2102-1, and 2102-2) being compressed together, and the remaining 16x16 blocks (e.g., block 2102-3) being compressed into 8x8 blocks (e.g., blocks 2104-12, 2104-13, 2104-14, 2104-15); or all 8x8 blocks being compressed one by one.

[0152] Reference now Fig. 22, which shows an exemplary method 2200 for selecting a block of a channel block to be compressed, which can be implemented by a compression unit such as the compression unit 2400 described below. The method 2200 begins at step 2202, at which a channel block to be compressed (e.g., a 32x32 block of color values ​​for a particular channel) is received. Once the channel block has been received, the method 2200 proceeds to step 2204, at which the received channel block is placed on a list of blocks to be compressed. Then, the method 2200 proceeds to step 2206, at which it is determined whether the list of blocks to be compressed is empty. If it is determined that the list is empty, the compression of the channel block is completed, and the method ends. However, if there is at least one block in the list of blocks to be compressed, the method 2200 proceeds to step 2208, at which one of the blocks in the list of blocks to be compressed is selected and removed from the list. In the first iteration of step 2208, the channel block will be selected. In any other iteration of block 2208 (if necessary), the channel sub-block will be selected. Once a block has been selected from the list of blocks to be compressed, method 2200 proceeds to step 2210.

[0153] At step 2210, a fixed length compression algorithm is selected or identified for compressing the block. Any suitable method may be used, such as but not limited to the above referenced methods. Fig.19 and 20 Those methods described are used to select or identify a fixed length compression algorithm for compressing a block. Once a fixed length compression algorithm for compressing a block has been selected or identified, method 2200 proceeds to step 2212.

[0154] At step 2212, it is determined whether the selected block is a minimum block size. If the selected block is a minimum block size, then the selected block must be compressed at this level, or not compressed (i.e., it cannot be divided into sub-blocks for compression). However, if the selected block is not a minimum size block, then the block can only be compressed at this level if the block can be properly compressed using a selected or identified fixed length compression algorithm. If the block cannot be properly compressed using a selected or identified fixed length compression algorithm, it can be divided into sub-blocks that can be compressed one by one. Therefore, if it is determined at step 2212 that the selected block is a minimum block size, then the method 2200 proceeds to step 2214, at which the selected block is compressed using the selected or identified fixed length compression algorithm (which may include storing the original or initial color values). However, if it is determined at step 2212 that the selected block is not a minimum block size (i.e., it is larger than a minimum size block), then the method 2200 proceeds to step 2216.

[0155] At step 2216, the size of the fixed length parameter is determined when the selected block is compressed using the selected fixed length compression algorithm. Once the size of the fixed length parameter is determined, the method 2200 then proceeds to step 2218. At step 2218, it is determined whether the size of the fixed length parameter exceeds a threshold value, which indicates that the block can be appropriately or efficiently compressed. In some cases, the threshold value can be 0, meaning that a higher level of block size can be used only when all color values ​​in the block are the same. In other cases, the threshold value can be another small number, such as but not limited to 1, 2 or 3. In some cases, the threshold value can be based on the size of the selected block. Therefore, blocks of different sizes can have different threshold values ​​(for example, the threshold value of a 32x32 block can be different from the threshold value of a 16x16 block). If it is determined at step 2218 that the size does not exceed the threshold value, then the method 2200 proceeds to step 2214, at which the selected block is compressed using the selected or identified fixed length compression algorithm.

[0156] However, if it is determined at step 2218 that the size of the fixed length parameter exceeds a threshold value (e.g., indicating that it is inappropriate or inefficient to compress the entire block together), then method 2200 proceeds to steps 2220 and 2222, in which the block is divided into a plurality of (e.g., n) sub-blocks and the sub-blocks are added to a list of blocks to be compressed. The number and size of the sub-blocks can be based on the size of the selected block and the block size supported by the compression unit. In some cases, the selected block is divided into sub-blocks of the next smallest supported block size. For example, if the channel block is a 32x32 pixel block, and the compression unit can compress the 32x32 pixel block at the 32x32 pixel block level, the 16x16 pixel block level, or the 8x8 pixel block level, then if the selected block is a 32x32 pixel block, it can be divided into four 16x16 pixel blocks, and if the selected block is a 16x16 pixel block, it can be divided into four 8x8 pixel blocks. Once a sub-block has been added to the list of blocks to be compressed, steps 2210 to 2222 are repeated for each sub-block.

[0157] Specifically, for each sub-block, a fixed length compression algorithm is selected or identified for the sub-block, and if the sub-block is the minimum block size supported, the sub-block is compressed using the selected or identified fixed length compression algorithm. However, if the sub-block is not the minimum block size supported, the size of the fixed length parameter of the selected fixed length compression algorithm is determined. If the size of the fixed length parameter does not exceed a threshold, the sub-block is compressed according to the selected fixed length compression algorithm. However, if the size of the fixed length parameter of the selected fixed length compression algorithm exceeds a threshold, the sub-block is further subdivided into sub-sub-blocks or micro-blocks, and the sub-sub-blocks or micro-blocks are added to a list of blocks to be compressed. Next, the method is repeated for the sub-sub-blocks or micro-blocks until the entire channel block has been compressed.

[0158] It will be apparent to those skilled in the art that where there is only one fixed length compression algorithm or the fixed length compression algorithm for the selected block is predetermined, then step 2210 may be omitted for that block.

[0159] It will be apparent to those skilled in the art that this is merely an exemplary method and that other suitable methods may be used to select blocks of channel blocks to be compressed. For example, other methods may work in reverse, i.e., they may start with the lowest level blocks and only consider compression of higher level blocks when it is possible to compress the lower level blocks with a certain number of bits.

[0160] When a layered compression scheme is implemented, a compressed block (e.g., a header of the compressed block) may also include information indicating which blocks of each channel have been compressed. For example, in some cases, the header of the compressed block may include information for each block at that level for each compression level, indicating whether the block has been compressed together for each channel. For example, RGBA image data of a 32x32 pixel block includes four 32x32 channel blocks of color values. If each channel block can be compressed into a 32x32 block, one or more 16x16 blocks, and / or one or more 8x8 blocks, then there are three levels of compression—Level 1: compression of 32x32 blocks; Level 2: compression of 16x16 blocks; and Level 3: compression of 8x8 blocks. In this example, there is one block at level 1, so the header of the compressed block may include information for the block, indicating whether the block has been compressed for each channel. There are four blocks at level 2, so the header may include information for each of the four blocks, indicating whether the block has been compressed for each channel. There are sixteen blocks at level 3, so the header may include information for each of the sixteen blocks indicating whether the block has been compressed for each channel.

[0161] Reference now Fig.23 , which shows an exemplary header 2302 for a compressed data block that has been generated using a layered compression scheme (i.e., dynamically selecting the blocks to be compressed and their sizes). In this example, a header is generated for a 32x32 block of image data having four channels, such that each of the four channel blocks includes a header similar to Fig.21 2100. In this example, there are three possible compression levels—Level 1: 32x32 blocks; Level 2: 16x16 blocks; and Level 3: 8x8 blocks. However, it will be apparent to those skilled in the art that this is merely an example and that the techniques and principles described herein can be applied to images / channel blocks of different sizes that can be compressed at different block sizes.

[0162] Fig.23The header 2302 of FIG. 2 is divided into a level 1 section 2304, a level 2 section 2306, and a level 3 section 2308. Each section 2304, 2306, 2308 includes information for each block at that level, which indicates whether the block is compressed for each channel. Each section 2304, 2306, 2308 also includes information indicating the length or size of the fixed length parameter and the common basis information of any blocks compressed at that level. In some cases, the corresponding section will also include information indicating the fixed length compression algorithm used to compress the block.

[0163] exist Fig.23 In the example shown, each section 2304, 2306, 2308 includes a set of compression fields for each block at that level (one compression field for each channel), which indicates whether the channel block is compressed at that level. For example, at level 1, there is only one block (32x32 block), so the level 1 section 2304 includes a set of four compression fields 2310, 2312, 2314, 2316 (one compression field for each channel) that indicate whether the 32x32 block of the channel is compressed. For example, the first compression field 2310 indicates whether the 32x32 block is compressed for channel 0, the second compression field 2312 indicates whether the 32x32 block is compressed for channel 1, the third compression field 2314 indicates whether the 32x32 block is compressed for channel 2, and the fourth compression field 2316 indicates whether the 32x32 block is compressed for channel 3. In this example, a "1" in a compression field indicates that the block is compressed for the channel, while a "0" indicates that the block of the channel is not compressed. When the compression field indicates a channel compression block for a particular level, it indicates that one of the available compression methods is used in the encoding to represent the channel block at that level, and it should be noted that the available compression methods may also include the original (or uncompressed) mode. Fig.232340. Similarly, at level 3, there are sixteen blocks (i.e., sixteen 8x8 blocks), so level 3 segment 2308 includes a set of four compression fields for each of the four 16x16 blocks (i.e., one compression field per channel), which indicates whether the 16x16 blocks of the channel are compressed. Thus, there are sixteen compression fields at level 2, eight of which are shown as fields 2322, 2324, 2326, 2328, 2334, 2336, 2338, and 2340. Similarly, at level 3, there are sixteen blocks (i.e., sixteen 8x8 blocks), so level 3 segment 2308 includes a set of four compression fields for each of the sixteen 8x8 blocks (i.e., one compression field per channel), which indicates whether the 8x8 blocks of the channel are compressed. Thus, at level 3 there are sixty-four compressed fields, eight of which are shown as fields 2342 , 2344 , 2346 , 2348 , 2358 , 2360 , 2362 , and 2364 .

[0164] If the compression field of any block indicates that the block is compressed for a channel, the corresponding sections 2304, 2306, and 2308 of the header 2302 also include information indicating the size or length of the fixed length parameter and the common base information for the block for the channel. Fig.23 In the example shown, for any block compressed for a channel, the corresponding section 2304, 2306, 2308 of the header 2302 includes: a length field 2318, 2330, 2350, 2352, 2366, 2368, 2370 indicating the length or size of the fixed length parameter of the block; and a common base information field 2320, 2332, 2354, 2356, 2372, 2374, 2376 indicating common base information for the block. For example, only the first 16x16 block (i.e., 16x16 block 0) is compressed for channel 2, so that the level 2 section 2306 includes a length field 2330 and a common base information field 2332 for channel 2 of the block. Similarly, the last 8x8 block (i.e., 8x8 block 15) is compressed for channels 0, 1, and 2 so that the level 3 segment 2308 includes length fields 2366, 2368, 2370 and common base information fields 2372, 2374, 2376 for each of channels 0, 1, and 2. The length field and common base information field may be as described above with respect to Fig.15 Configure as described above.

[0165] It will be apparent to those skilled in the art that this is merely an exemplary header and that the header may take any suitable form. Fig.16As described above, there may be a compression algorithm field, a length field, and a common base information field, rather than having a length field and a common base information field for each compressed block. In still other cases, there may be a single length field that indicates whether a block is compressed, and if so, also indicates the compression algorithm and the length or size of a fixed length parameter, rather than having separate compression and length fields. For example, as described above with respect to Fig.15 Described, can have 4-bit length field, wherein, 0 (" 0000 " (binary)) indicates that corresponding channel block is compressed using common value compression algorithm; Any digit between 1 (" 0001 " (binary)) and 7 (" 0111 " (binary)) indicates that corresponding channel block is compressed using initial value and incremental compression algorithm, and parameter length (that is, the number of incremental bits) equals this digit; 8 (" 1000 " (binary)) indicates that corresponding channel block is not compressed, and the original or initial color value of this channel block is included in the compressed block; And 15 (" 1111 " (binary)) indicates that corresponding channel block is not compressed (or, uncoded) at this level. This is summarized in Table 4.

[0166] Table 4

[0167]

[0168] In the case of compressing image data blocks using a layered compression scheme, fixed length parameters and / or initial color values ​​can be stored in the body at the smallest block level. For example, if each channel block can be compressed at a 32x32 block level or an 8x8 block level, then the fixed length parameters and / or initial color values ​​corresponding to each 8x8 image block can be stored or grouped together. This ensures that any pixel within a particular 8x8 block will be represented by the same number of data bits, thereby allowing random access to specific pixels within the block. Specifically, a channel will be compressed / uncompressed at this level, which means that the number of bits for each color value of the channel is fixed by the compression algorithm at this level / no compression at this level, or a channel will be compressed at a higher level, which means that the number of bits for each color value of the channel is fixed by the compression algorithm at this higher level.

[0169] Although the layered compression method is described as Figure 2 The method 200 may form part of the method 200, but in other examples, may be independent of Figure 2 The method 200 uses a layered compression method to compress channel blocks / sub-blocks or other image data (e.g., image data of a single two-dimensional block having only values). For example, in some cases, the layered compression method can be used to compress color data at the pixel level.

[0170] compression

[0171] Reference now Fig.24, the figure shows the Figure 2 An exemplary compression unit 2400 (which may form a block of image data) of the method 200 of compressing the image data Figure 1 The compression unit 2400 includes a header generation unit 2402 and a body generation unit 2404.

[0172] The header generation unit 2402 is configured to receive a block of image data to be compressed and generate a header of the compressed data block based on the received image data. The received image data includes data for an nxm block of pixels, which block of pixels can be divided into nxm blocks of color values ​​for each color channel. As described above, the header of the compressed data block includes information identifying which blocks of each channel block are compressed, and if a block of the channel block is compressed, the header also includes information identifying the length or size of the fixed length parameter of the block and common basis information of the block.

[0173] Where the blocks of each color channel to be compressed and the fixed-length compression algorithm to be used to compress those blocks are known, the header generation unit 2402 can be configured to determine, for each block of the channel blocks to be compressed, the length of the fixed-length parameters and the common basis information based on the color values ​​in those blocks. For example, if each 8x8 block of each channel block is to be compressed using an initial value and incremental compression algorithm, the header generation unit can be configured for each 8x8 block to: (i) analyze the color values ​​in the block to determine the range of values ​​in each 8x8 block; (ii) determine the number of incremental bits representing the range; and (iii) identify the initial value (e.g., minimum value).

[0174] In the case where the fixed length compression algorithm to be used to compress a specific block of the channel block is not known in advance (i.e., not predetermined), the header generation unit 2402 may also be configured to dynamically select the fixed length compression algorithm to be used to compress the specific block. The header generation unit 2402 may be configured to select one of a plurality of fixed length compression algorithms to be used to compress the specific block of the channel block in any suitable manner. For example, the header generation unit 2402 may be configured to select one of a plurality of fixed length compression algorithms to be used to compress the specific block of the channel block according to the method described above (e.g., respectively Fig.19 and 20 1900 or method 2000) to select a fixed length compression algorithm for compressing blocks of channel blocks.

[0175] In the case where the specific blocks of the channel blocks to be compressed are not known in advance (i.e., they are not predetermined), the header generation unit 2402 may also be configured to dynamically select blocks of the channel blocks to be compressed. Any suitable method may be used, such as described above with respect to Fig. 22 The hierarchical method 2200 is used to dynamically select blocks of channel blocks to be compressed.

[0176] The body generation unit 2404 is configured to receive the image data block and the header generated by the header generation unit 2402, and compress one or more blocks of at least one channel block according to the header. Specifically, the body generation unit 2404 compresses each of the one or more blocks of at least one channel by generating fixed length parameters for each color value of the block based on the information in the header. As described above, in the case where the blocks to be compressed are known in advance (i.e., predetermined) and the fixed length compression algorithm to be used to compress those blocks is known in advance (i.e., predetermined), the header may include information identifying the length or size of the fixed length parameters of each block to be compressed and the common basis information. In these cases, the body generation unit is configured to generate fixed length parameters for each color value in each relevant block based on the length of the fixed length parameters of the block and the common basis information of the block according to the known fixed length compression algorithm for the block. For example, if it is known in advance that an initial value and incremental compression algorithm will be used to compress each 8x8 block, the main body generation unit 2404 generates an incremental value (of a specified length) for each color value in each 8x8 block, which represents the difference between the color value of the block and the initial value.

[0177] In cases where the fixed length compression algorithm and / or the blocks to be compressed are not known in advance, the header may also include information indicating which blocks of each color block are to be compressed and / or the fixed length compression algorithm to be used to compress the associated blocks. In these cases, the body generation unit 2404 may be configured to identify which blocks of each channel block are to be compressed based on the information in the header and / or the fixed length compression algorithm to be used to compress each associated block.

[0178] Once the body generation unit 2404 has generated the fixed length parameters for each block to be compressed, the body generation unit 2404 can be configured to generate the body of the compressed block by combining or merging the fixed length parameters of each compressed block and the original color values ​​of each uncompressed block. As described above, in some cases, the body can be generated by packing the fixed length parameters and / or color values ​​of each pixel into pixel data units and then packing the pixel data units of each block together.

[0179] In some cases, the body and header may be merged (by body generation unit 2404 or another unit) to form a complete compressed block. However, in other cases, the body and header may be output separately.

[0180] The body and header may be stored together or separately in a memory (eg, a frame buffer).

[0181] Unzip

[0182] Reference now Fig.25, which shows the Figure 2 200 to provide channel color values ​​of selected pixels. Figure 1 The decompression unit 2500 includes: a header analysis unit 2502 configured to analyze the header to identify common basis information for channel color values ​​of selected pixels and a location of a fixed length parameter or color value for the channel color values ​​of the selected pixels in the body; and a body analysis unit 2504 configured to retrieve the fixed length parameter or color value from the identified location in the body; and a color value generation unit 2506 configured to generate a color value based on the common basis information and the fixed length parameter or color value. Reference will now be made to Fig.26 The operation of the decompression unit 2500 is described in detail.

[0183] Reference now Fig.26 , which illustrates an exemplary method 2600 for decompressing a compressed block of image data generated according to the methods described herein to generate channel color values ​​for selected pixels (which may be referred to herein as pixel channel color values), which may be performed by Fig.25 The method 2600 is implemented by the decompression unit 2500. The method 2600 begins at step 2602, where a compressed block of image data is received at the decompression unit 2500. As described herein, the compressed block of image data includes a header and a body. The header includes information indicating, for example, the blocks / sub-blocks compressed for each channel, and the length and common basis information of the fixed length parameters of each compressed block / sub-block. The body includes the fixed length parameters of each compressed block and the original color values ​​of each uncompressed block.

[0184] As described above, in some cases, the entire channel block can be compressed so that the header includes (i) a single set of common basis information for the channel block, and (ii) information identifying the length of the fixed length parameter; and the body includes the fixed length parameter for each color value in the channel block. In other cases, one or more sub-blocks of the channel block can be compressed. In these cases, the header includes (i) a set of common basis information for each compressed channel sub-block, and (ii) information identifying the length of the fixed length parameter for each compressed block; and the body includes the fixed length parameter for each color value in the sub-block for each compressed sub-block. For example, in the case where two sub-blocks of the channel block are compressed, the header may include (i) common basis information common to the color values ​​in the first sub-block and common basis information common to the color values ​​in the second sub-block, and (ii) information indicating the length of the fixed length parameter for the first sub-block and information indicating the length of the fixed length parameter for the second sub-block; and the body may include a first fixed length parameter for each color value in the first sub-block and a second fixed length parameter for each color value in the second sub-block. In the case where multiple channel sub-blocks are compressed, different sub-blocks may have different sizes and / or they may be compressed by different fixed length compression algorithms. For example, in a hierarchical compression scheme where a 32x32 channel block can be compressed at a 32x32 block level, a 16x16 block level, or an 8x8 block level, the 32x32 block can be compressed into a 32x32 block, or any combination of 16x16 and 8x8 blocks. For example, a 16x16 block can be compressed as one unit, while other 16x16 blocks can be compressed into 8x8 blocks. Similarly, where multiple channel sub-blocks are compressed, different fixed-length compression algorithms can be used to compress different sub-blocks.

[0185] Moreover, as described above, the compressed block of image data may include information representing the color values ​​of a single channel block or multiple channel blocks. In the case where the compressed block of image data includes information representing the color values ​​of multiple channel blocks (i.e., multiple color channels), the header may include information indicating which blocks / sub-blocks of each channel have been compressed, and for each block / sub-block of the compressed channel, the length of the common base information and the fixed length parameter, and optionally the fixed length compression algorithm used to compress the block / sub-block; and the body may include the fixed length parameter for each color value in the compressed channel block / sub-block and the color value of each uncompressed channel block / sub-block. Different channels may be compressed according to blocks / sub-blocks of different sizes and / or with different fixed length compression algorithms.

[0186] Once the compressed block of image data has been received, method 2600 proceeds to step 2604.

[0187] At step 2604, the header analysis unit 2502 analyzes the header of the compressed block to (i) determine the location of the fixed length parameters (if compressed) or color values ​​(if uncompressed) for the channel color of the selected pixel in the body; and (ii) determine the common basis information (if compressed) related to the channel color value for the selected pixel. In some cases, the location of the fixed length parameters (if compressed) or color values ​​(if uncompressed) in the body can be based on the size of the fixed length parameters of the compressed block / sub-block to which the desired color value belongs.

[0188] Specifically, when a block of image data is compressed according to the method described herein, the color values ​​within the lowest block / sub-block level associated with a particular channel will be represented by a fixed number of bits, and therefore, if the bits associated with each color value are stored in a predetermined order, the bits associated with a particular color value in the body of the compressed block can be determined from the number of bits used to represent the color values ​​of each channel.

[0189] For example, for a four-channel image, if the lowest block level of the compressed block is an 8x8 block, then each channel 0 color value in the 8x8 block will be represented by the same number of bits b0, each channel 1 color value in the 8x8 block will be represented by the same number of bits b1, each channel 2 color value in the 8x8 block will be represented by the same number of bits b2, and each channel 3 color value in the 8x8 block will be represented by the same number of bits b3. Therefore, if all bits associated with the same pixel are packed together to form a pixel data unit, then each pixel data unit will have b0+b1+b2+b3 bits. If the pixel data units of the block are then packed together in pixel order to form a block data unit, then i th The starting point of a pixel data unit for a pixel (where the first pixel is numbered 0) is located at i*(b0+b1+b2+b3) bits from the starting point of the block data unit. As described above, in some cases, the starting point of the block data unit can be determined from the length of the fixed length parameter; and in other cases, the header can include an offset value for the block indicating the offset of the starting point of the body of the compressed data block starting from the block data unit.

[0190] The specific bits of the pixel data unit corresponding to a specific color value can then be determined from b0, b1, b2, b3 and the ordering of the channels in the pixel data unit. For example, if the bits of each channel are packed together in the pixel data unit in channel order, then the bits corresponding to the color value of channel 0 are the first b0 bits in the pixel data unit; the bits corresponding to the color value of channel 1 are the b1 bits starting from bit b0; the bits corresponding to the color value of channel 2 are the b2 bits starting from bit b0+b1; and the bits corresponding to the color value of channel 3 are the last b3 bits starting from bits b0+b1+b2.

[0191] If the fixed length compression algorithm is not predetermined, the header analysis unit 2502 may also determine the fixed length compression algorithm used to compress the channel color value of the selected pixel from the header. Once the fixed length parameters or the location of the color value in the body and the common basis information have been determined from the header of the compressed block, the method 2600 proceeds to step 2606.

[0192] At step 2606, the body analysis unit 2504 retrieves the fixed length parameters (if compressed) or the color values ​​(if uncompressed) of the channel color values ​​for the selected pixel from the location of the body determined by the header analysis unit. Once the fixed length parameters or the original color values ​​have been retrieved from the body of the compressed block, the method 2600 proceeds to step 2608.

[0193] At step 2608, the color value generation unit 2506 generates the original color value from the retrieved color value (if not compressed) or from the common basis information and the fixed length parameters (if compressed). The manner in which the initial color value is generated from the common basis information and the fixed length parameters is based on the fixed length compression algorithm used to compress the channel color values.

[0194] For example, if the color values ​​are compressed using a common value compression algorithm, the common basis information includes the common color value, the fixed length parameter has zero bits, and the common color value is used as the channel color value; if the color values ​​are compressed using an initial value and incremental compression algorithm, the common basis information includes the initial value, the fixed length parameter includes an incremental value representing the difference between the initial value and the color value, and the initial value and the incremental value are added (as described above, in some cases, the addition can be performed by modulo m, where m=2 x , where each color value includes x bits) to generate the required color value; if the color value is compressed using a multiple initial value and incremental compression algorithm, then the common base information includes multiple initial values, the fixed length parameter includes an index identifying one of the initial values ​​and an incremental value representing the difference between the identified initial value and the color value, and by adding the identified initial value and the incremental value (as described above, in some cases, the addition can be performed by modulo m, where m=2x , where each color value includes x bits) to generate a desired color value; if a lookup table compression algorithm is used to compress the color values, the common basis information includes a lookup table having multiple color values, the fixed length parameter includes an index identifying one of the color values ​​in the lookup table (i.e., an index pointing to the lookup table), and the color value identified by the index is used as the desired color value; and if a predetermined color compression algorithm is used to compress the color values, the common basis information includes information identifying one of one or more predetermined color values, the fixed length parameter includes zero bits, and the identified predetermined color value is used as the desired color value.

[0195] As described above, when a predetermined color compression algorithm is used, there may be only a single predetermined color value, and the common basis information may include information indicating that the color value is compressed using the predetermined color compression algorithm. In other cases, there may be multiple predetermined color values, wherein one or more of the predetermined color values ​​are fixed and / or one or more of the predetermined color values ​​may be configurable. In some cases, the common basis information may identify specific predetermined color values ​​for more than one channel. For example, the common basis information may indicate that the color value of the first channel is a specific predetermined color value, and the color value of the second channel is a specific predetermined color value. For example, the common basis information may indicate that the pixel color value (i.e., a combination of channel color values) of the pixels in the compressed block is a predetermined value.

[0196] The fixed length compression algorithm used to compress the color values ​​may be predetermined or determined from the header by the header analysis unit 2502 and then provided to the color value generation unit 2506 .

[0197] Test Results

[0198] Reference now Fig. 27 , which shows the results of the Manhattan 3.0 benchmark using the compression method. Specifically, Fig. 27The size of a compressed block of image data (including header data and body data) relative to an uncompressed block of image data is shown when a 32x32 block of image data is compressed at a single compression level (i.e., 32x32 blocks, 16x16 blocks, or 8x8 blocks) using an initial value and incremental compression method. As can be seen at 2702, when a 32x32 block of image data is compressed in 8x8 blocks, the size of the compressed data block is 40% of the size of the uncompressed block of image data, a 60% reduction. As shown at 2704, when a 32x32 block of image data is compressed in 16x6 blocks, the size of the compressed data block is 46% of the size of the uncompressed block of image data, a 54% reduction. As shown at 2706, when a 32x32 block of image data is compressed in 32x32 blocks, the size of the compressed data block is 54% of the size of the uncompressed block of image data, a 46% reduction. Thus, it has been shown that the simpler single-stage compression works particularly well for the 8x8 block level.

[0199] Fig. 27 It is also shown that at 2708, when a layered compression method is implemented such that if there are common color values ​​in the 16x16 blocks, then 32x32 blocks are compressed at the 16x16 block level, and otherwise 8x8 blocks are compressed using an initial value and incremental compression algorithm, the size of the compressed block of image data is 39% of the size of the uncompressed block of image data, a reduction of 61%. Fig. 27 It is also shown that at 2710, when the layered compression method is implemented such that if there are common color values ​​in the 32x32 blocks, the 32x32 blocks are compressed at the 32x32 level, otherwise the 8x8 blocks are compressed using the initial value and incremental compression algorithm, the size of the compressed block of image data is 39% of the size of the uncompressed block of image data, which is also reduced by 61%. Therefore, an improvement in the level of compression can be achieved using a layered compression scheme, but this increases the complexity of compression and decompression. It is found that, on average, the size of the header is approximately 7% of the size of the compressed block of image data.

[0200] Reference now Fig.28 , which shows the percentage of 8x8 blocks having common color values ​​(also referred to herein as unique color blocks) for each of a number of benchmarks, for each of a number of different block sizes.

[0201] Reference now Fig.29 , which shows the size of a compressed block of image data (including header data and body data) relative to an uncompressed block of image data when a 32x32 block of image data is compressed according to each of the following schemes for each of a number of benchmarks:

[0202] Single compression level: 8x8 blocks - using initialization and incremental compression algorithm

[0203] Single compression level: 16x16 blocks - using initialization and incremental compression algorithm

[0204] Single compression level: 32x32 blocks - using initialization and incremental compression algorithm

[0205] Multi-level compression:

[0206] ο 32x32 blocks (if they have a common value) - use the common value compression algorithm

[0207] ο16x16 blocks (if they have a common value) - use the common value compression algorithm

[0208] ο8x8 blocks, using initialization and incremental compression algorithms

[0209] Fig.30 A computer system in which the compression unit, decompression unit, and compression / decompression unit described herein may be implemented is shown. The computer system includes a CPU 3002, a GPU 3004, a memory 3006, and other devices 3014, such as a display 3016, a speaker 3018, and a camera 3020. A processing block 3010 (which may be a compression unit, a decompression unit, or a compression / decompression unit described herein) is implemented on the GPU 3004. In other examples, the processing block 3010 may be implemented on the CPU 3002. The components of the computer system may communicate with each other via a communication bus 3022.

[0210] Figure 24-25 The compression unit and decompression unit are shown as comprising a plurality of functional blocks or units. This is merely illustrative and is not intended to define a strict division between different logical elements of such entities. Each functional block or unit may be provided in any suitable manner. It should be understood that intermediate values ​​described herein as being formed by blocks or units need not be physically generated by the compression or decompression unit at any point, and may simply represent logical values ​​that conveniently describe the processing performed by the compression or decompression unit between its input and output.

[0211] The compression unit, decompression unit and / or compression / decompression unit described herein can be implemented in hardware on an integrated circuit. The compression unit, decompression unit and / or compression / decompression unit described herein can be configured to perform any method described herein. In general, any of the functions, methods, techniques or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry) or any combination thereof. The terms "module", "function", "component", "element", "unit", "block" and "logic" can be used herein to generally represent software, firmware, hardware or any combination thereof. In the case of software implementation, a module, function, component, element, unit, block or logic represents a program code, which performs a specified task when executed on a processor. The algorithms and methods described herein can be performed by one or more processors that execute code, and the code enables the processor to perform the algorithm / method. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disk, flash memory, hard disk storage, and other memory devices that can use magnetic, optical and other technologies to store instructions or other data and can be accessed by a machine.

[0212] As used herein, the terms computer program code and computer readable instructions refer to any kind of executable code for execution by a processor, including code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, byte code, code that defines an integrated circuit (such as a hardware description language or netlist), and code expressed in programming language code such as C, Java, or OpenCL. Executable code can be, for example, any kind of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled, run in a virtual machine or other software environment, causes a processor of a computer system supporting the executable code to perform the tasks specified by the code.

[0213] A processor, computer or computer system may be any kind of device, machine or special purpose circuit, or a collection or part thereof, which has processing capabilities so that instructions can be executed. A processor may be any kind of general or special purpose processor, such as a CPU, GPU, system on a chip, state machine, media processor, application specific integrated circuit (ASIC), programmable logic array, field programmable gate array (FPGA), etc. A computer or computer system may include one or more processors.

[0214] The present invention is also intended to cover software that defines the configuration of hardware as described herein, such as hardware description language (HDL) software, for designing integrated circuits or for configuring programmable chips to perform desired functions. That is, a computer readable storage medium may be provided having encoded thereon computer readable program code in the form of an integrated circuit definition data set, which, when processed (i.e., run) in an integrated circuit manufacturing system, configures the system to manufacture a compression unit, a decompression unit, or a compression / decompression unit configured to perform any of the methods described herein, or to manufacture a processor including any of the apparatus described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.

[0215] Thus, a method of manufacturing a system, a compression unit, a decompression unit and / or a compression / decompression unit as described herein in an integrated circuit manufacturing system may be provided. Furthermore, an integrated circuit definition data set may be provided, which, when processed in an integrated circuit manufacturing system, causes the method of manufacturing a compression unit, a decompression unit and / or a compression / decompression unit to be performed.

[0216] The integrated circuit definition data set may be in the form of computer code, for example as a netlist, code for configuring a programmable chip, as a hardware description language that defines hardware suitable for fabrication at any level in an integrated circuit, including as register transfer level (RTL) code, as a high-level circuit representation such as Verilog or VHDL, and as a low-level circuit representation such as OASIS (RTM) and GDSII. Higher-level representations that logically define hardware suitable for fabrication in an integrated circuit, such as RTL, may be processed on a computer system configured to generate a manufacturing definition of the integrated circuit in the context of a software environment that includes definitions of circuit elements and rules for combining those elements to generate a manufacturing definition of the integrated circuit defined by the representation. As is typically the case with software executed at a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate a manufacturing definition of the integrated circuit to execute code that defines the integrated circuit to generate the manufacturing definition of the integrated circuit.

[0217] Now refer to Fig.31 Examples of processing an integrated circuit definition data set at an integrated circuit manufacturing system to configure the system to manufacture a compression unit, a decompression unit, and / or a compression / decompression unit are described.

[0218] Fig.31An example of an integrated circuit (IC) manufacturing system 3102 is shown, which is configured to manufacture a compression unit, a decompression unit, and / or a compression / decompression unit as described in any of the examples herein. Specifically, the IC manufacturing system 3102 includes a layout processing system 3104 and an integrated circuit generation system 3106. The IC manufacturing system 3102 is configured to receive an IC definition data set (e.g., defining a compression unit, a decompression unit, and / or a compression / decompression unit as described in any of the examples herein), process the IC definition data set, and generate an IC (e.g., which embodies a compression unit, a decompression unit, and / or a compression / decompression unit as described in any of the examples herein) based on the IC definition data set. The processing of the IC definition data set configures the IC manufacturing system 3102 to manufacture an integrated circuit that embodies a compression unit, a decompression unit, and / or a compression / decompression unit as described in any of the examples herein.

[0219] The layout processing system 3104 is configured to receive and process an IC definition data set to determine a circuit layout. Methods for determining a circuit layout based on an IC definition data set are known in the art and may, for example, involve synthesizing RTL code to determine a gate-level representation of a circuit to be generated, such as in terms of logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining location information for the logic components, the circuit layout may be determined based on the gate-level representation of the circuit. This may be done automatically or with user involvement in order to optimize the circuit layout. When the layout processing system 3104 determines the circuit layout, it may output the circuit layout definition to the IC generation system 3106. The circuit layout definition may be, for example, a circuit layout description.

[0220] As is known in the art, IC generation system 3106 generates ICs according to the circuit layout definition. For example, IC generation system 3106 can implement a semiconductor device manufacturing process to generate ICs, which can involve a multi-step sequence of photolithography and chemical processing steps during which electronic circuits are gradually formed on a wafer made of semiconductor material. The circuit layout definition can be in the form of a mask that can be used in a photolithography process to generate ICs according to the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 3106 can be in the form of a computer readable code that IC generation system 3106 can use to form a suitable mask for generating the IC.

[0221] The different processes performed by the IC manufacturing system 3102 can all be implemented in one location, such as by one party. Alternatively, the IC manufacturing system 3102 can be a distributed system so that some processes can be performed in different locations and can be performed by different parties. For example, some of the following stages can be performed in different locations and / or by different parties: (i) synthesizing RTL code representing an IC definition data set to form a gate-level representation of a circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) forming a mask based on the circuit layout; and (iv) using the mask to manufacture the integrated circuit.

[0222] In other examples, processing of an integrated circuit definition data set at an integrated circuit manufacturing system may configure the system to manufacture a compression unit, a decompression unit, or a compression / decompression unit without processing the IC definition data set to determine a circuit layout. For example, an integrated circuit definition data set may define a configuration of a reconfigurable processor such as an FPGA, and processing of the data set may configure the IC manufacturing system to generate (e.g., by loading configuration data into the FPGA) a reconfigurable processor having the defined configuration.

[0223] In some embodiments, when processed in an integrated circuit manufacturing system, the integrated circuit manufacturing definition data set can enable the integrated circuit manufacturing system to generate a device as described herein. Fig.31 The configuration of an integrated circuit manufacturing system in the described manner can manufacture the device described herein.

[0224] In some examples, the integrated circuit definition data set may include software that runs on, or in combination with, the hardware defined at the data set. Fig.31 In the example shown, the IC generation system can also be configured by the integrated circuit definition data set to load firmware onto the integrated circuit when manufacturing the integrated circuit according to the program code defined in the integrated circuit definition data set, or otherwise provide the integrated circuit with program code for use with the integrated circuit.

[0225] Compared to known implementations, the implementation of the concepts set forth in this application in devices, apparatuses, modules and / or systems (and in the methods implemented herein) can cause performance improvements. Performance improvements can include one or more of improved computing performance, reduced waiting time, increased throughput and / or reduced power consumption. During the manufacture of such devices, devices, modules and systems (e.g., in integrated circuits), a trade-off can be made between performance improvements and physical implementations to improve manufacturing methods. For example, a trade-off can be made between performance improvements and layout area to match the performance of known implementations, but using less silicon. For example, this can be accomplished by reusing functional blocks in a serial manner or sharing functional blocks between elements of devices, devices, modules and / or systems. On the contrary, the concepts of improvements (e.g., reduced silicon area) that cause physical implementations of devices, devices, modules and systems set forth in this application can be weighed against performance improvements. For example, this can be accomplished by manufacturing multiple instances of a module within a predefined area budget.

[0226] Applicants hereby independently disclose each individual feature described herein and any combination of two or more such features, to the extent that such feature or combination can be implemented according to the common general knowledge of a person skilled in the art based on the specification as a whole, regardless of whether such feature or combination of features solves any problem disclosed herein. In view of the foregoing description, it will be clear to a person skilled in the art that various modifications can be made within the scope of the invention.

Claims

1. A method (200) for compressing an image data block, the image data block comprising a plurality of image element values, each image element value being divisible into at least a first value and a second value, such that the image data block comprises a two-dimensional block of the first value and a block of the second value, the method (200) comprising: Compressing (206) all or a portion of a first data set including a two-dimensional block of the first value according to a first fixed length compression algorithm to generate a first compressed block by: identifying common base information of the first data set; as well as identifying a fixed length parameter for each first value in the first data set, each first value in the first data set being obtainable from common base information of the first data set and the fixed length parameter for the first value, the fixed length parameter being zero, one, or more than one bit in length; A second data set comprising all or a portion of the two-dimensional block of the second value is compressed (206) according to a second fixed length compression algorithm to generate a second compressed block by: identifying common base information of the second data set; and identifying a fixed length parameter for each second value in the second data set, each second value in the second data set being obtainable from common base information of the second data set and the fixed length parameter for the second value, the fixed length parameter being zero, one, or more than one bit in length; A compressed block of the image data block is formed (208) based on the first compressed block and the second compressed block by: forming a header of the compressed block, wherein the header includes common base information of the first data set and common base information of the second data set, information indicating a size of a fixed length parameter for each first value in the first data set, and information indicating a size of a fixed length parameter for each second value in the second data set; as well as forming a body of the compressed block, wherein the body includes a fixed length parameter for each first value in the first data set and a fixed length parameter for each second value in the second data set, The size of the first data set is different from the size of the second data set.

2. The method (200) of claim 1, wherein: Each first value and each second value corresponds to one pixel of the plurality of pixels; The body of the compression block comprises a pixel data unit for each pixel, the pixel data unit comprising: first data corresponding to the first value of the pixel in the two-dimensional block representing the first value, the first data including the first value or a fixed-length parameter generated according to a fixed-length compression algorithm for the first value; The second data corresponding to the second value of the pixel in the two-dimensional block representing the second value includes the second value or a fixed-length parameter generated according to a fixed-length compression algorithm for the second value.

3. The method (200) according to claim 2, wherein: The pixel data units are grouped into blocks, and first data of each pixel data unit in the block has the same size, and second data of each pixel data unit in the block has the same size.

4. The method (200) of claim 3, wherein: Each pixel data unit block includes X pixel data units; The first data set comprises Y first values ​​of a two-dimensional block of the first values; and X is an integer greater than or equal to 2, and Y is an integer multiple of X.

5. The method (200) according to claim 1 or 2, wherein: The first fixed-length compression algorithm and the second fixed-length compression algorithm are different.

6. The method (200) according to claim 1 or 2, wherein: The first data set comprises a first portion of a two-dimensional block of the first values, and the method (200) further comprises compressing a third data set comprising a second portion of the two-dimensional block of the first values ​​according to a third fixed length compression algorithm to generate a third compressed block, and wherein the compressed block of the image data block is further based on the third compressed block.

7. The method (200) of claim 6, wherein: The first fixed-length compression algorithm and the second fixed-length compression algorithm are different.

8. The method (200) of claim 6, wherein: The first data set and the third data set have different sizes.

9. The method (200) of claim 1 or 2, further comprising subdividing the two-dimensional block of the first values ​​into a plurality of sub-blocks, and wherein the first data set is one of the plurality of sub-blocks.

10. The method (200) according to claim 1 or 2, further comprising: Before compressing the first data set, the first data set is selected by: subdividing the two-dimensional block of the first value into a plurality of sub-blocks; determining whether one of the sub-blocks can be suitably compressed using a fixed length compression algorithm; In response to determining that the one of the sub-blocks can be suitably compressed using a fixed-length compression algorithm, selecting the one of the sub-blocks as the first data set; as well as In response to determining that the one of the sub-blocks cannot be properly compressed using a fixed length compression algorithm, the one of the sub-blocks is subdivided into a plurality of micro-blocks and one of the micro-blocks is selected as the first data set.

11. The method (200) according to claim 1 or 2, further comprising: Before compressing the first data set, the first data set is selected by: determining whether the two-dimensional block of the first value can be suitably compressed using a fixed length compression algorithm; In response to determining that the two-dimensional block of the first values ​​can be suitably compressed using a fixed-length compression algorithm, selecting the two-dimensional block of the first values ​​as the first data set; as well as In response to determining that the two-dimensional block of the first values ​​cannot be properly compressed using a fixed length compression algorithm, the two-dimensional block of the first values ​​is subdivided into a plurality of sub-blocks and one of the sub-blocks is selected as the first data set.

12. The method (200) of claim 10, wherein: Determining whether a block or sub-block of values ​​can be suitably compressed using a fixed length compression algorithm includes determining whether a size of the compressed block or sub-block is less than or equal to a predetermined threshold when the block or sub-block is compressed according to the fixed length compression algorithm.

13. The method (200) according to claim 1 or 2, wherein: Each first value is a color value of a first color channel, and each second value is a color value of a second color channel.

14. The method (200) according to claim 1 or 2, further comprising: analyzing first values ​​in the first data set to generate one or more diversity statistics; as well as Based on the one or more diversity statistics, one of a plurality of fixed-length compression algorithms is selected as the first fixed-length compression algorithm.

15. The method (200) according to claim 1 or 2, wherein: If all first values ​​in the first data set are the same and match one of the one or more predetermined values, the common base information of the first data set includes information identifying the one of the one or more predetermined values, and the fixed length parameter of each first value of the first data set has zero bits.

16. The method (200) according to claim 1 or 2, wherein: The common basic information of the first data set includes an initial value based on a first value in the first data set, and the fixed length parameter of each first value of the first data set includes a difference between the first value and the initial value.

17. The method (200) according to claim 1 or 2, wherein: The common basic information of the first data set includes multiple initial values ​​based on the first value in the first data set, and the fixed length parameter of each first value of the first data set includes an index identifying an initial value among the multiple initial values ​​and a difference between the first value and the identified initial value.

18. The method (200) according to claim 1 or 2, wherein: The common base information of the first data set includes a lookup table of unique first values ​​in the first data set, and the fixed length parameter of each first value in the first data set includes an index pointing to the lookup table.

19. The method (200) according to claim 1 or 2, wherein: If all first values ​​in the first data set are the same, the common base information of the first data set includes the common first value, and the fixed length parameter of each first value of the first data set has zero bits.

20. The method (200) according to claim 1 or 2, wherein: The header also includes information indicating the first fixed-length compression algorithm and information indicating the second fixed-length compression algorithm.

21. A compression device (2400) for compressing an image data block (300), the image data block (300) comprising a plurality of image element values, each image element value being divisible into at least a first value and a second value, so that the image data block comprises a two-dimensional block of the first value and a two-dimensional block of the first two values ​​(302, 304, 306, 308), the compression device (2400) comprising: A header generation unit (2402), the header generation unit being configured to: identifying a length of a fixed length parameter and common basis information for compressing a first data set according to a first fixed length compression algorithm, the first data set comprising all or a portion of a two-dimensional block of the first value; identifying a length of a fixed length parameter and common basis information for compressing a second data set according to a second fixed length compression algorithm, the second data set comprising all or a portion of the two-dimensional block of the second value; as well as forming a header of a compressed block, the header comprising common base information of the first data set and common base information of the second data set, information indicating a size of a fixed length parameter for the first data set, and information indicating a size of a fixed length parameter for the second data set; and A subject generation unit (2404), the subject generation unit being configured to: identifying a fixed length parameter for each first value in the first data set according to the first fixed length compression algorithm, each first value in the first data set being obtainable from common base information of the first data set and the fixed length parameter for the first value; identifying a fixed length parameter for each second value in the second data set according to the second fixed length compression algorithm, each second value in the second data set being obtainable from common base information of the second data set and the fixed length parameter for the second value; forming a body of the compressed block, wherein the body includes a fixed length parameter for each first value in the first data set and a fixed length parameter for each second value in the second data set, The size of the first data set is different from the size of the second data set.

22. A computer-readable storage medium having computer-readable instructions stored thereon, which, when executed at a computer system, cause the computer system to perform the method according to any one of claims 1 to 21.

23. A computer-readable storage medium having stored thereon a computer-readable description of a compression device according to claim 21, wherein the computer-readable description, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit including the compression device.

Citation Information

Patent Citations

  • Data compression

    GB2530311A