Guaranteed data compression

Abstract

A lossy method and hardware for compressing data and corresponding decompression methods and hardware are described. The lossy compression method includes dividing a pixel block into a plurality of sub-blocks, and then analyzing each sub-block and selecting one of a set of candidate lossy compression modes. The analysis can be based, for example, on alpha values ​​of the pixels in the sub-blocks. In various examples, the set of candidate lossy compression modes includes at least one mode that uses a fixed alpha channel value for all pixels in the sub-blocks, and one or more modes that encode variable alpha channel values.

Description

Background Art

[0001] Data compression, whether lossless or lossy, is desirable in many applications where data is to be 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. Examples of data for which data compression is particularly useful are image data, such as depth data to be stored in a depth buffer, pixel data to be stored in a frame buffer, and texture data to be stored in a texture buffer. These buffers may 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.

[0002] A graphics processing unit (GPU) can be used to process image data in order to determine the pixel values ​​of an image to be stored in a frame buffer for output to a display. GPUs typically have a highly parallelized structure for processing large blocks of data in parallel. There is tremendous commercial pressure to enable GPUs, especially those intended for implementation on mobile devices, to operate at lower power levels. Contrary to this, the desire to use higher quality rendering algorithms on faster GPUs puts pressure on a relatively limited resource, memory bandwidth. However, increasing the bandwidth of the memory subsystem may not be an attractive solution because moving data to and from the GPU, or even moving data within the GPU, consumes a large portion of the GPU's power budget. The same problem may be faced by other processing units, such as central processing units (CPUs) and GPUs.

[0003] 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 data compression methods. Summary of the invention

[0004] This summary is provided to introduce some concepts in a simplified form, which are further described in the detailed description below. 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.

[0005] Lossy methods and hardware for compressing data and corresponding decompression methods and hardware are described. The lossy compression method includes dividing a pixel block into a plurality of sub-blocks, and then analyzing each sub-block and selecting one of a set of candidate lossy compression modes. The analysis can be based, for example, on alpha values ​​of pixels in the sub-block. In various examples, the set of candidate lossy compression modes includes at least one mode that uses a fixed alpha channel value for all pixels in the sub-block, and one or more modes that encode variable alpha channel values.

[0006] A first aspect provides a lossy method for compressing data, comprising: dividing a pixel block into a plurality of sub-blocks; and for each sub-block: analyzing an alpha channel value of each pixel in the sub-block to select a lossy compression mode from a set of candidate lossy compression modes, wherein the set of candidate lossy compression modes comprises two or more lossy compression modes, including at least one compression mode that uses a fixed alpha channel value for all pixels in the sub-block; and compressing the sub-block using the selected lossy compression mode.

[0007] A second aspect provides a data decompression method, comprising: unpacking data from a compressed data block to generate compressed data of multiple sub-blocks; for each sub-block: identifying a compression mode from a block mode field within the compressed data block, wherein the compression mode is one of a set of candidate lossy compression modes, the set of candidate lossy compression modes including two or more lossy compression modes, including at least one compression mode using a fixed alpha channel value for all pixels in the sub-block; and decompressing the sub-block using a decompression mode corresponding to the selected compression mode.

[0008] A third aspect provides a data compression unit, comprising: hardware logic, which is arranged to divide a pixel block into multiple sub-blocks; hardware logic, which is arranged to analyze the alpha channel value of each pixel in the sub-block for each sub-block to select a lossy compression mode from a set of candidate lossy compression modes, wherein the set of candidate lossy compression modes includes two or more lossy compression modes, including at least one compression mode that uses a fixed alpha channel value for all pixels in the sub-block; and a data compression element, which is arranged to compress the sub-block using the selected lossy compression mode.

[0009] A fourth aspect provides a data decompression unit, comprising: hardware logic, which is arranged to unpack data from a compressed data block to generate compressed data of multiple sub-blocks; hardware logic, which is arranged to, for each sub-block, identify a compression mode from a block mode field within the compressed data block, wherein the compression mode is one of a set of candidate lossy compression modes, the set of candidate lossy compression modes including two or more lossy compression modes, including at least one compression mode that uses a fixed alpha channel value for all pixels in the sub-block; and a data decompression element, which is arranged to decompress the sub-block using a decompression mode corresponding to the selected lossy compression mode.

[0010] A data compression and / or decompression unit as described herein may be implemented in hardware on an integrated circuit. A method of manufacturing a data compression and / or decompression unit as described herein in an integrated circuit manufacturing system may be provided. An integrated circuit definition data set may be provided, which, when processed in an integrated circuit manufacturing system, configures the system to manufacture a data compression and / or decompression unit as described herein. A non-transitory computer-readable storage medium may be provided, having stored thereon a computer-readable description of an integrated circuit, which, when processed, causes a layout processing system to generate a circuit layout description for use in the integrated circuit manufacturing system to manufacture a data compression and / or decompression unit as described herein.

[0011] An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable integrated circuit description describing a data compression and / or decompression unit as described herein; a layout processing system configured to process the integrated circuit description so as to generate a circuit layout description of an integrated circuit embodying the data compression and / or decompression unit as described herein; and an integrated circuit generation system configured to manufacture the data compression and / or decompression unit as described herein based on the circuit layout description.

[0012] Computer program code for performing any of the methods as described herein may be provided.A non-transitory computer-readable storage medium having computer-readable instructions stored thereon may be provided, which, when executed at a computer system, causes the computer system to perform any of the methods as described herein.

[0013] The above-described features may be combined as appropriate, as will be apparent to the skilled person, and may be combined with any aspects of the examples as described herein. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1 A graphics rendering system is shown;

[0016] Figure 2A , 2B and 2C show three different data compression architectures;

[0017] Figure 3A is a flow chart of an example lossy data compression method;

[0018] Figure 3B is a flowchart of a data decompression method that can be used to decompress data using Figure 3A The method compresses the data;

[0019] Figure 4A and 4B is a schematic diagram showing different data blocks and their subdivision into sub-blocks;

[0020] Figure 4C is a schematic diagram illustrating an example compressed data block;

[0021] Figure 5A and 5B Shows Figure 3A Two different example implementations of the analysis phase of the method;

[0022] Fig. 6A is used Figure 3A A flowchart of a first example method for compressing a sub-block using a constant alpha mode;

[0023] Figure 6B , 6C and 6D are schematic diagrams showing two different ways of packing compressed values ​​into one data block;

[0024] Fig. 7A is used Figure 3A A flowchart of a second example method for compressing a sub-block using a constant alpha mode;

[0025] Figure 7B It shows that Fig. 7A A schematic diagram of an example of how to divide pixels in a sub-block into two subsets in the method;

[0026] Fig. 8A is used Figure 3A A flowchart of a first example method of compressing a sub-block using a variable alpha mode;

[0027] Figure 8B It shows Fig. 8A a schematic diagram of a portion of a method;

[0028] Fig. 9 is used Figure 3A A flowchart of a second example method for compressing a sub-block using a variable alpha mode;

[0029] Fig. 10A It shows that it can be Fig. 9 A schematic diagram of a coding pattern used in the method;

[0030] Fig. 10B and 10C is a schematic diagram showing two different ways of packing compressed data of a mini-block into a data field;

[0031] Fig. 10D It shows that it can be Fig. 9 Schematic diagram of two additional coding patterns used in the method of;

[0032] Fig.11 is a flow chart of another example method for compressing a sub-block using a constant alpha mode;

[0033] Fig. 12A is a flow chart of a method for converting an n-bit number into an m-bit number, where n>m;

[0034] Fig. 12B yes Fig. 12A A schematic diagram of a hardware implementation of the method;

[0035] Fig.13A is a flowchart of a method for converting an n-bit number into an m-bit number, where n <m;

[0036] Fig. 13B yes Fig.13A A schematic diagram of a hardware implementation of the method;

[0037] Fig. 13C and 13D It shows Fig.13A Schematic diagram of two examples of the method;

[0038] Fig.14 is a flow chart of a first example method of converting 10-bit data into 8-bit data;

[0039] Fig.15A , 15B , 15C and 15D are diagrams showing the use of Fig. 9 still Fig.11 Methods, schematic diagrams of four different ways to pack data into data fields;

[0040] Fig.16 is a flow chart of a first example method of converting 10-bit data into 8-bit data;

[0041] Fig.17 It shows Fig.16 A schematic diagram of the method;

[0042] Fig.18A Yes Fig.16 A flowchart of a data compression method combining a preprocessing method with a lossless data compression method;

[0043] Fig.18B It can be used Fig.18A A flowchart of a method for decompressing data used in the case of compressing data;

[0044] Fig.19A is a schematic diagram of another example data compression unit;

[0045] Fig.19B yes Fig.19AA flowchart of a method of operation of a bit predictor element in a data compression unit is shown;

[0046] Fig.19C It shows the use of Fig.19A A schematic diagram of an example manner in which the method packs data into compressed data blocks;

[0047] Fig. 20A shows a schematic diagram of another data compression unit;

[0048] Fig. 20B is a flow chart of a lossless data compression method;

[0049] Fig.21A is used Fig. 20A Schematic diagram of hardware spatially decorrelating and remapping data blocks;

[0050] Fig. 21B It shows that from Fig. 22 A schematic diagram of the encoded data output by the method;

[0051] Fig. 22 is a flow chart representing an entropy coding method;

[0052] Fig.23 A computer system implementing a data compression and / or decompression unit is shown; and

[0053] Fig.24 An integrated circuit manufacturing system for producing an integrated circuit embodying a data compression and / or decompression unit as described herein is shown.

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

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

[0056] Embodiments are now described by way of example only.

[0057] As mentioned above, memory bandwidth is a relatively limited resource within a processing unit (e.g., a CPU or GPU). Similarly, memory space is also a limited resource because increasing it has an impact on both the physical size of the device and power consumption. By using data compression before storing the data in memory, both memory bandwidth and space in memory can be saved.

[0058] There are many data compression schemes, some of which are lossless and others are lossy. In some cases, lossless compression techniques may be preferred because the original data can be perfectly reconstructed from the compressed data. In contrast, where lossy compression techniques are used, the data cannot be perfectly reconstructed from the compressed data, and instead, the decompressed data is only an approximation of the original data. The accuracy of the decompressed (and therefore reconstructed) data will depend on the importance of the data discarded during the compression process. In addition, unlike the case when lossless compression techniques are used, repeatedly compressing and decompressing data using lossy compression techniques will result in a gradual degradation in quality. Lossless compression techniques are commonly used to compress audio and image data, and examples of common lossless compression techniques include run-length encoding (RLE) and Huffman coding.

[0059] The amount of compression that can be achieved using lossless compression techniques (e.g., as described in British Patent No. 2530312) depends on the nature of the data being compressed, with some data being more easily compressed than others. The amount of compression achieved by a compression technique (whether lossless or lossy) can be expressed as a percentage referred to herein as the compression ratio, and is given by the following formula:

[0060]

[0061] It should be understood that there are other ways to define compression ratios; however, the above convention is used throughout this article. This means that a compression ratio of 100% means that no compression is achieved, a compression ratio of 50% means that the data has been compressed to half of its original, uncompressed size, and a compression ratio of 25% means that the data has been compressed to one-quarter of its original, uncompressed size. Lossy compression techniques can generally compress data to a greater extent (i.e., achieve a smaller compression ratio) than lossless compression techniques. Therefore, in some examples, for example, where the degree of compression that can be achieved is considered more important than the quality of the decompressed (i.e., reconstructed) data, a lossy compression technique may be preferred over a lossless compression technique. How to choose between lossless and lossy compression techniques is an implementation choice.

[0062] The variability in the amount of compression that can be achieved (depending on the characteristics of the actual data being compressed) has an impact on both memory bandwidth and memory space, and may mean that the full benefits of the compression achieved are not fully realized in terms of one or both of these aspects, as described below.

[0063] In many use cases, random access to the original data is required. Typically for image data, to achieve this, the image data is divided into independent, non-overlapping rectangular blocks before compression is performed. If the size of each compressed block varies due to the nature of the data in the block (for example, blocks of all the same color may compress much more than blocks containing a lot of detail), so that in some cases the block may not be compressed at all, then in order to maintain the ability to randomly access the compressed data blocks, memory space can be allocated as if the data was not compressed at all. Alternatively, it is necessary to maintain an index in which there is an entry for each block that identifies the location in memory where the compressed data for that block resides. This requires memory space to store the index (which can be relatively large), and the memory access (performing a lookup in the index) can increase the latency of the system. For example, in a system where it is important to be able to randomly access each compressed data block and no index is used, even if an average compression ratio of 50% is achieved (for all data blocks), memory space still needs to be allocated assuming a compression ratio of 100%, because for some blocks, it may not be possible to achieve any compression using lossless compression techniques.

[0064] Furthermore, since the transfer of data to memory occurs in fixed-size bursts (e.g., in bursts of 64 bytes), for any given block, only a discrete set of effective compression ratios are applicable to transferring the data to memory. For example, if a block of data contains 256 bytes and the data transfer occurs in bursts of 64 bytes, the effective compression ratios for the data transfer are 25% (if the block is compressed from 256 bytes to no more than 64 bytes, thus requiring only one burst), 50% (if the block is compressed to 65-128 bytes, thus requiring two bursts), 75% (if the block is compressed to 129-192 bytes, thus requiring three bursts), and 100% (if the block is not compressed at all or is compressed to 193 or more bytes, thus requiring four bursts). This means that if a data block comprising 256 bytes is compressed to any value in the range of 129-192 bytes, three bursts are required for the compressed block, while four bursts are required for the uncompressed block, resulting in an effective compression ratio of 75% for the memory transfer, while the actual data compression achieved can be much lower (e.g., as low as 50.4% if compressed to 129 bytes). Similarly, if compression can only compress the block to 193 bytes, the memory transfer sees no benefit from using data compression because four bursts are still required to transfer the compressed data block to the memory. In other examples, the data block can include a different number of bytes, and the bursts to the memory can include a different number of bytes.

[0065] Described herein are various methods of performing data compression. Some methods as described herein provide a guarantee that a compression threshold is met, which may be defined in terms of a compression ratio (e.g., 50%), a compressed block size (e.g., 128 bytes), or in any other manner. The effect of this guarantee is that the amount of allocated memory space may be reduced while still being able to randomly access compressed data blocks, and also that the memory bandwidth used to transfer compressed data to and from memory may be reduced. In other examples, a compression ratio may be targeted (i.e., the method may be configured to achieve that ratio in most circumstances), but there is no guarantee that it will be met.

[0066] Also described herein are methods for converting 10-bit (e.g., 10:10:10:2) data to 8-bit (e.g., 8:8:8:3) data and methods for mapping from n-bit numbers to m-bit numbers. As described below, the methods for converting 10-bit (e.g., 10:10:10:2) data to 8-bit (e.g., 8:8:8:3 or 8888) data can be used as a preprocessing (or pre-encoding) step for performing the data compression methods described herein, or can be used independently (e.g., used with another data compression method or used only with a lossless compression method, such as the one described below with reference to Fig. 20A -B, 21A-B and 22). By first converting 10-bit (e.g., 10:10:10:2) data using one of the methods described herein, the 10-bit data can then be compressed by a method arranged to operate on 8888 format data. The conversion method may be lossy for three channels (e.g., RGB data) and may be lossless for the fourth channel (e.g., alpha data); however, since this format is typically used for high dynamic range (HDR) data and most pixels (e.g., 75%) will still be in the low dynamic range (LDR), the conversion can be performed with only a small loss of accuracy. The method for mapping from an n-bit number to an m-bit number as described herein can be used in a method for performing data compression as described below, or can be used independently. By using this mapping method, data in other formats can then be compressed by a method arranged to operate on 8888 format data and / or it can be used to reduce internal buffering (e.g., registers, etc.), for example, 6 bits per pixel can be reduced (i.e., 19%), and this can be described, for example, below and in Figure 2C The initial standby compression subunit 204A shown in FIG.

[0067] Figure 1A graphics rendering system 100 is shown that may be implemented in an electronic device such as a mobile device. The graphics rendering system 100 includes a host CPU 102, a GPU 104, and a memory 106 (e.g., graphics memory). The CPU 102 is arranged to communicate with the GPU 104. Data, which may be compressed data, may be transferred between the GPU 104 and the memory 106 in either direction.

[0068] The GPU 104 includes a rendering unit 110, a compression / decompression unit 112, a memory interface 114, and a display interface 116. The system 100 is arranged so that data can be transferred in either direction between: (i) the CPU 102 and the rendering unit 110; (ii) the CPU 102 and the memory interface 114; (iii) the rendering unit 110 and the memory interface 114; (iv) the memory interface 114 and the memory 106; (v) the rendering unit 110 and the compression / decompression unit 112; (vi) the compression / decompression unit 112 and the memory interface 114; and (vii) the memory interface 114 and the display interface. The system 100 is also arranged so that data can be transferred from the compression / decompression unit 112 to the display interface 116. Images rendered by the GPU 104 can be sent from the display interface 116 to the display for display thereon.

[0069] In operation, GPU 104 processes image data. For example, rendering unit 110 may perform scan conversion of graphics primitives such as triangles and lines using known techniques such as depth testing (e.g., for hidden surface removal) and texturing and / or shading. 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 unit 114 (which may include a cache), but for other data, such as data to be stored in a frame buffer, data is preferably transferred from rendering unit 110 to memory interface 114 via compression / decompression unit 112. Compression / decompression unit 112 reduces the amount of data to be transferred to memory 106 via an external memory bus by compressing the data, as described in more detail below.

[0070] The display interface 116 sends the completed image data to the display. The uncompressed image may be accessed directly from the memory interface unit 114. The compressed data may be accessed via the compression / decompression unit 112 and sent to the display 108 as uncompressed data. In an alternative example, the compressed data may be sent directly to the display 108, and the display 108 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.

[0071] In various examples, the compression / decompression unit 112 may implement a compression method (or scheme) that guarantees that a compression threshold (which may be predefined, and therefore fixed, or may be an input variable) is met. As detailed above, the compression threshold may be defined, for example, in terms of a compression ratio (e.g., 50% or 25%), a compressed block size (e.g., 128 bytes), or in any other manner. In order to provide such guarantees regarding the amount of compression provided, and given that the exact nature of the data is not known in advance, a combination of lossless and lossy compression methods is used, and in Figure 2A -C. In most cases, if not all, lossless compression techniques are used (such as that described in UK Patent No. 2530312 or in the referenced patent document below). Fig. 20A -B, 21A-B and 22) to compress the data block, and then perform a test to determine whether the compression threshold is met. If the compression threshold is not met, a lossy compression technique (such as a vector quantization (VQ) technique) is applied to the data block instead, or the following reference is made to Figure 3A The description of 4-11 will provide a method for guaranteed compression based on a compression threshold to achieve the compression threshold.

[0072] exist Figure 2A In the method shown, uncompressed source data (e.g., 256-byte blocks) are input to a primary compression unit 202 (which may also be referred to as a lossless compression unit) and a backup compression unit 204 (which may also be referred to as a lossy or backup compression unit). Thus, the input data blocks are independently compressed in parallel using two different methods (potentially, a lossless method in the primary compression unit 202 and a lossy method in the backup compression unit 204). Fig. 20A21A-B, 21A-B, and 22 describe example methods of lossless compression that may be implemented by the primary compression unit 202. The backup compression unit 204 compresses the input data block in such a manner as to guarantee that the compression threshold is met. The two versions of the compressed data block are then input to a test and selection unit 206. The test and selection unit 206 determines whether the compressed data block generated by the primary compression unit 202 meets the compression threshold (e.g., for a 256-byte input block, whether it is not greater than 128 bytes, and a compression threshold of 50%). If the compressed data block generated by the primary compression unit 202 meets the compression threshold, it is output, otherwise the compressed data block generated by the backup compression unit 204 is output. In all cases, the compressed data block output will meet the compression threshold, and for those blocks that cannot be properly compressed using lossless techniques (in the primary compression unit 202), the overall quality of the compressed data is improved (i.e., the amount of data lost due to the compression process is kept at a lower level while still meeting the compression threshold) by using only lossy compression (in the backup compression unit 204).

[0073] exist Figure 2B In the method shown, uncompressed source data (e.g., 256-byte blocks) is initially input only to the primary compression unit 202, and the input of the source data to the backup compression unit 204 is delayed (e.g., in the delay unit 208). The amount of delay can be arranged to be similar to or slightly longer than the time taken to compress the source data block using a lossless compression technique (in the primary compression unit 202), so as to also include the time taken to evaluate the size of the compressed data block output by the primary compression unit 202 (in the test and decision unit 210). The compressed data block output by the primary compression unit 202 is input to the test and decision unit 210, and if it meets the compression threshold, it is output and no lossy compression is performed. However, if the compressed data block output by the primary compression unit 202 does not meet the compression threshold (i.e., it is still too large), the test and decision unit 210 discards the compressed block and triggers lossy compression of the block by the backup compression unit 204. The compressed data block output by the backup compression unit 204 is then output.

[0074] exist Figure 2C In the method shown, the backup compression unit 204 is divided into two subunits: an initial backup compression subunit 204A and a final backup compression subunit 204B, each of which performs a portion of the lossy compression method. For example, the initial backup compression subunit 204A can compress each byte from 8 bits to 5 bits (for example, using truncation or reference below). Fig. 12A -B) and any further compression required to meet the compression threshold may be performed by the final backup compression subunit 204B. In other examples, the backup compression subunit 204B may perform pre-processing steps (e.g., as described below with reference to Fig.14 In other examples, the lossy compression method may be split between the two alternate compression sub-units 204A, 204B in different ways.

[0075] exist Figure 2C In the method shown, uncompressed source data (e.g., 256-byte blocks) are input to the main compression unit 202 and the initial standby compression subunit 204A. Thus, the input data blocks are compressed independently and in parallel using two different methods (a lossless method in the main compression unit 202 and a first portion of a lossy method in the subunit 204A). The compressed data block output by the main compression unit 202 is input to the test and decision unit 210, and if it meets the compression threshold, it is output, the partially compressed data block output by the initial standby compression subunit 204A is discarded, and no further lossy compression is performed on the data block. However, if the compressed data block output by the main compression unit 202 does not meet the compression threshold (i.e., it is still too large), the test and decision unit 210 discards the compressed block and triggers the completion of the lossy compression performed by the final standby compression subunit 204B on the block output by the initial standby compression subunit 204A. The compressed data block output by the final standby compression subunit 204B is output.

[0076] In some cases, a data block may be compressed beyond the compression threshold. In such cases, the primary compression unit 202 may output a compressed data block that always just meets the compression threshold, or alternatively, in such cases, the size of the output compressed data block may be less than the size required to meet the compression threshold. Similarly, in Figure 2A , 2B The lossy compression techniques used in and 2C (and implemented in alternate compression unit 204 or subunits 204A, 204B) can output compressed data blocks that always just meet the compression threshold, or alternatively, the size of the compressed data blocks can vary while still always meeting the compression threshold. In the case where the compressed data blocks are smaller than the compressed data blocks required to just meet the compression threshold, there may still be memory bandwidth and memory space inefficiencies caused by the fixed burst size and pre-allocation requirements, respectively; however, when the compression threshold is met, there is always an improvement related to memory bandwidth and memory space. In various examples, headers can be used to further reduce the used memory bandwidth of certain blocks (e.g., by including information in the header about how much data to read from or write to memory).

[0077] Depending on the specific implementation, you can use Figure 2A -C for any architecture. Figure 2AThe arrangement shown in provides fixed throughput and fixed latency (meaning that there is no need to buffer the data and / or cause bubbles later in the system), but may increase power consumption (e.g., compared to having just a single compression unit perform lossless or lossy compression). Figure 2B The arrangement shown may have Figure 2A The arrangement shown in Figure 1 consumes less power (on average) because Figure 2B The spare compression unit 204 in the system can be turned off when not needed; however, the latency may vary, so a buffer may be included in the system. Alternatively, an additional delay element 208 may be added between the test and decision unit 210 and the output (in Figure 2B 204) to delay the compressed data block output by the primary compression unit 202 (e.g., the delay amount may be arranged to be comparable to the time taken to compress the source data block using the lossy compression technique in the backup compression unit 204). The additional delay element 208 is included in Figure 2B This has the effect of making the waiting time of the arrangement fixed rather than variable. Figure 2C The arrangement shown in FIG. 1 can also have Figure 2A The arrangement shown in Figure 1 consumes less power (on average) because Figure 2C The final backup compression subunit 204B in can be turned off when not needed; however, in some cases, the initial backup compression subunit 204A discards data that will be useful later, which may reduce the accuracy of the decompressed data (for example, the data is initially compressed from 8 bits to 6 bits, and then, from 6 bits to 4 bits, and the decompression from 4 bits to 8 bits may introduce more errors than the case where the data is directly compressed from 8 bits to 4 bits).

[0078] Reference above Figure 2A -C The method described can be used in combination with any compression threshold; however, in many examples, the compression threshold will be 50% (but this can be expressed in another way, such as 128 bytes for 256-byte data blocks). In examples using a compression threshold other than 50%, the compression threshold can be selected to align with the burst size (e.g., 25%, 50%, or 75% for the above example), when the threshold can be met using lossless compression for most of the data blocks (e.g., >50%) and lossy compression is used only for the remaining blocks. Figure 2A The architecture shown in -C provides the greatest efficiency.

[0079] To identify which compression technique was used (e.g., lossless or lossy), data indicating the type of compression used may be appended (e.g., in a header), or the data may be incorporated into any existing header (or header table) used, or each compressed data block may include, in addition to the compressed data, multiple bits indicating the type of compression used (e.g., as described below with reference to FIGURE 3-11).

[0080] exist Figure 2A -C, there may be additional preprocessing steps ( Figure 2A -C), which is a lossy pre-processing step, and converts the source data into a format suitable for the main compression unit 202 and / or the backup compression unit 204, 204A. The lossy pre-processing step can, for example, change the format of the data from a 10-bit (e.g., RGBA1010102) format to an 8-bit (e.g., RGBA8883 or 8888 format), as described below. Fig.14 and 16 Two example methods for performing this preprocessing are described. In various examples, Fig.16 The method may be used as a pre-processing step of the main compression unit 202, Fig.14 The method may be used as a pre-processing step for the backup compression unit 204, or vice versa, or the same method may be used for both the primary compression unit and the backup compression unit.

[0081] exist Figure 2A The use of different data formats and / or pre-processing steps in the architecture of the primary compression unit 202 and / or the backup compression units 204, 204A, 204B may also require modifications to the compression method used (e.g., in the primary compression unit 202 and / or the backup compression units 204, 204A, 204B), and some examples of these situations are also described below. By combining a lossy pre-processing step with a lossless compression (implemented in the primary compression unit 202), it will be appreciated that the compressed data output by the primary compression unit 202 is no longer lossless.

[0082] Reference Figure 3-11 describes a lossy compression technique that ensures that a predefined compression threshold is met. This technique can be performed by Figure 1 The compression / decompression unit 112 shown in FIG. 1 and / or by Figure 2A and 2BThe alternate compression unit 204 shown is implemented. As described above, the use of data compression reduces the requirements for memory storage space and memory bandwidth, and ensuring that the compression threshold (which can be defined in any suitable manner as described above) is met can ensure that the benefits of both memory storage space and memory bandwidth are achieved. In the example described below, the compression threshold is 50% (or 128 bytes in the case where the size of each uncompressed data block is 256 bytes); however, in other examples, the method can be used for different compression thresholds (e.g., 75% or 25%), and as described above, the compression threshold can be selected to correspond to an integer number of burst pulses used for memory transfers.

[0083] Figure 3A The lossy compression method shown takes as input source data in RGBA8888 or RGBX8888 format or in a corresponding format with channels in a different order (e.g., ARGB or other corresponding formats, e.g., including four channels, each with an 8-bit value). In various examples, the source data may include channels with data values ​​less than 8 bits, and examples of corresponding changes to the method are described below (e.g., with reference to Fig.15A -D). In examples where the source data is not in a suitable format (e.g., where each RGB channel comprises more than 8 bits), a preprocessing step (e.g., as described below in Fig.14 or Fig.16 As described) to convert the source data into an appropriate format. Alternatively, Figure 3A The method may be used where a channel includes more than 8 bits of data (e.g., 10:10:10:2 data); however, by using the following reference to including the HDR flag Fig.14 With the preprocessing techniques described, there is an extra bit that can be shared between RGB values. The following examples involve compressing and decompressing image data (e.g., data in RGBA format), but it should be understood that the same principles can be applied to compress and decompress other types of data in other formats.

[0084] Input to Figure 3AThe source data of the method includes data blocks. For image data, each data block relates to a tile (or block) of pixels (e.g., a tile comprising 8x8 pixels or 16x4 pixels), and each block is subdivided into a plurality of sub-blocks (box 302). In various examples, each data block is subdivided (in box 302) into four sub-blocks. If the data block is subdivided (in box 302) into a smaller number of larger blocks, the amount of compression that can be achieved can be greater, but random access is more difficult, and unless many pixels in the block are accessed, bandwidth usage increases as the "data per pixel accessed" increases. Similarly, with a larger number of smaller blocks, random access becomes easier (and the data per pixel accessed can be reduced); however, the amount of data compression that can be achieved can be reduced. For example, if the data block relates to 8x8 pixel tiles or 16x4 pixel tiles, the block can be subdivided into four sub-blocks 400, each of which corresponds to a 4x4 pixel arrangement, and for 8x8 tiles, such as Figure 4A As shown, for a 16x4 tile, Figure 4B As shown. The sub-blocks may be denoted as sub-blocks 0-3. After performing this subdivision (in block 302), each sub-block is considered independently, and based on the results of an analysis of the alpha values ​​of the pixels within the sub-block, a lossy compression mode is selected for each sub-block (block 304). Depending on the results of the analysis, the selected mode may be a mode that uses a constant value for alpha (as applied in block 306, and referred to as a constant alpha mode) or a mode that uses a variable value for alpha in the sub-block (as applied in block 308, and referred to as a variable alpha mode). There may be only two modes available, or alternatively, there may be one or more additional modes (e.g., as applied in block 310). The compressed data for each sub-block in the source data block (output by one of blocks 306-310) is then packed together to form a corresponding compressed data block (block 312).

[0085] Figure 4C A compressed data block 402 is shown, which includes compressed data 404 for each sub-block and indicates that the compressed data 404 is being used. Figure 3A The data 404 for each sub-block 400 is divided into two fields: a 2-bit block mode 408 and a 252-bit block data 410. The block mode bits 408 indicate whether variable alpha mode (block 308), constant alpha mode (block 306), or other mode (block 310) is used. For example, the field values ​​may be as follows:

[0086] <![CDATA[ Field Value ]]> <![CDATA[ explain ]]> 0b00 Constant α 0b01 Variable alpha 0b1- Other modes (when in use)

[0087] Figure 5A The details are shown in Figure 3A304 . In this example, the alpha value of each pixel within the sub-block is analyzed and two parameters are calculated: minalpha and maxalpha, which are the minimum and maximum values ​​of alpha for all pixels in the sub-block (block 502). These can be determined in any manner, including, for example, using a loop (as in the pseudo-code example below, or a functional equivalent thereof) or using a test tree, with a first step determining the maximum and minimum alpha values ​​for a pair of pixels, and then a second step determining the maximum and minimum alpha values ​​for the output pairs of the first step, etc. These two parameters (minalpha and maxalpha) are then used in a subsequent decision process (blocks 504-508), and although the decision process is shown as being applied in a particular order, in other examples, the same tests may be applied in a different order. (For example, assuming alphadifftol<254, blocks 506 and 508 may be swapped). In addition, it should be understood that the test in block 504 may alternatively be maxalpha>(minalpha+alphadifftol).

[0088] The first decision operation (block 504) evaluates the range of alpha values ​​across the sub-block and determines whether the range is greater than the error that would be introduced by using the (best case) variable alpha mode (in block 308). The magnitude of these errors is Figure 5A The value of alphadifftol may be predetermined. The value of alphadifftol may be determined during training by comparing the quality loss caused by different approaches in variable alpha mode (i.e., 4-color encoding with 4-bit alpha or 3-color encoding with 5-bit alpha and with two pixels sharing the same color) (hence the phrase "best case" above). Alternatively, the value of alphadifftol may be determined by evaluating different candidate values ​​against a large set of test images (also during training) to find the candidate value that provides the best results using visual comparison or an image difference metric. The value of alphadifftol may be fixed or may be programmable.

[0089] In response to determining that the range is greater than the error that would be introduced by using the (best case) variable alpha mode ("yes" in block 504), a variable alpha compression mode is applied to this sub-block (block 308). However, in response to determining that the range is not greater than the error that would be introduced by using the (best case) variable alpha mode ("no" in block 504), a constant alpha compression mode (block 306) is applied to the sub-block, and two further decision operations (blocks 506, 508) are used to determine the alpha value for the entire sub-block. If the value of maxalpha is the maximum possible value for alpha (e.g., 0xFF, "yes" in block 506), the alpha value used in the constant alpha mode (constalphaval) is set to the maximum possible value (block 510). This ensures that if there are any fully opaque pixels, they remain fully opaque after the data is compressed and then decompressed. If the value of minalpha is zero (e.g., 0x00, "yes" in block 508), the alpha value used in constant alpha mode (constalphaval) is set to zero (block 512). This ensures that if there are any fully transparent pixels, they remain fully transparent after the data is compressed and then decompressed. If neither of these conditions is true ("no" in blocks 506 and 508), an average value of alpha is calculated for the pixels in the sub-block (block 514) and used in constant alpha mode.

[0090] For example, the following pseudo code (or its functional equivalent) may be used to implement the analysis shown in FIG. 5 , where P.alp is the alpha value for the pixel P under consideration:

[0091] const AlphaDiffTol = 4;

[0092] U8MinAlpha:=0xFF;

[0093] U8MaxAlpha:=0x00;

[0094] U12AlphaSum:=0;

[0095] FOREACH Pixel,P,in the 4x4block

[0096] MinAlpha:=MIN(P.alp,MinAlpha);

[0097] MaxAlpha:=MAX(P.alp,MaxAlpha);

[0098] AlphaSum+ = P.alp;

[0099] ENDFOR

[0100] IF((MaxAlpha–MinAlpha)>AlphaDiffTol)THEN

[0101] Mode:=VariableAlphaMode;

[0102] ELSE IF (MaxAlpha == 0xFF)

[0103] Mode:=ConstAlphaMode;

[0104] ConstAlphaVal:=0xFF;

[0105] ELSE IF (MinAlpha == 0x00)

[0106] Mode:=ConstAlphaMode;

[0107] constAlphaVal:=0x00;

[0108] ELSE

[0109] Mode:=ConstAlphaMode;

[0110] ConstAlphaVal:=(AlphaSum+8)>>4;

[0111] ENDIF

[0112] Figure 5B The analysis phase is shown in Figure 3A 304 in block 520). In this example, the parameter constalphaval is initially set to the alpha value of the pixel at the predefined position within the sub-block (block 520). For example, constalphaval can be set to the alpha value of the pixel at the upper left corner of the sub-block (i.e., the first pixel in the sub-block). All alpha values ​​of other pixels in the sub-block are then compared to constalphaval (in blocks 522-526). In the case where all alpha values ​​are very similar to constalphaval (e.g., within a range of ±5, "yes" in block 522), the constant alpha mode is used ( Figure 3A 306 in block 522), but if they vary more than this (“No” in block 522), then the variable alpha mode is used ( Figure 3A Then, with Figure 5AIn a similar manner to the method of , for constant alpha mode, the parameter constalphaval is set to zero (in box 512) or a maximum value (in box 510), where the pixels are almost completely transparent (constalphaval<5, "yes" in box 524) or almost completely opaque (constalphaval>250, "yes" in box 526), ​​respectively. It should be understood that Figure 5B The specific values ​​used as part of the analysis (e.g., in boxes 522-526) are provided as examples only, and in other examples, these values ​​may be slightly different.

[0113] and Figure 5A Compared with the method Figure 5B The method does not require the determination of minalpha and maxalpha, which reduces the computational effort required to perform the analysis. However, Figure 5B The approach may produce some visible artifacts (such as aliasing), especially when objects move slowly on the screen, and the "constant alpha" tile is less likely to be detected due to the use of a predefined position as the center of the alpha value.

[0114] In analyzing the alpha values ​​within the sub-block (in block 304, for example, Figure 5A In the case where it is determined that the constant alpha mode is to be used (in block 306) and the parameter constalphaval is also set (in one of blocks 510-514 and 520), the compression of the sub-block is as follows: Fig. 6A or Fig. 7A Proceed as shown. Fig. 6A shows the use of constant α mode ( Figure 3A Flowchart of a first example method for compressing a sub-block. For each pixel, compress each RGB value from 8 bits to 5 bits (block 602, e.g., as described below with reference to Fig. 12A -B, or using an alternative truncation method), and then pack the compressed value into a data block together with the value of constalphaval (block 604). Thus, in this example, the data of the 4x4 sub-block is compressed from 512 bits (RGBA8888 format (16*32=512 bits)) to 248 bits (8+16*(5+5+5)=248 bits).

[0115] Figure 6B-6D Two different ways of packaging compressed values ​​into data blocks are shown, but it is understood that compressed values ​​may alternatively be packaged into data blocks in other ways. Figure 6BAs shown, data block 606 includes three 80-bit fields 608-610, each of which includes data from one of the three channels (e.g., R, G, or B), and an 8-bit constalphaval (e.g., as used in Figure 5A The remaining 4 bits may not be used or reserved for future use. In each 80-bit field 608-610, each pixel in the sub-block has a 5-bit value.

[0116] In the second example, if Figure 6C-6D As shown, the layout of the data is similar to the second method of implementing variable alpha mode (as shown in the following reference Fig. 9 block 308), since this will be done in two ways (i.e., Fig. 6A and Fig. 9 When used together with the method of , less complex hardware (and therefore smaller hardware with lower power consumption). Figure 6C As shown, each sub-block 400 (e.g., each 4x4 pixel sub-block) is subdivided into four mini-blocks 650-653 (e.g., four 2x2 pixel mini-blocks). Each mini-block has a corresponding 60-bit data field 660-663 that contains the RGB data of the pixels in the mini-block. Figure 6C In the , mini-blocks and their corresponding data fields have been labeled Q, S, U, and W. The 8-bit constalphaval (e.g., Figure 5A or 5B) are distributed in four 3-bit fields 670-673. Within each mini-block data field 660-663, the RGB data is as follows Fig.6D If each mini-block consists of four pixels labeled AD, they are each represented by three 5-bit values, one for each of the R, G, and B channels (e.g., 5-bit value R A , G A and B A Represents pixel A, 5-bit value R B , G B and B B represents pixel B, and so on).

[0117] Fig. 7A shows the use of constant α mode ( Figure 3A 306) to compress the sub-blocks, the method being Fig. 6A A variation of the method shown in . Fig. 7A As shown, the pixels in sub-block 400 are divided into two non-overlapping subsets, and then the pixels in each subset are compressed by different amounts. Fig. 7AIn the specific example shown, this example can be used when constalphaval can be stored in less than 8 bits (e.g., constant α < 5 or > 250) to match Fig. 6A The pixels in the first subset are compressed in the same manner, i.e., by converting each R, G, B value from RGB888 format to RGB555 format (block 602), while the pixels in the second subset are compressed in a different manner (block 702), i.e., by converting the RGB data from RGB888 format (i.e., three 8-bit values, one for each channel) to RGB565 format (i.e., 5-bit values ​​for the R and B channels, and 6-bit values ​​for the G channel). The compression may be as follows with reference to Fig. 12A -B is performed as described above (in blocks 602 and 702), or an alternative method may be used (e.g., truncating the value by removing one or more LSBs). In other examples, the two subsets of pixels may be compressed in different ways (e.g., the pixels of the second subset may be compressed by converting the RGB data from RGB888 format to RGB554).

[0118] Figure 7B An example of how to divide the pixels in a sub-block into two subsets is shown. Figure 7B In the example shown, the 4 pixels marked AD form a first subset, and the 12 shaded pixels form a second subset. In other examples, the division between the two subsets may be different (e.g., there may be more or less than four pixels in the first subset, with the remaining pixels forming the second subset) and / or the positions of the pixels in the first subset may be different.

[0119] In the example where constalphaval is an 8-bit value (e.g., in the case where constant alpha is not < 5 or > 250), you can modify Fig. 7A The method makes the pixels in the second subset Fig. 6A The pixels in the first subset are compressed in the same manner as in the previous example, i.e., by converting each of the R, G, B values ​​from RGB888 format to RGB555 format (block 602), while the pixels in the first subset are compressed in a different manner (block 702), i.e., by converting the RGB data in RGB888 format (i.e., three 8-bit values, one for each channel) to RGB565 format (i.e., 5-bit values ​​for the R and B channels and 6-bit values ​​for the G channel). As previously described, the compression may be performed as follows with reference to Fig. 12A -B is performed as described above (in blocks 602 and 702), or an alternative approach may be used (e.g., truncating the value by removing one or more LSBs).

[0120] In the analysis of the alpha values ​​within the sub-block (in block 304, for example, Figure 5AIn the event that a variable alpha mode is determined to be used (block 308) as shown in FIG. 8A or FIG. 9, compression of the sub-blocks continues as shown in FIG. 8A or FIG. 9. Fig. 8A shows the use of variable alpha mode ( Figure 3A Flowchart of a first example method of compressing a sub-block by using block 308 of FIG. Fig. 8A As shown, data for each pixel in the sub-block is compressed by converting the RGBA8888 format (i.e., four 8-bit values, one value for each channel including the alpha channel) to the RGBA5555 format (i.e., four 5-bit values, one value for each channel including the alpha channel) (block 802, e.g., as described below with reference to Fig. 12A -B). Then, the pixels in sub-block 400 are divided into two non-overlapping subsets (e.g., as described above with reference to Figure 7B ), and then for pixels in the first subset (e.g., Figure 7B The pixels AD in are further compressed (blocks 804-806), which can be referred to as Figure 8B To further compress the pixels in the first subset, each of these pixels is compared to its neighboring pixels to identify which neighboring pixel is most similar (block 806). Similarity can be evaluated using a color difference parameter, where the most similar pixel has the smallest color difference with a particular pixel, and the color difference between one pixel and a neighboring pixel (i.e., between a pair of pixels) can be calculated as follows:

[0121] |Red difference|+|Green difference|+|Blue difference|+|Alphadifference| (1)

[0122] After identifying the most similar neighboring pixels for each pixel in the first subset, a lookup table is used to select an index for each pixel in the first subset, such as:

[0123] <![CDATA[ index ]]> <![CDATA[ Most similar neighboring pixels ]]> 000 R0 001 R1 010 R2 011 R3 100 R4

[0124] The reference definition for adjacent pixels R0-R4 is as follows: Figure 8B However, it should be understood that these neighboring pixels may be defined differently when the positions of the pixels of the first subset are different.

[0125] In various examples, there may be additional indices used when there is a gradient around the pixels in the first subset. In such an example, the pixel data of one or more additional nominal neighboring pixels are calculated, for example, by adding a single additional nominal neighboring pixel R5, where the pixel data of R5 is calculated using the following formula:

[0126] R5=(R0+R1) / 2

[0127] In other examples, one or more other nominal neighboring pixels may also be considered, for example, R6 and / or R7, where the pixel data of R6 and R7 are calculated using the following formula:

[0128] R6=(R0+R4) / 2

[0129] R7=(R1+R3) / 2

[0130] In case additional nominal neighboring pixels are used, the lookup table includes corresponding additional entries for identifying the index, for example:

[0131] <![CDATA[ index ]]> <![CDATA[ Most similar neighboring pixels ]]> 000 R0 001 R1 010 R2 011 R3 100 R4 101 R5 110 R6 111 R7

[0132] In various examples, there may be additional special case indices that indicate that none of the neighboring pixels (including any nominal neighboring pixels used) are sufficiently similar to a particular pixel. For example, this may be determined based on a threshold, and where the closest color difference exceeds the threshold, index 000 may be used. In one example, for a 5-bit value, the threshold may be 31. In addition to using index 000, the pixel pointed to by index 000 is changed to the average value between the current pixel and the pointed to pixel. Alternatively, in Fig. 8A In a variation of this, if the conversion of the pixel data from RGBA8888 to RGBA5555 is not performed (in block 802) until just before the data values ​​are packed (in block 808) so that the comparison (in block 804) is performed on the 8-bit values, the threshold value will be different (e.g., 255 for an 8-bit value).

[0133] Fig. 9 shows the use of variable alpha mode ( Figure 3A Flowchart of a second example method for compressing sub-blocks. Fig. 9 As shown, a sub-block 400 (eg, each 4x4 pixel sub-block) is subdivided (block 902) into four mini-blocks 650-653 (eg, 2x2 pixel mini-blocks), as shown in FIG. Figure 6C Each mini-block is then compressed individually, with each mini-block having a corresponding data field 660-663 containing the RGB data for the pixels in the mini-block. The corresponding four 3-bit fields 670-673 do not contain constalphaval, as previously described. Figure 6C , but when variable alpha mode is used, these 3-bit fields identify the encoding (or palette) mode used for each mini-block in the sub-block, as described below.

[0134] Based on the color difference calculated for each pixel pair in the mini-block, a coding mode is determined for each mini-block (block 904). The color difference can be calculated using equation (1) above, and this can be implemented by the functional equivalent of the pseudo-code provided below, where the color difference is truncated to 6 bits (i.e., a maximum value of 63). In this code, the notation is as follows: IntermediateResult[5,0] refers to the 6 LSBs of the IntermediateResult 10-bit value, and red / grn / blu / alp refers to red / green / blue / alpha, respectively).

[0135] U6DiffMetric(PIXEL Pix1,PIXEL Pix2)

[0136] {

[0137] U6Result;

[0138] U10IntermediateResult;

[0139] U8R1:=Pix1.red;

[0140] U8R2:=Pix2.red;

[0141] U8G1:=Pix1.grn;

[0142] U8G2:=Pix2.grn;

[0143] U8B1:=pix1.blu;

[0144] U8B2:=Pix2.blu;

[0145] U8A1:=Pix1.alp;

[0146] U8A2:=Pix2.alp;

[0147] IntermediateResult:=SAD4x5(R1,R2,G1,G2,B1,B2,A1,A2);

[0148] IF((IntermediateResult>63)THEN

[0149] Result:=63;

[0150] ELSE

[0151] Result:=IntermediateResult[5..0];

[0152] ENDIF

[0153] RETURN Result;

[0154] }

[0155] The pseudocode above includes a sum of absolute differences (SAD) function, and this can be implemented in any manner, for example (e.g., by a logic synthesis tool, or as described in Figure 2 of "Efficient Sum of Absolute Difference Computation on FPGAs" by Kumm et al.).

[0156] After the color differences are calculated (in block 904), the minimum color difference of any pair of pixels in the mini-block is used to determine the mini-block encoding mode to be used (block 906). Depending on whether the minimum color difference (between any pair of pixels in the mini-block) exceeds a threshold (e.g., which can be set to a value in the range 0-50, such as 40), two different types of mini-block encoding modes are used. If the minimum color difference does not exceed the threshold ("yes" in block 906), one of a plurality of encoding patterns is used (as selected in block 908), and three per-mini-block palette colors are stored (blocks 910-914). However, if the minimum color difference does exceed the threshold ("no" in block 906), a four-color mode is used (block 916). These different mini-block modes are described in detail below. The encoding patterns rely on the assumption that in most mini-blocks, there are no more than three different colors, and in this case, the mini-block can be represented by three palette colors and the assignment of pixels to palette entries. A four-color mode exists to handle exceptions.

[0157] As described above, the value of the threshold can be in the range of 0-50. In various examples, it can be a fixed value set at design time. Alternatively, it can be a variable stored in a global register and set each time the execution Fig. 9 method. This enables the threshold to be changed dynamically or at least periodically. In various examples, the value of the threshold can be set based on the results from the training phase. The training phase can use an image quality metric, such as a peak signal-to-noise ratio (PSNR) or a structural similarity metric (SSIM) to evaluate a set of images compressed using each of the three-color method (boxes 908-912) or the four-color method (box 916), and then the threshold can be selected so that the highest image quality metric is obtained overall.

[0158] It can be noted that in Fig. 9 The threshold used in the method can have the same Fig. 8AThe two thresholds are used for different purposes because they target different situations and remove different kinds of artifacts. Fig. 8A In the method of , a threshold is used to identify when one of the pixels is an "isolated color" because it cannot be well represented by one of its neighboring pixels. Fig. 9 The thresholds in the method are used to identify when the four colors are too different from each other.

[0159] like Fig. 9 As shown, if the minimum color difference is less than or equal to the threshold ("yes" in block 906), so that the coding pattern can be used, then based on the pixel pair with the minimum color difference (in the mini-block), from Fig. 10A A particular pattern is selected from a set of six allocation patterns shown (block 908). Fig. 10A In each of the patterns in , the two pixels shown in shading share a palette entry obtained by averaging the two source pixel colors. Therefore, determining the three palette colors P0, P1, P2 (block 910) for the selected pattern (from block 908) includes performing this averaging operation and identifying the pixel data for the other two remaining pixels in the mini-block. Example pseudo code for implementing this selection and calculation of the three palette colors is provided below, but reference is made to Fig. 10A , if the minimum color difference is for pixel pair AB (denoted as DiffAB in pseudocode), then the selected mode is the one called "Top" and the three palette colors are the average of A and B, and then the average of pixels C and D. Similarly, if the minimum color difference is for pixel pair CD (denoted as DiffCD in pseudocode), then the selected mode is the one called "Bottom" and the three palette colors are the average of C and D, and then the average of pixels A and B. The palette colors in the other modes (i.e., "Left", "Right", "Diag1", and "Diag2" modes) are selected from Fig. 10A It is obvious.

[0160] The following table shows the corresponding palette color for each pixel AD in the mini-block for each coding mode, and the coded value stored in the 3-bit fields 670-673 of the mini-block (eg, Figure 6C ) is shown in FIG. Pixels represented by the same palette color are shown in bold and italics. In this example, the mapping is arranged so that each pixel (e.g., pixel A, B, C, or D) only accesses one of two possible palette colors, and this results in a simpler hardware implementation than if all four pixels could access any of the three palette colors.

[0161]

[0162]

[0163] Implementing this table (and Fig. 9 A portion of example pseudo code for blocks 908-910 of FIG. 1 is as follows:

[0164] ELSIF(MinDiff == DiffAB)

[0165] MODE:=TOP;

[0166] P0full:=PixelC;

[0167] P2full:=PixelD;

[0168] P1full:=Average(PixelA,PixelB);

[0169] ELSIF(MinDiff == DiffAC)

[0170] MODE:=LEFT;

[0171] P0full:=Average(PixelA,PixelC);

[0172] P1full:=PixelB;

[0173] P2full:=PixelD;

[0174] ELSIF…

[0175] The Average function in the pseudocode above can be implemented as follows (or its functional equivalent):

[0176] PIXEL Average(PIXEL Pix1,PIXEL Pix2)

[0177] {

[0178] PIXEL Result;

[0179] Result.red:=(Pix1.red+Pix2.red+1)>>1;

[0180] Result.grn:=(Pix1.grn+Pix2.grn+1)>>1;

[0181] Result.blu:=(Pix1.blu+Pix2.blu+1)>>1;

[0182] Result.alp:=(Pix1.alp+Pix2.alp+1)>>1;

[0183] Return Result;

[0184] }

[0185] After determining the three palette colors P0, P1, P2 in RGBA8888 format, these values ​​are converted to RGBA5555 format (block 912, for example, as described below with reference to Fig. 12A -B). Although the operations of generating palette colors (in block 910) and compression by converting formats (in block 912) are shown and described separately, it should be understood that these two operations can be combined into a single step, which can result in less complex hardware.

[0186] like Fig. 9 As shown, if the minimum color difference is not less than or equal to the threshold ("No" in box 906, i.e., exceeds the threshold), the Fig. 10A Instead of using the coding pattern shown in , a four-color mode is used. In this mode, the number of bits used to represent each channel is reduced (in block 916), and Fig. 9 In the example shown in FIG. 1 , for each of the four pixels in the mini-block, the pixel data is converted from the RGBA8888 format to the RGBA4434 format (block 916, e.g., as described below with reference to FIG. 1 ). Fig. 12A -B). The coded value used to indicate that the mode is being used is one of the values ​​not used for the coded pattern (as detailed in the table above), and in various examples, the coded value 111 may be used. This coded value is stored in the 3-bit fields 670-673 of the mini-block (as detailed in the table above). Figure 6C shown).

[0187] Although the four-color mode is shown as using the RGBA4434 format, alternative compression formats (e.g., RGBA4443) may be used instead. The RGBA4434 format may be used because, although the human eye is sensitive to blue, the human visual system does not perceive the same color resolution as red or green. Additionally, when the four-color mode is used (e.g., in block 916 and Fig.11 602 in FIG. 4 ), a dithering pattern may additionally be applied.

[0188] After the compressed data for the mini-block is generated using any of the coding patterns or four-color modes, the compressed data for the mini-block is packed into the 60-bit data fields 660-663 of the mini-block and the corresponding encoded values ​​are inserted into the associated fields 670-673 (block 914). The manner in which the data is packed varies depending on the mode used, which is described in detail in the following sections. Fig. 10B and 10C Shown in. Fig. 10B The packing of pixel data of mini-blocks compressed using a coding pattern is shown. Fig. 10CThe packing of pixel data for mini-blocks using four-color mode compression is shown.

[0189] As described above, for a mini-block that has been compressed using a coding pattern, the data to be included in the data field includes three palette colors in RGBA5555 format, and these data can be packed into the data field as follows: Fig. 10B As shown, the RGB data can be separated from the alpha channel data to more closely match the packing arrangement that can be used in constant alpha mode (such as Fig.6D For a mini-block that has been compressed using the four-color mode, the data to be included in the data field includes four RGBA4434 values, and these data can be packed into the data field, such as Fig. 10C Again, the arrangement shown is chosen to more closely match the packing arrangement that can be used in constant alpha mode. The arrangement for packing the data for each pixel is also Fig. 10C As shown in FIG. 1 , by packing the data in this way, the four α bits are separated and placed between the RGB data, and the R, G, and B channel data correspond to Fig.6D The positions of the four, four, and three MSBs of the RGB data for the constant alpha mode shown in . The alpha channel for a given pixel is distributed over the unused portion, matching the LSB to MSB order.

[0190] After forming the data fields of the mini-block (in block 914), these data fields are then packed into data fields in the sub-block (block 918, e.g., as Figure 6C shown).

[0191] Although the coding patterns are described above for a variable alpha mode, in various examples, they may also be used to provide a higher precision constant alpha mode, where the constant alpha value is 255 (or other predefined value), such as Fig.11 As shown, the constant α mode described above (e.g., Fig. 6A or as shown in 7A) for other constant α values. Fig.11 shows the use of constant α mode ( Figure 3A 306) to compress the sub-blocks, the method being Fig. 6A and 9 In this example method, a sub-block 400 (e.g., each 4x4 pixel sub-block) is subdivided (block 902) into four mini-blocks 650-653 (e.g., 2x2 pixel mini-blocks), such as Figure 6Cas shown. Each mini-block is then compressed individually, each mini-block having a corresponding data field 660-663 containing the RGB data for the pixels in the mini-block. The corresponding four 3-bit fields 670-673 identify the coding mode used for each mini-block in the sub-block. In this example, constalphaval is not included because it is a known constant value, e.g., 255, and a dedicated block coding mode (e.g., one of the reserved 0b1 modes as described above) may be used to indicate this. In further examples, the coding pattern may also be used additionally or alternatively to provide a higher precision constant alpha mode in which a constant alpha value is stored and is not assumed to have a known constant value (e.g., 255). In such an example, constalphaval may be stored with the pixel data, and in order to have room to store constalphaval, the encoding pattern may be modified. Fig.11 The method converts the three palette colors from RGB888 to RGB676 (in block 1112, instead of RGB776), and the four-color mode converts each color from RGB888 to RGB554 (in block 602, instead of RGB555).

[0192] Then, based on the color difference calculated for each pixel pair in the mini-block, an encoding mode is determined for each mini-block (block 904).The color difference may be calculated using any of the methods described above, but omitting the alpha channel data.

[0193] After the color differences are calculated (in block 904), the minimum color difference of any pair of pixels in the mini-block is used to determine the mini-block encoding mode to use (block 906). Depending on whether the minimum color difference (between any pair of pixels in the mini-block) exceeds a threshold (e.g., which can be set to a value in the range 0-50, such as 40), two different types of mini-block encoding modes are used. If the minimum color difference does not exceed the threshold ("yes" in block 906), one of a plurality of encoding patterns is used (as selected in block 908), and three per-mini-block palette colors are stored (blocks 910-914). However, if the minimum color difference does exceed the threshold ("no" in block 906), an early compression method that converts each RGB value from 8 bits to 5 bits is used (in Fig. 6A 602). As previously described, the coding pattern relies on the assumption that in most mini-blocks there are no more than three different colors, and in this case the mini-block can be represented by three palette colors and the assignment of pixels to palette entries. The previous method (block 602) is used to handle exceptions to this. In the case where a coding pattern is used, higher precision can be used (e.g., more than 5 bits per color channel) because there are only three palette colors instead of four pixels.

[0194] Then, refer to the above Fig. 9 The selection of the coding pattern is performed as described above, except that there is no alpha data to be considered (blocks 908-910). After the three palette colors P0, P1, P2 in RGB888 format are determined, these values ​​are converted to a format with a higher resolution than RGB555, such as RGB776 or RGB666 format (block 1112, for example by truncation or as described below). Fig. 12A -B).

[0195] After the compressed data for the mini-block is generated, the compressed data for the mini-block is packed into the 60-bit data fields 660-663 of the mini-block using one of the coding patterns or the four-color pattern (although in some examples, this four-color pattern may not be used when α is a constant value of 255), and the corresponding encoded values ​​are inserted into the associated fields 670-673 (box 1114). As described above, in various examples of constant alpha patterns using coding patterns to provide higher precision, constalphaval may also be packed into the 60-bit data fields 660-663. After the data fields of the mini-block are formed (in box 1114), these data fields are then packed into the data fields in the sub-block (box 1118, for example, as Figure 6C shown). Fig.11 The method improves the RGB precision (eg, RGB776 or RGB676 instead of RGB555) and thus improves the image quality.

[0196] In the above description, there are six different palette allocation (or encoding) modes, such as Fig. 10A In various examples, there may be one or more additional modes, such as Fig. 10D In such an additional mode, there are only two palette colors (such as Fig. 10D ), each of the two palette colors is the average of two pixels that share the same palette color. In the first example 1001, pixels A and C are averaged to generate a first palette color, which is then used to replace the data for pixels A and C, and similarly operated on for pixels B and D to generate a second palette color (which is then used to replace the data for those pixels). In the second example 1002, pixels A and B are averaged to generate a first palette color, and pixels C and D are averaged to generate a second palette color. Since only two palette colors are stored (compared to three palette colors in the previous encoding mode), the palette colors can be stored with higher precision (e.g., for constant alpha, RGBA8888, for variable alpha, RGBA7878).

[0197] The first of the two palette color modes 1001 (such as Fig. 10D) can be used, for example, when the color difference between pixels A and C (DiffAC in the notation used above) and the color difference between pixels B and D (DiffBD) are both less than a predefined threshold. Similarly, the second of the two palette color modes 1002 can be used, for example, when the color difference between pixels A and B (DiffAB in the notation used above) and the color difference between pixels C and D (DiffCD) are both less than a predefined threshold. In addition, although Fig. 10D Only two two-palette color modes are shown, however, it should be understood that in various examples, there may be a third two-palette color mode where one palette color is the average of pixels A and D and the other palette color is the average of pixels B and C.

[0198] When using the two-palette color model, you can Fig. 9 An additional test for a predefined threshold (which may be different from the threshold used in block 906) is inserted between blocks 904 and 906 in block 907. If the test determines that the two-palette color mode can be used (as described above), the pixel data is averaged to form two palette colors, which can then be converted to RGB7878 format (or they can be left as RGB888 for the constant alpha case), and the pixel data is then packed into the data field (block 914). If the test determines that the two-palette color mode cannot be used, the method proceeds to block 906.

[0199] As detailed above, there are many operations in data compression that involve converting an n-bit number N to an m-bit number M, where n>m. The ideal mapping from n bits to m bits is given by:

[0200]

[0201] For example, this can be implemented using a large lookup table (LUT) comprising N entries. Alternatively, since the result is "symmetric" around half, because:

[0202]

[0203] in The size of the LUT can be halved if the complement of the number of bits X is represented. In such an example, half of the LUT can be retained (e.g., the lower half), and the other half of the table (e.g., the upper half) can be derived by inverting the N-1 LSBs at the input, and similarly by inverting the M-1 LSBs at the output (e.g., by XORing the X-1 LSBs with the MSB—the MSBs at the input and output are the same).

[0204] Fig. 12Ais a flowchart of an alternative method of performing this conversion. Fig. 12A The method can provide a hardware implementation that is both accurate and efficient (e.g., in hardware, i.e., in terms of size, etc.), such as Fig. 12B Although it still uses a LUT, the LUT is significantly smaller than the above LUT (but requires an additional addition element). Although this article describes this method in the context of data compression, the reference in this article is Fig. 12A The methods described may also be used in other situations and are independent of any other methods as described herein.

[0205] like Fig. 12A As shown, the method includes receiving an input n-bit number N and truncating the number from n bits to m bits (block 1202), and this can be Fig. 12B 1202 and the truncation hardware unit 1222 in the truncation hardware unit 1222. An adjustment value is then determined based on the input n-bit number N (block 1204), and as described below, this can be implemented using a plurality of AND and OR gates in the lookup logic unit 1224. These AND and OR logic gates (or alternatively functionally equivalent alternative logic arrangements) compare a plurality of predetermined subsets of the bits of the input n-bit number with predetermined values ​​in the fixed function circuit and based on the results of the comparison, determine an adjustment value, which is then added to the truncation value (from block 1202 and the truncation hardware unit 1222) in the increment / decrement unit 1226 (block 1206). The value of the adjustment value is zero, one, or negative one.

[0206] The operation of the lookup logic unit 1224 to determine the adjustment value (in block 1204) may be described with reference to a specific example where n=8 and m=5 and the following VHDL (or its functional equivalent) where "0-0-111" is an example of a predefined bit sequence and the sequence is compared to the bits in the input n-bit number and the adjustment value "01" associated therewith:

[0207] function CorrectionsFor8to5(i:std_logic_vector(7downto 0))

[0208] return std_logic_vector is

[0209] variable results:std_logic_vector(1downto 0);

[0210] begin

[0211] results:=(others=>'0');

[0212] if std_match(i,"00---11-")then results:="01";end if;

[0213] if std_match(i,"0-0--111")then results:=results OR"01";end if;

[0214] if std_match(i,"000--1-1")then results:=results OR"01";end if;

[0215] if std_match(i,"0-00011-")then results:=results OR"01";end if;

[0216] if std_match(i,"0--00111")then results:=results OR"01";end if;

[0217] if std_match(i,"1--11000")then results:=results OR"11";end if;

[0218] if std_match(i,"111--0-0")then results:=results OR"11";end if;

[0219] if std_match(i,"1-11100-")then results:=results OR"11";end if;

[0220] if std_match(i,"11---00-")then results:=results OR"11";end if;

[0221] if std_match(i,"1-1--000")then results:=results OR"11";end if;

[0222] return results;

[0223] end function CorrectionsFor8to5;

[0224] In this example, 'std_logic_vector(7downto 0)' refers to all 8 bits of N (labeled 0-7, bit 0 is the LSB, bit 8 is the MSB), and the function 'std_match' can be implemented using AND gates. For example, 'std_match(i,"00---11-")' can be implemented as follows:

[0225]

[0226] Where by is the bit y of N, and ∧ represents logical AND. Similarly, 'std_match(i,"11---00-")' can be implemented as:

[0227]

[0228] Additionally, in this example, the initial value of 'results' is set to the two LSBs of N (i.e., bits 0 and 1), and the final value of 'results' is set to the initial value of the result of a combination of 01 or 00 or an OR gate with a 2-bit value depending on the result of the above-described 'std_match' function. This assumes sharing of common factors. It is estimated that for n=8 and m=5, approximately 31 AND / OR gates are required to implement the lookup logic unit 1224; however, it should be understood that any equivalent logic function (e.g., implemented using NAND, NOR, XOR, etc.) may be used instead, for example, depending on the silicon process used for manufacturing or the target clock speed).

[0229] In this way, the lookup logic unit 1224 compares a predetermined subset of the bits of the input n-bit number with a predetermined value in the fixed function circuit, and sets the adjustment value according to the result of the comparison. As described above, by implementing the conversion from the n-bit number to the m-bit number in hardware using AND / OR gates to determine the adjustment value to be applied to the truncated version of the n-bit number, a very efficient implementation (e.g., in terms of silicon area, latency, and power consumption) for performing a specific conversion (e.g., 8-bit value conversion to 5-bit value) is provided. In this example, the hardware is not very flexible because it is implemented using AND and OR gates in a fixed function circuit to perform one or more specific conversions (e.g., from 8-bit number to 5-bit number). If different conversions are required, such as different n and / or m values, different hardware can be used. One compensation for this inflexibility is that the hardware can be implemented very efficiently (in terms of silicon area, latency, and power consumption). Since the compression process as described herein uses an 8-bit to 5-bit converter, and this is known at design time, the inflexibility is not a big problem, but the efficiency advantage is significant.

[0230] Although data decompression is not described above, it should be understood that reversing the above data compression operations enables data decompression. For example, when performing data decompression, reverse Figure 3A , 6A , 7A, 8A, 9, and 11. Figure 3B illustrates a method of data decompression that is the reverse of the Figure 3A data compression method shown. As Figure 3B shown, for each sub-block of compressed data, identify the compression mode from the block mode (box 322), and according to the mode, use a variable α mode (box 308', opposite to box 308 above), or a constant α mode (box 306', which is the opposite of box 306 above) to decompress the compressed sub-block data. For cases using any other data compression mode, it is treated similarly (box 310'). The data decompression of the sub-blocks (in boxes 306', 308', 310') may involve converting a number from n bits to m bits, where n < m (e.g., in the inverse operations of boxes 602, 702, 802, 912, 916, and 1112). This can be achieved using the Fig.13A method shown in Fig. 13B and the hardware shown in

[0231] As Fig.13A shown, the method includes receiving an input n-bit number N and expanding the number from n bits to m bits using bit replication (box 1302), and this can be implemented in the replication hardware unit 1322 in Fig. 13B . This bit replication involves appending (m - n) MSBs in N to the least significant end of N to generate an intermediate m-bit number R, as Fig. 13C shown. If m > 2n, then (m - n) > n, so all n bits (i.e., the entire N) must be appended at least once (e.g., k times) first, and then the (m - kn - n) MSBs of N are appended to form the intermediate m-bit number R, as Fig.13D shown. Alternatively, the bit replication operation can be described as follows: Assume (n ≤ m) and define and r = m mod n, form a new value R that includes k repetitions of N in the MSB position, and then, in the LSB, the r MSBs of N.

[0232] Then, an adjustment value is determined based on the input n-bit number N (block 1204), and as described below, this can be implemented using multiple AND and OR gates in the lookup logic unit 1224. These AND and OR logic gates (or alternatively, a functionally equivalent alternative logic arrangement) compare multiple predetermined subsets of the bits of N with predetermined values in the fixed-function circuitry and, based on the results of the comparison, determine the adjustment value, which is then added to the replicated value in the increment / decrement unit 1226 (from block 1302 and the replication hardware unit 1322) (block 1306). The value of the adjustment value is zero, one, or negative one. In some examples, i.e., for certain combinations of the values of n and m (where n < m), the adjustment value is always zero, and thus the increment / decrement unit 1226 and the lookup logic unit 1224 can be omitted from Fig. 13B the increment / decrement unit 1226 and the lookup logic unit 1224 can be omitted from

[0233] The operation of the lookup logic unit 1224 to determine the adjustment value (at block 1204) can be described with reference to a specific example: where n = 5 and m = 8 and the following VHDL (or its functional equivalent):

[0234] function CorrectionsFor5to8(i:std_logic_vector(4downto 0))

[0235] return std_logic_vector is

[0236] variable results:std_logic_vector(1downto 0);

[0237] begin

[0238] results := (others => '0');

[0239] if std_match(i,"00-11")then results := "01";end if;

[0240] if std_match(i,"11-00")then results := results OR"11";end if;

[0241] return results;

[0242] end function CorrectionsFor5to8;

[0243] In this example, 'std_logic_vector(4downto 0)' refers to all 5 bits of N (labeled 0-4, bit 0 is the LSB, bit 4 is the MSB). The function 'std_match' can be implemented using AND gates. For example, 'std_match(i,"00-11")' can be implemented as follows:

[0244]

[0245] Where by is the bit y of N, and ∧ represents logical AND. Similarly, 'std_match(i,"11-00")' can be implemented as:

[0246]

[0247] Furthermore, in this example, the initial value of 'results' is set to the two LSBs of N (i.e., bits 0 and 1), and the final value of 'results' is set to 01 or 00, or to the initial value of the result combined with 11 using an OR gate. It is estimated that for n=5 and m=8, approximately 7 AND / OR gates are required to implement the lookup logic unit 1224.

[0248] Lookup logic unit 1224 compares a predetermined subset of the bits of the input n-bit number with predetermined values ​​in the fixed function circuit and sets the adjustment value based on the result of the comparison. As described above, fixed function hardware using the AND and OR gates described above allows the hardware to be implemented very efficiently in terms of silicon area, latency, and power consumption. The hardware can be configured to perform the conversion for a small set of different values ​​of n and m.

[0249] The following further examples show how the adjustment values ​​are calculated (in block 1204 and cell 1224) for other values ​​of n and m.

[0250] For n=8 and m=4, the following example VHDL shows how the adjustment value is calculated (in block 1204 and cell 1224):

[0251] function CorrectionsFor8to4(i:std_logic_vector(7downto 0))

[0252] return std_logic_vector is

[0253] variable results:std_logic_vector(1downto 0);

[0254] begin

[0255] results:=(others=>'0');

[0256] if std_match(i,"00--11--")then results:="01";end if;

[0257] if std_match(i,"000-1-1-")then results:=results OR"01";end if;

[0258] if std_match(i,"0-0-111-")then results:=results OR"01";end if;

[0259] if std_match(i,"00001--1")then results:=results OR"01";end if;

[0260] if std_match(i,"0-0011-1")then results:=results OR"01";end if;

[0261] if std_match(i,"00-01-11")then results:=results OR"01";end if;

[0262] if std_match(i,"0--01111")then results:=results OR"01";end if;

[0263] if std_match(i,"1--10000")then results:=results OR"11";end if;

[0264] if std_match(i,"11-10-00")then results:=results OR"11";end if;

[0265] if std_match(i,"1-1100-0")then results:=results OR"11";end if;

[0266] if std_match(i,"11110--0")then results:=results OR"11";end if;

[0267] if std_match(i,"1-1-000-")then results:=results OR"11";end if;

[0268] if std_match(i,"111-0-0-")then results:=results OR"11";end if;

[0269] if std_match(i,"11--00--")then results:=results OR"11";end if;

[0270] return results;

[0271] end function CorrectionsFor8to4;

[0272] It is estimated that for n=8 and m=4, approximately 41 AND / OR gates are required to implement the lookup logic unit 1224. In contrast, for n=4 and m=8, only bit duplication is required, and the adjustment value is zero in all cases.

[0273] For n=8 and m=3, the following example VHDL shows how the adjustment value is calculated (in block 1204 and cell 1224):

[0274] function CorrectionsFor8to3(i:std_logic_vector(7downto 0))

[0275] return std_logic_vector is

[0276] variable results:std_logic_vector(1downto 0);

[0277] begin

[0278] results:=(others=>'0');

[0279] if std_match(i,"00-11---")then results:="01";end if;

[0280] if std_match(i,"0001-1--")then results:=results OR"01";end if;

[0281] if std_match(i,"0-0111--")then results:=results OR"01";end if;

[0282] if std_match(i,"0001--11")then results:=results OR"01";end if;

[0283] if std_match(i,"00-1-111")then results:=results OR"01";end if;

[0284] if std_match(i,"11-0-000")then results:=results OR"11";end if;

[0285] if std_match(i,"1110--00")then results:=results OR"11";end if;

[0286] if std_match(i,"1-1000--")then results:=results OR"11";end if;

[0287] if std_match(i,"11-00---")then results:=results OR"11";end if;

[0288] if std_match(i,"1110-0--")then results:=results OR"11";end if;

[0289] return results;

[0290] end function CorrectionsFor8to3;

[0291] It is estimated that for n=8 and m=3, approximately 31 AND / OR gates are required to implement the lookup logic unit 1224. In contrast, for n=3 and m=8, only bit duplication is required, and the adjustment value is zero in all cases.

[0292] Reference above Figure 2A-C, 3A, and 4-11 describe compression methods that take as input source data in RGBA8888 or RGBX8888 format or corresponding formats where the channels are in a different order (e.g., ARGB). As described above, in examples where the source data is not in this format, a preprocessing step may be used to convert the source data to an appropriate format (e.g., to 888Z, where Z is an integer not greater than 8). Fig.14 The first example of describing this preprocessing step converts the data value in RGBA10:10:10:2 format into RGBA8883. Fig.16 Alternative techniques for preprocessing 10-bit data are described. By using one or both of these preprocessing methods, the likelihood of meeting the compression threshold (and thus using Figure 2A -C in any one of the main compression unit 202 lossless compression method); but need to be Figure 2A -C with minor modifications to the methods performed by the architecture shown in Figure 1, as described below. Furthermore, while these conversion methods are described herein in terms of the pre-processing steps of the compression methods described above, both conversion methods may alternatively be used independently of any other method described herein. It should also be understood that while the compression method implemented by the main compression unit 202 is inherently lossless, if used in conjunction with Fig.14 The overall data compression method is lossy if used in combination with the conversion method (which is not lossless). Fig.16 The conversion method of is lossless and is therefore suitable for use as a pre-processing step for the main compression unit 202, since the entire method remains lossless; however, if Fig.16 method, discarding any bits from the fourth pseudo-channel, the overall data compression method becomes lossy.

[0293] Fig.14 A flow chart of a first example method for converting pixel data from RGBA10:10:10:2 format to RGBA8883 is shown. Fig.14 As shown, the MSB of each RGB channel is checked (block 1402), and if one or more of the three MSBs are equal to one ("yes" in block 1402), a flag is set (block 1404), otherwise the flag is not set. The flag may be referred to as a high dynamic range (HDR) flag because if at least one MSB is equal to one, then the pixel data may be HDR data. HDR images can represent a larger range of brightness levels than non-HDR images, and HDR images are typically created by merging multiple low or standard dynamic range (LDR or SDR) photos or by using special image sensors. Hybrid log-gamma is an HDR standard that defines a nonlinear transfer function in which the lower half of the signal values ​​(which is the SDR portion of the range) is scaled using x 2The curve uses a logarithmic curve for the upper half of the signal value (which is the HDR part of the range), and the white signal standard level is set to 0.5 signal value. Of the 10 bits of R / G / B data, the most significant bit indicates whether the value is in the lower half of the range (SDR part) or in the upper half of the range (HDR part).

[0294] In addition to setting the flag or not, the pixel data is reduced from 10 bits to 8 bits in different ways depending on whether one or more of the MSBs of the RGB channels is one. If none of the three MSBs is equal to one ("No" in block 1402), each 10-bit value of the RGB channels is truncated by removing both the MSB (known to be zero) and the LSB (block 1410). If any of the three MSBs is equal to one ("Yes" in block 1402), there are two different ways to reduce the 10-bit value to 8 bits (block 1406). In a first example, two LSBs can be removed from each 10-bit value, and in a second example, the above referenced method can be used. Fig. 12A -B describes the method.

[0295] In use Fig. 12A In the case of the method, n=10 and m=8, the following example VHDL shows how the adjustment value is calculated (in block 1204 and cell 1224):

[0296] function CorrectionsFor10to8(i:std_logic_vector(9downto 0))

[0297] return std_logic_vector is

[0298] variable results:std_logic_vector(1downto 0);

[0299] begin

[0300] results:=(others=>'0');

[0301] if std_match(i,"00------11")then results:="01";end if;

[0302] if std_match(i,"0-00----11")then results:=results OR"01";end if;

[0303] if std_match(i,"0-0-00--11")then results:=results OR"01";end if;

[0304] if std_match(i,"0-0-0-0011")then results:=results OR"01";end if;

[0305] if std_match(i,"1-1-1-1100")then results:=results OR"11";end if;

[0306] if std_match(i,"1-1-11--00")then results:=results OR"11";end if;

[0307] if std_match(i,"1-11----00")then results:=results OR"11";end if;

[0308] if std_match(i,"11------00")then results:=results OR"11";end if;

[0309] return results;

[0310] end function CorrectionsFor10to8;

[0311] It is estimated that for n=10 and m=8, approximately 25 AND / OR gates are required to implement the lookup logic unit 1224.

[0312] To reverse this mapping (e.g. Fig.13A As shown), such that n=8 and m=10, the following example VHDL shows how to calculate the adjustment value (in block 1204 and cell 1224):

[0313] function CorrectionsFor8to10(i:std_logic_vector(7downto 0))

[0314] return std_logic_vector is

[0315] variable results:std_logic_vector(1downto 0);

[0316] begin

[0317] results:=(others=>'0');

[0318] if std_match(i,"0011----")then results:="01";end if;

[0319] if std_match(i,"001-11--")then results:=results OR"01";end if;

[0320] if std_match(i,"001-1-11")then results:=results OR"01";end if;

[0321] if std_match(i,"110-0-00")then results:=results OR"11";end if;

[0322] if std_match(i,"110-00--")then results:=results OR"11";end if;

[0323] if std_match(i,"1100----")then results:=results OR"11";end if;

[0324] return results;

[0325] end function CorrectionsFor8to10;

[0326] It is estimated that for n=8 and m=10, approximately 19 AND / OR gates are required to implement the lookup logic unit 1224.

[0327] Regardless of the values ​​of the three MSBs of the pixel's RGB channels, the 2-bit alpha channel value is modified in the same way. Fig.14 As shown, the HDR flag is appended to the existing 2-bit value (block 1408) so that the output alpha channel value is 3 bits.

[0328] Fig.14 The method may be implemented on a per-pixel basis, but in variations of the method, the decision resulting in setting the HDR block (in block 1402) may alternatively be performed less frequently, for example, on a sub-block or mini-block basis.

[0329] As mentioned above, in Fig.14 In the case where the method is used as a preprocessing step, Figure 2A -C can be slightly modified. Specifically, the test and selection unit 206 (in Figure 2A or the test and determination unit 210 (in Figure 2B -C) is calculated based on the size of the original data before preprocessing, or alternatively, the threshold can be modified to take into account the reduced size of the alpha channel values ​​in the source data (i.e. 3 bits instead of 8 bits). This means that, for example, instead of defining the compression threshold based on a ratio, the threshold used can be defined based on the size of the compressed data block (e.g. 128 bytes) instead of a ratio. In addition, in the alternate compression unit 204, the above reference Figure 3A As with the method described in 4-11, this lossy compression method is also modified as described below because the resulting alpha value only includes 3 bits, one of which is the HDR flag.

[0330] exist Figure 3A In a first variation of the lossy compression method of , there may be three constant alpha modes (in block 306) that may be used with the variable alpha mode (in block 308). This is because there are only four possible alpha values ​​A (rather than 256 values ​​where alpha is an 8-bit value), so more constant alpha modes can be used than those mentioned above. Figure 5A -B. Each constant alpha mode has a different predefined constalphaval value, which can be determined by inserting block mode bits 408 (in Figure 4C 670-673). As described below, in the case of an alpha value of zero, it uses the same field value as the variable alpha; however, since such a block is fully transparent, RGB may not be as important as for other alpha values, and in this mode, the data is encoded as if alpha is variable per pixel.

[0331]

[0332] Then, use Fig.11 The constant alpha mode (block 306) is implemented using the method of , i.e., using a coded pattern and three palette colors; however, in this case, each color in the palette is represented as RGB676 plus a 1-bit HDR flag, so block 1112 involves a different conversion than described above. To perform this conversion, for the G channel, the value is truncated, and for the R and B channels, the above referenced values ​​can be used again. Fig. 12A- The method described in B, where n=8 and m=6, or alternatively, the values ​​may simply be truncated.

[0333] The adjusted values ​​for n=8 and m=6 may be determined (in block 1204 and lookup logic 1224) according to the following example VHDL (or its functional equivalent):

[0334] function CorrectionsFor8to6(i:std_logic_vector(7downto 0))

[0335] return std_logic_vector is

[0336] variable results:std_logic_vector(1downto 0);

[0337] begin

[0338] results:=(others=>'0');

[0339] if std_match(i,"00----11")then results:="01";end if;

[0340] if std_match(i,"0-00--11")then results:=results OR"01";end if;

[0341] if std_match(i,"0-0-0011")then results:=results OR"01";end if;

[0342] if std_match(i,"1-1-1100")then results:=results OR"11";end if;

[0343] if std_match(i,"1-11--00")then results:=results OR"11";end if;

[0344] if std_match(i,"11----00")then results:=results OR"11";end if;

[0345] return results;

[0346] end function CorrectionsFor8to6;

[0347] It is estimated that for n=8 and m=6, approximately 19 AND / OR gates are required to implement the lookup logic unit 1224.

[0348] Reverse mapping (e.g., as Fig.13A As shown), so that n = 6 and m = 8:

[0349] function CorrectionsFor6to8(i:std_logic_vector(5downto 0))

[0350] return std_logic_vector is

[0351] variable results:std_logic_vector(1downto 0);

[0352] begin

[0353] results:=(others=>'0');

[0354] if std_match(i,"0011--")then results:="01";end if;

[0355] if std_match(i,"001-11")then results:=results OR"01";end if;

[0356] if std_match(i,"110-00")then results:=results OR"11";end if;

[0357] if std_match(i,"1100--")then results:=results OR"11";end if;

[0358] return results;

[0359] end function CorrectionsFor6to8;

[0360] In addition, modify the four-color mode (in Fig.11), so that the pixel is represented as RGB554 (rather than RGB555 as described above, as in block 602) and a 1-bit HDR flag. Fig. 12A -B) Perform an operation to reduce the bit value from 8 bits to 5 bits or 4 bits.

[0361] Similar modifications in data format are also made to the variable alpha mode, as referenced above. Fig. 9 Specifically, three palette entries are encoded with a 1-bit HDR flag, 2 alpha bits, and RGB665 (in blocks 910-912), and four-color mode uses a 1-bit HDR flag, 2 alpha bits, and RGB444 (in block 916).

[0362] As a result of the different data formats used, data is packed into data fields in a slightly different manner than described above (i.e., as Figure 6C 60-bit data fields 660-663) shown in FIG. Fig.15A -D to describe. Fig.15A and 15B Involving constant alpha patterns (such as Fig.11 ), Fig. 15C and 15D Involving variable alpha modes (such as Fig. 9 (packaged in box 914 of ). Fig.15A and 15C Packing using four-color mode (blocks 916 and 602) is shown. Fig. 15B and 15D Packing using a coding pattern (blocks 908-912 and 1112) is shown. Fig. 15C The packaging arrangement shown in replaces Fig. 10C The packaging arrangement shown in and described above. Fig.15D The packaging arrangement shown in replaces Fig. 10B Packaging arrangement as shown and described above.

[0363] Fig.16 A flowchart of a second exemplary method for converting pixel data from a 10-bit (e.g., RGBA 10:10:10:2) format to an 8-bit format (e.g., 8888 format) is shown. For example, the method may be used as a pre-processing step before the RGBA 10:10:10:2 format data is input to the main compression unit 202. Fig.17 The schematic diagram in Fig.16 Schematic diagram in . Fig.17 As shown, the input pixel data comprises four input channels 1702-1708, referred to herein as RGBA channels, but the data may alternatively represent other channels. The output of the method is four 8-bit pseudo channels.

[0364] Each of the RGB input channels 1702-1706 includes 10 bits, and the A (α) input channel 1708 includes two bits. Each RGB channel is truncated by removing one or more LSBs (block 1602), and in the method shown, the R and B channels are truncated to 7 bits 1710, 1714 by removing three bits from each channel 1711, 1715 and the G channel is truncated to 8 bits 1712 by removing two bits 1713. The 8-bit channel 1712 formed by truncating the G channel forms one of the four output pseudo channels (block 1604).

[0365] The alpha channel data is optionally Gray encoded (box 1606) before one bit 1716 is appended as the new MSB to the truncated R data 1710 to form another of the four output pseudo channels 1720, and another bit 1718 from the (optionally Gray encoded) alpha channel data is appended as the new MSB to the truncated B data 1714 to form another of the four output pseudo channels 1722 (box 1608).

[0366] The fourth of the four output pseudo channels 1730 is formed by the error value. In one example, to generate the error value, the truncated RGB787 data 1710, 1712, 1714 is copied so that each channel includes 10 bits 1724, 1726, 1728 (block 1610). Fig.17 As shown, this bit copying involves copying three (for R and B) or two (for G) MSBs and appending them as new LSBs to the truncated data. These new LSBs of the updated 10:10:10 data are then combined with the corresponding number of original LSBs of the input data channels 1711, 1713, 1715 to generate an error value (block 1612). One way to combine these three or two bit values ​​is to use a subtraction operation (modulo 8 for R and B, modulo 4 for G), as shown below:

[0367] Red error=(3new red LSBs–3LSBs of input red data)mod 8

[0368] Green error=(2new green LSBs–2LSBs of input green data)mod 4

[0369] Blue error=(3new blue LSBs–3LSBs of input blue data)mod 8

[0370] However, by using XOR, as Fig.17 As shown, a more compact hardware implementation can be provided. In other examples, any reversible function can be used. In an alternative example, in block 1612, instead of performing an operation of copying the MSB as a new LSB bit to the truncated data, the three (for R and B) and two (for G) MSBs of the truncated RGB787 data can be directly combined with the original LSBs of the input data channels 1711, 1713, 1715 to generate an error value. As described above, the combination can be achieved by subtraction, XOR, or any suitable reversible function.

[0371] After the three error values ​​are generated (in block 1612), they are packed together to form a fourth pseudo channel 1730 (block 1614). This may be formed by concatenating the three error values, or alternatively, the bits from the error values ​​may be interleaved so that the three LSBs 1732 of the pseudo channel 1730 include the LSBs from each of the three error values, the two MSBs 1734 of the pseudo channel 1730 include the MSBs from each of the red and blue error values, and the middle three bits 1736 include the remaining three bits, one for each of the three error values, as shown in FIG. Fig.17 By using this bit arrangement in the fourth pseudo channel 1730, the degradation of image quality caused by discarding one or more of these bits is minimized (e.g., as described below with reference to Fig.18A For example, if the 3 LSBs of the fourth pseudo channel 1730 are discarded, a single MSB of the error value of each RGB channel will be lost, rather than the entire error value of one of the channels (eg, the B channel).

[0372] The following pseudocode (or its functional equivalent) can be used to implement Fig.16 Method:

[0373] r'[9:0]:=Replicate(Truncate(r[9:0],10,7),7,10);

[0374] g'[9:0]:=Replicate(Truncate(g[9:0],10,8),8,10);

[0375] b'[9:0]:=Replicate(Truncate(b[9:0],10,7),7,10);

[0376] r_x[2:0]:=r'[2:0]xor r[2:0];

[0377] g_x[1:0]:=g'[1:0]xor g[1:0];

[0378] b_x[2:0]:=b'[2:0]xor b[2:0];

[0379] a'[1:0]:={a[1],a[1]xor a[0]}

[0380] ch0_Red:={a'[0],r'[9:3]}

[0381] ch1_Grn:=g'[9:2]

[0382] ch2_Blu:={a'[1],b'[9:3]}

[0383] ch3_Lsb:={r_x[2],b_x[2],r_x[1],g_x[1],b_x[1],r_x[0],g_x[0],b_x[0]}

[0384] Although Fig.16 and 17 While the pseudo code above shows that the bit from the alpha channel is appended as the MSB to the truncated R and B channel data (in block 1608), in other examples, the alpha bit may be inserted at a different location (e.g., as the LSB or in the middle of the truncated 7-bit data). However, when this method is used in conjunction with lossless compression techniques, the data compression that can be achieved may be improved by positioning the alpha bit as the MSB.

[0385] Then, use Fig.16 The four 8-bit pseudo channels 1720, 1712, 1722, 1730 generated by the method can be fed into a data compression method designed to operate on RGBX8888 data, such as the lossless compression method implemented by the main compression unit 202 in Figure 2.

[0386] As described above, using Gray coding for the alpha channel (block 1606) is optional. By using Gray coding (where only one bit changes when the value increases by one), lossless compression methods (such as those described below with reference to Fig. 20A -B, 21A-B and 22 and / or described in British Patent No. GB2530312) can achieve an increase in data compression (e.g., by 1-2%). This is because it reduces the impact of the alpha channel, which is usually unrelated to the R, G or B data, on the color and / or spatial decorrelation step, which is a common first (or early) step in lossless compression. Color channel decorrelation usually uses a color transform, such as:

[0387] R*=R-Gmod2 8

[0388] G*=G

[0389] B*=B-Gmod2 8

[0390] A*=A

[0391] In the already executed Fig.16 In the case of preprocessing, the pseudo channels do not correspond to the original color data, but rather combine alpha data into the red and blue channels. In the case of changes in alpha values, the values ​​of R* and B* can vary significantly from one pixel to the next, making the data more difficult to compress; however, by using Gray encoding, any single value change only affects R* or B*, not both at the same time.

[0392] as Fig.14 If the method Fig.16 is used as a preprocessing step, then Figure 2A -C can be implemented slightly differently. In particular, Fig.16 In the case where the method is used as a pre-processing step of the main compression unit 202, Figure 2A Testing and Selection Unit 206 or Figure 2B The test and decision unit 210 in or 2C may consider additional options. In the above method, these test and decision / selection units 206, 210 compare the compressed data generated by the main compression unit 202 with the compression threshold, and if the compression threshold is met, the compressed data generated by the main compression unit 202 is output. If the threshold is not met, the data compressed by the backup compression unit 204 (or subunits 204A, 204B) is output instead. Fig.16 In the case of the preprocessing method of FIG. 1 , if the compressed data generated by the main compression unit 202 does not meet the compression threshold, the size of the compressed data can be further reduced by discarding all data corresponding to the fourth pseudo channel 1730 (i.e., the pseudo channel formed by the error value). In this implementation, the compressed data generated by the backup compression unit 204 (or subunits 204A, 204B) is output only when the compression threshold is still not met after discarding all data corresponding to the fourth pseudo channel. This reduces the amount of data lost in data compression (because the lossy compression method in the backup compression unit 204 is used less), thereby improving the quality of the subsequently decompressed data.

[0393] Instead of discarding the entire fourth pseudo channel, refer to Fig.19A The described bit prediction techniques may alternatively be used to partially drop bits prior to compression.In a further variant, a subset of the bits of the fourth pseudo channel may be dropped and the data may then be fed back into the main compression unit 202.

[0394] Fig.18A A flowchart of a data compression method is shown. Fig.16 The pre-processing method (block 1802) is similar to that described in, for example, GB2530312 and / or the following references Fig. 20A -B, 21A-B and 22 described lossless data compression methods (block 1804) are combined. As described above, some or all of the fourth pseudo channel can be discarded (in block 1804) to increase the amount of data compression. As described above, this discarding can be implemented to ensure that the compression threshold (such as Figure 2A -C), or the discarding may be implemented to improve compression without any defined threshold or test and decision process. In order to enable the decompression hardware to operate in the same manner regardless of whether some or all of the fourth pseudo channel data is discarded (in block 1804), when the data is discarded, one or more zeros (e.g., a single byte of data containing all zeros) or another constant, predefined bit sequence may be reserved for the channel. Alternatively, a special packing code or other means may be used to indicate to the decompressor that the fourth pseudo channel data has been discarded. Then, the fourth pseudo channel data may be discarded as described below with reference to Fig.18B Decompression is performed.

[0395] like Fig.18B As shown, the compressed data is first decompressed (box 1810) using the inverse of the lossless compression method used when compressing the data (in box 1802). This operation outputs data in 888X format because the fourth channel can be 8 bits or less, depending on how much data is discarded (as described above) and can be completely absent. Then, the fourth channel is reconstructed so that it includes 8 bits for pixels (box 1812), and this can be achieved by adding zeros or another predefined bit sequence. As described above, one or more zeros or bit sequences can be present in the compressed data and used for reconstruction (in box 1812), or alternatively, reconstruction can be performed based on a known convention without any bits associated with the fourth channel in the compressed data.

[0396] The alpha channel data may then be extracted (block 1814) by removing the MSB from the first and third channels and concatenating them (followed by optional Gray decoding, which is used for data compression), leaving 787 format data, which is expanded to a 10:10:10 format by bit copying (block 1816). The error values ​​from the fourth pseudo channel are then applied, using the inverse of the function used to generate these error values ​​(in block 1612). Fig.18BIn the example shown, the LSB from each channel (e.g., 3 bits from the first and third channels and two bits from the second channel) is combined with the corresponding bit from the fourth channel using an XOR logic gate or equivalent logic block (block 1818). In the case where any bits from the fourth channel were previously discarded, the XOR with zero will not change the value of the LSB. In the example of using a predefined bit sequence that does not include all zeros in the reconstruction, a substitution function can be used to generate an error value when compressing the data (at block 1612) and apply the error value when decompressing the data (at block 1818).

[0397] In an example implementation, you can use Fig.14 and 16 In such an example, Fig.14 The preprocessing method shown and described above may be used to preprocess RGBA10:10:10:2 format data before such format data is input to the backup compression unit 204, or may be implemented before or by the initial backup compression subunit 204A. Fig.16 The pre-processing method shown and described above may be used to pre-process RGBA10:10:10:2 format data before it is input to the main compression unit 202.

[0398] The methods described above are described with reference to RGBA or RGBX data, but as mentioned above, these methods can also be used for data other than image data where three of the four channels (e.g., the RGB channels above) are related to each other in some way (e.g., color or spatially related) in some channels. For some types of data, such as YUV or YCbCr data (where YCbCr data is digital brightness and two chrominance components, YUV is its analog counterpart, but it can also be used to represent YCbCr), which are typically arranged in two or three plane formats (e.g., depending on whether the U and V data are separate or interleaved), there may be little or no correlation between channels within a block of data because the channels are typically assembled by aggregating non-intersecting (although adjacent) single-channel or two-channel pixel blocks, such as multiple tiles of only Y, only U, only V, or only UV being packed into the channels of a block. As a result, although the above compression methods can be used, and despite the palette modes of lossy compression methods (e.g., as described above with reference to Fig. 9 908-912 of ) are effective when the data has strong spatial and good correlation between channels, but they are not suitable for YUV or YCbCr data (or other unrelated data types) because it is difficult to predict values ​​based on their neighbors, so it relies too much on the four-color model ( Fig. 9 916).

[0399] Fig.19A is a schematic diagram of a data compression unit which increases the amount of compression achieved compared to the main compression unit 202 which implements only a lossless compression method such as that described in UK patent number GB2530312 or referenced below. Fig. 20A -B, 21A-B and 22 described methods. Fig.19A The data compression unit shown in FIG. 1 can be used as Figure 2A -C, especially in cases where the input data is not correlated across channels and therefore does not benefit greatly from color decorrelation or palette. In addition, due to Fig.19A The data compression unit of the main compression unit 202 can operate on each channel separately, so it can only target a subset of channels (for example, for channels using Fig.16 The alpha channel or fourth pseudo channel created by the method of ) is implemented, while the remaining channels are compressed using a lossless compression method, such as the method described in the British patent numbered GB2530312 or the method referenced below. Fig. 20A -B, 21A-B and 22. The data compression unit in FIG. 19 is used as Figure 2A -C, there is less reliance on the backup compression unit 204, which may involve more severe quantization and therefore result in a greater degradation in image quality.

[0400] Fig.19A The data compression unit shown may alternatively be connected to Figure 2A -C is used separately, i.e., there is no test and selection / decision unit 206, 210 or spare compression unit 206, and there is no need to ensure that the compression threshold is met. Instead, by using Fig.19A The data compression unit shown can increase the overall data compression amount achieved and can target a specific compression ratio. Fig.19A The data compression unit shown in FIG. 1 may also be used in conjunction with a compression method other than that described in the British patent number GB2530312 or the following references Fig. 20A -B, 21A-B and 22 are used together, and / or used to compress data other than image data (for example, used to compress any data having a compression algorithm and multiple levels of quantization, where further quantization improves the efficiency of the compression algorithm).

[0401] like Fig.19A As shown, the source data block (for the purpose of the following description, it is assumed to be in 8888 format) is split, and each channel can be considered separately (such as Fig.19A). Alternatively, two or more channels (or any subset of channels) may be considered together (and in this case, the determined total size relates to all channels considered together). For example, RGB data may be considered together, with a single quantization level (i.e., a single mapping parameter) being chosen uniformly across the three color channels. The following description considers each channel separately by way of example only.

[0402] The data for a single channel is input to a bit predictor element 1902 and an x-bit remapping element 1904. The operation of the x-bit remapping element is controlled based on an input from the bit predictor element 1902, called a mapping parameter. The mapping parameter specifies the data conversion or truncation operation performed by the x-bit remapping element 1904, and in particular, the mapping parameter specifies a value x. By selecting a lower value of x, the amount of data compression achieved is increased, however, because remapping is a lossy operation, the accuracy is reduced. The data conversion operations performed by the x-bit remapping element 1904 may also include operations such as low pass filtering, where the mapping parameter x determines the degree of filtering of the data.

[0403] The operation of the bit predictor element 1902 is Fig.19B . The bit predictor element 1902 takes the data of the channel (e.g., 8 bits per pixel for each pixel in the data block) and compresses it using the same data compression method used in the data compression element 1906 (block 1922), however, some operations of the data compression method (e.g., those operations after entropy encoding) may be omitted. For example, the bit predictor element 1902 may not pack the compressed data into a compressed data block, but may only determine the total size of the compressed data (block 1924). This total size is then compared to multiple thresholds (e.g., A Y , B Y , C Y , D Y , which may be stored, for example, in a lookup table), and based on the comparison, a mapping parameter (ie, the quantization level, and therefore the value of x) is determined and output (block 1926).

[0404] In examples where data compression within the bit predictor element 1902 is performed using a lossless compression method such as that described in UK Patent No. GB2530312 or as referenced below Fig. 20A-B, 21A-B and 22, the bit predictor element 1902 can use wavelet transformation, symbol remapping and group length generation to compress the data (in block 1922); however, the group length code, packing mode code and actual packing of the data can be omitted because they are not necessary to generate the compressed block size. In such an example, the total size of the compressed data of the channel can be given by the size of the variable length data of the channel (see below Fig. 20A -B, 21A-B and 22). The size can be calculated by adding four times the coefficient length of each group (which includes 2x2 group values) except the upper left corner. The group size can be determined by combining adjacent values ​​into groups of four values, and then the number of bits required to encode the maximum value therein is used as the group bit depth and encoded in the block. The size of the group is four times the bit depth. The upper left group is handled differently because the reference value is always stored with full precision and its size can be determined based on a lookup table. In other examples, any suitable data compression method can be used in the bit predictor element 1902 and the data compression element 1906.

[0405] The comparison with the multiple thresholds (in block 1926) may be implemented, for example, in a manner as shown in the following pseudo code (or its functional equivalent), where Chan Size is the total size of the compressed data for the channel:

[0406] If(Chan Size≤A Y )x=8

[0407] Else if(Chan Size≤B Y )x=7

[0408] Else if(Chan Size≤C Y )x=6

[0409] Else if(Chan Size≤D Y )x=5

[0410] Else x=4

[0411] In various examples, a lookup table may be used. The pseudo code (or lookup table) includes at least two lines but may include more lines. In addition, although the value of x is described herein as referring to the actual bit depth, in other examples, the mapping parameter x may correspond to a set of different quantizations.

[0412] The multiple thresholds (e.g., A Y , B Y , C Y , D Y) can be determined by compressing a large training image set multiple times using different threshold configurations and analyzing the resulting size of the compressed data or the score of an image quality metric for a given target compression ratio. The thresholds can be set to achieve a specific compression threshold or target compression ratio, or can be calibrated to minimize certain artifacts of lossy compression, such as blocking artifacts or banding. The thresholds can also be set so that only those blocks that do not compress well are quantized.

[0413] After the bit predictor element 1902 determines the mapping parameter (i.e., the value of x), the x-bit remapping element 1904 converts the input data from its original format to x bits per pixel, where x is the mapping parameter, and the original format may be 8 bits per pixel. This conversion may use truncation, for example, or may alternatively use the method described above with reference to Fig. 12A -B. As described above, in other examples, the mapping parameters may correspond to a different set of quantization rather than the actual bit depth, and in such examples, the remapping element 1904 converts the input data based on the mapping parameters. In other examples, the bit depth may not be changed, but the information content may be reduced by low-pass filtering under the control of the mapping parameters x. Alternatively, a combination of filtering and bit precision reduction may be employed.

[0414] The data generated by the x-bit remapping element 1904 is input to a data compression element 1906 which then compresses the data using a data compression method such as the lossless compression method described in UK patent number GB2530312 or the lossless compression method described below with reference to Fig. 20A -B, 21A-B and 22. It should be understood that although the method can be described as lossless and can be lossless based on the data input to the data compression element 1906, since the conversion performed by the x-bit mapping element 1904 may be lossy, the resulting compressed data is not lossless relative to the source data.

[0415] In order to be able to subsequently decompress the data, the value of x must be included in the compressed data in some way so that the correct inverse mapping can be used. Fig.19C An example of how four channels of data may be packed into a compressed data block is shown (in block 1910). Fig.19CAs shown, in the case where the data compression method includes entropy coding, the data size of each channel 1930-1933 can be different. The 8-bit mode field 1940 includes a 2-bit packing mode for each channel. One of the possible packing modes can be used to indicate that x<8; however, given the number of available bits, it is not possible to include the x value of the channel in the packing mode without increasing the size of the mode field 1940. Therefore, the bit depth encoding element 1908 can encode the value of x (where it is less than 8) in the data generated by the data compression element 1906. For example, the value of x can be encoded in the reference value field of the compressed channel, for example, by changing the least significant unused bit from 0 to 1, i.e., unary encoding. As described below with reference to 20A-B, 21A-B and 22, the reference value is a data value (generated by the data compression element 1906) that is not entropy encoded but included in the specified reference value field of the encoded data. For example, the reference value may be modified to encode the value of x as follows (where '0b' is a binary value indicator and e, f, g, h, i, j, k are used to identify the bits used to encode the reference value):

[0416] x Original value coding 7 0b0efghijk 0b1efghijk 6 0b00fghijk 0b01fghijk 5 0b000ghijk 0b001ghijk 4 0b0000hijk 0b0001hijk

[0417] If the compressed data has no redundancy that can be exploited, the value x may instead be packed with the compressed data, e.g. occupying header bytes. It may be read upon decompression to determine which inverse mapping to perform after decompressing the block in order to map the data back to its original precision.

[0418] Fig.19A An optional y-bit remapping element 1912 is also shown. This can be used to reduce the number of bits per pixel in the source data for the channel used by the bit predictor element 1902. The y-bit remapping element 1912 can use truncation or the above referenced Fig. 12A -B describes a method to reduce the bit depth of the source data. The bit depth, i.e., the value of y, can be a value between 4 and 8, where y=8 provides the most accurate prediction (i.e., in terms of selecting a value of x to meet an overall compression threshold or target) but is the most expensive in terms of operations performed by the bit predictor element 1912. A value of y=4 provides the least accurate prediction, but is the cheapest in terms of hardware and operations implemented by the bit predictor element 1902. Similar to the value x, the value y can correspond to some other type of quantization, e.g., a low pass filter. By removing noise from the data, the accuracy of the predictor results can be improved and may be less susceptible to change due to small perturbations in the original data.

[0419] It should be understood that although the above Fig.19AThe description of -C refers to source data comprising 8 bits per pixel per channel, and methods may also be used where there are more or fewer bits per pixel per channel, for example, 10, which may result in the use of more or fewer thresholds (in box 1926).

[0420] In the example where the source data is 10-bit data instead of 8888 data, the data compression unit may include additional pre-processing elements, Fig.19A The pre-processing element may perform similar operations as those described above. Fig.16 and 17 The 10-bit values ​​are truncated and then extended back to 10-bit values ​​using bit replication, thereby generating new LSBs, and the error values ​​are generated by XORing the LSBs of each original 10-bit value with the new LSBs of the corresponding truncated and extended value. The 8 MSBs of the three tiles (corresponding to the three input channels) form the first, second, and third pseudo channels, while the error values ​​are packed into the fourth pseudo channel as described above and in Fig.17 Then, a set of thresholds is used in the bit predictor element 1902 for the first three pseudo channels, and these thresholds may be different from the thresholds used for the 8888 data. A second set of thresholds (also different from the thresholds used for the 8888 data) is used for the fourth pseudo channel, and the quantization options may be reduced, for example, to only 6 bits and 3 bits. Fig.19A The data compression unit is used as Figure 2A In the case of the primary data compression unit 202 in any architecture of -C, the test and selection / decision unit also operates differently. Initially all four pseudo channels are checked to see if they fit into the target size, in which case they are included. If none of them fit, the first three pseudo channels are checked to see if they fit into a single additional byte, and if so, the fourth pseudo channel is replaced by a constant zero channel (occupying a single byte). If this test still does not meet the target compression threshold, the output of the alternate compression unit is used. The above referenced Fig.18B A modified version of the method described to decompress the data.

[0421] exist Fig.19A The data compression unit shown in FIG. 1 targets a specific compression ratio (eg, 50%) and uses the lossless compression method described in the British patent number GB2530312 or the following reference Fig. 20A In the examples of the methods described in 21A-B, 21A-B and 22, the RAW mode of the compression method can be modified to store data with different precision, such as 4 bits instead of 8 bits.

[0422] Fig.19AThe data compression unit shown in is a general unit capable of compressing multiple types of data, such as YUM, RGB (A), non-image data, etc. It is applicable to various combinations of quantization / lossy compression and can be used to improve the compression ratio or for a specific compression ratio. The threshold used can be calibrated to produce the desired properties, such as minimizing block artifacts or banding or optimizing a given metric score, and the threshold can be set conservatively to minimize the use of spare compression units that perform lossy compression (if provided). The data compression unit is also highly configurable, and the cost / complexity of the bit predictor element 1902 can be weighed against the accuracy and performance of the data compression. In addition, it is highly scalable and can be applied to only a subset of the data, for example, only to the alpha channel.

[0423] A first example of a lossless compression method may be performed in the main compression unit 202 ( Figure 2A -C and as described above) and in Fig.19A The data compression unit shown in is implemented in the data compression unit (for example, in the bit predictor element 1902 and the data compression element 1906 described in British Patent No. 2530312). British Patent No. 2530312 describes a data compression system in which 8x8 blocks of image data are compressed by performing color decorrelation, spatial decorrelation and entropy coding, and then the resulting encoded data values ​​are packaged into data packets for storage. In the system described in the patent, each iteration processes a row of data values ​​from the block. A modified version of the exponential Golomb coding is used for entropy coding, in which each coefficient stores a prefix to indicate the range of values ​​subsequently identified by a suffix. Having a prefix and suffix for each encoded coefficient makes it difficult to decode multiple values ​​simultaneously because it is not simple to quickly determine the location of the boundaries between encoded bits.

[0424] The main compression unit 202 ( Figure 2A A second example of a lossless compression method implemented in (as shown in FIG. 1 and described above) may be referred to Fig. 20A -B, 21A-B and 22. As described in British Patent No. 2530312 and in Fig. 20A -B, data compression may include the following steps (not necessarily in this order): segmentation into blocks, format conversion (box 2024), color channel decorrelation (box 2024, for example as described above), spatial decorrelation (box 2026), entropy encoding (box 2028), and then storage.

[0425] Entropy encoding is performed (in block 2028) according to a variable length coding (VLC) scheme so that the entropy encoded values ​​are unlikely to all have the same number of bits. Typically, more likely values ​​are encoded with fewer bits. In this way, it is possible to reduce the total number of bits used to encode all data values ​​in the data block by entropy encoding. In some cases, spatial decorrelation can expand the data, and these cases can be treated as special cases (i.e., the data is treated differently than other cases) to limit the expansion.

[0426] VLC encoding can be performed reasonably straightforwardly at high rates, but VLC decoding at a matching rate can be significantly more difficult because the bit boundaries between consecutively stored coded data values ​​are unknown before the coded data is analyzed, i.e., the length of the coded data values ​​is not known before the coded data is analyzed. In particular, when encoding, multiple symbols can be independently mapped to their corresponding codes and code lengths and then merged into a continuous output bit stream. However, when decoding, each code in the coded bit stream is usually examined sequentially in order to determine its length and, in turn, the start position of the next code. In other words, the bit boundaries between different coded data values ​​need to be found.

[0427] In this second example method, entropy encoding is performed on multiple groups of data values ​​(e.g., 2x2 groups of data values). For each group of data values, an indication is included in the encoded output (e.g., in a header portion thereof) to indicate how many bits are used for each encoded data value representing the group of data values. The encoded data value is then included in the encoded output according to the indicated number of bits. This system means that decoding of the encoded data values ​​is simplified (compared to the system of British Patent No. 2530312) because simply reading the indication (e.g., in the header) allows the bit boundaries between different encoded data values ​​to be determined. In other words, the indication allows the size of the corresponding encoded data portion to be quickly determined (e.g., within only a single clock cycle). Reference will be made below to Fig.21A -B and 22 to describe this in more detail.

[0428] Fig.21A An 8x8 block of data values ​​2100 is shown which has been spatially decorrelated and remapped by one of the spatial decorrelation modules 2004. The data values ​​relate to corresponding pixel values. Fig. 22 The flowchart shown in describes a method for performing entropy encoding on a block of data values ​​at the entropy encoding module 2006. The entropy encoding module 2006 outputs the encoded data output 2110 (eg Fig.21B2100). The coded data output 2110 is of variable length, depending on the compression that can be achieved by the entropy coding process. In particular, in the example where each received data value in the block 2100 includes 8 bits (i.e., 1 byte), the coded data output 2110 includes an 8-bit (1-byte) wide reference value field 2112, a 48-bit (6-byte) wide size indication field 2114, and in this example, a variable size field that has been configured to maintain 8-bit alignment of the field, which is any value between 8 bits (1 byte) and 448 bits (56 bytes) wide. If the entropy coding process cannot losslessly represent the data values ​​in the data block 2100 without exceeding the number of bits available in the coded data output 2110 (i.e., 504 bits or 63 bytes), the data values ​​in the data block 2100 are stored in the coded data output in their original form, with 8 bits for each data value. The header portion of the data packet in which the coded data output is placed has an indication of the format of the coded data within the data packet. For example, the indication may comprise two bits so that up to four different encoding modes may be set, which may include an original data format, an entropy coded format, and a constant format in which all data values ​​within a block have the same value, such that the value may be stored once (using 8 bits) to represent the value of each data value within the block.

[0429] A block of data values ​​is received at the entropy coding module 2006 (block 2202). The rows and columns of the block are as follows: Fig.21A Arranged as shown. The data value block 2100 includes multiple groups of data values ​​(in this example, most are 2x2 groups of data values ​​(related to 2x2 groups of pixel values), but in other examples, the groups can be different shapes and / or sizes). Block 2100 includes fifteen 2x2 groups of data values, and one special group (in the upper left of the block) that includes only three data values. The upper left data value (A0) is not entropy encoded, but the data value at position A0 is included in the reference value field 2112 of the encoded data output 2110 (box 2204). Since the group in the upper left corner represents a group of similar size compared to the other groups in the block, but minus the data value to be used as a reference value, the group in the upper left corner includes fewer (e.g., 3 instead of 4) data values ​​than each of the other groups.

[0430] exist Fig.21A In the example shown, for entropy coding purposes, the rows in the block have the order A", E", C", G", B", D", F", H", and the columns in the block have the order 0, 4, 2, 6, 1, 3, 5, 7. Other examples may be different from Fig.21A Sort the rows and columns as shown. Fig.21AThe example order shown does not exactly match the order in which the spatial decorrelation module processes the rows (e.g., row 6 is shown above rows 1 and 3). With the exception of the top left 2x2 group, which only groups three values ​​and is encoded slightly differently, each aligned group of 2x2 values ​​is encoded together. This example grouping is chosen so that: (a) the values ​​in the group belong to (if possible) the same spatial frequency, and (b) the values ​​in the group are from pixels that are likely to be spatially nearby. This is done because they are more likely to be "similar" in magnitude, so the group can be compressed more efficiently.

[0431] As mentioned above, data values ​​are unsigned and their distribution is biased towards zero (due to color correlation and spatial decorrelation processes). Therefore, data values ​​may have leading zeros. Therefore, data values ​​can be compressed simply by removing one or more leading zeros from the data value (if possible). An indication is used to indicate how many leading zeros have been removed.

[0432] The group of four data values ​​in the upper left corner is processed differently: (a) the upper left pixel is used as a reference and stored separately, and (b) the remaining three values ​​have a different encoding scheme that has been "trained" for a large set of image data so that: (i) the total number of bits used to represent the three values ​​is a multiple of 4 for alignment purposes (this matches the 2x2 block), and (ii) the total storage cost (for training the image group) has been minimized. The specific group of data values ​​in the upper left corner of the block is processed (box 2206). Specifically, an indication of the specific group is included in the size indication field 2114 (box 2208). For the corresponding data value group in block 2100, each indication in the size indication field has three bits. The 3-bit indication can be used as an index into a lookup table to retrieve a number of bits for each data value in the specific group so that the number of bits for each value is sufficient to store the value. There are sixteen groups of data values ​​in block 2100, so that the size indication field includes 48 bits (i.e., 3*16 bits) or 6 bytes. Fifteen groups of data values ​​(groups of four data values) in a block will be encoded as a number of bits that is a multiple of four (because, as described below, each encoded data value in a group (of four data values) has the same number of bits), and on any given row, each of these fifteen groups contributes a multiple of two bits. In order to maintain convenient alignment of the compressed data (because limiting data alignment can reduce hardware complexity), restrictions are applied to the options available to the upper left group of only 3 elements. The upper left group has three data values, one of which (E0) is in row 0. For hardware efficiency, the total data of the row is expected to be an even number of bits, so the possible lengths of the encoded data values ​​that can be used to represent this data value are restricted to even numbers. Similarly, the combined lengths of the two encoded data values ​​used to represent the other two data values ​​of this group (A4 and E4) sum to an even value. In addition, in this example, the combined lengths of all encoded data values ​​in the encoded data output will be rounded up to the nearest byte (so that the encoded data output is aligned on a byte boundary), as well as all other groups of data values ​​in the block. Therefore, the total number of bits used to encode the upper left data value group is also a multiple of four.

[0433] Using a size indicator comprising three bits, eight sets of lengths for encoded data values ​​can be set. For example, the following table shows some possible lengths of encoded data values ​​that can be represented by eight different size indicators for the upper left block. The lengths shown in the following table are achieved by evaluating a very large set of images and selecting the combination (from a very large set of possible combinations) that results in the lowest total storage cost.

[0434] Size Indicator E0 A4 E4 Overall length 000 0 0 0 0 001 2 1 1 4 010 2 3 3 8 011 4 3 5 12 100 4 5 3 12 101 6 5 5 16 110 6 7 7 20 111 8 8 8 24

[0435] The entropy coding module 2006 selects the code with the smallest total length that can (losslessly) represent the {E0, A4, E4} triplet from the possible options (e.g., as shown in the table above) by removing leading zeros from the data value. In the case of a tie (e.g., if deciding between the size indications 011 and 100 in the example shown in the table above), any of the tie codes may be selected, but as an example, the code with the smallest numeric code (e.g., 011) may be selected.

[0436] The upper left group of encoded data values ​​is included in the variable size field 2116 of the encoded data output 2110 (eg, at the beginning of the variable size field 2116) (block 2210).

[0437] The remaining (e.g., fifteen) data value groups in block 2100 are then processed (block 2212). Specifically, a number of bits (e.g., a minimum number of bits) for representing a maximum value of a data value of a group is determined (block 2214), and an indication of the determined number of bits is included in a size indication field 2114 of the encoded data output 2110 of the group (block 2216). Block 2214 may be implemented by finding which data value in the group has the minimum number of leading zeros, and then identifying the minimum available encoding that will suffice. Note that not all possible data lengths are available to be encoded. For example, as described in the example below, a data length of seven bits is not available to be encoded. Thus, the determined number of bits may be the minimum "valid" number of bits that may be used to represent a maximum value of a received data value in the group, where it is valid if the number of bits is valid as indicated by an indication to be included in the size indication field 2114. For example, there may be a predetermined set of valid bit numbers, which may be indicated by the indication (e.g., as listed in the table above), and the minimum valid bit number may be the minimum value of the valid bit numbers in the predetermined set that is sufficient to represent the maximum value of the received data value in the set.

[0438] When the number of bits to be used to represent each encoded data value in a group has been determined, some leading zeros can be removed from each data value in the group (if appropriate) to determine the encoded data values ​​so that each encoded data value in the group has the determined number of bits for the group.

[0439] The encoded data values ​​representing the data values ​​in the group are included in the variable size field 2116 of the encoded data output 2110 (block 2218). The order in which the encoded data values ​​are included in the variable size field 2116 is predetermined and corresponds to the order in which the indications were included in the size indication field 2114 so that when the encoded data values ​​are decoded, the decoded data values ​​within the block are known.

[0440] For example, if the four data values ​​in a group are 00000011, 00000100, 00000001, and 00000000, 00000100 is the maximum value in the group, and three is the minimum number of bits that can be used to represent the maximum value. Three is the number of effective bits in the example shown in the above table, in the sense that an indication can be included to indicate that each coded data value of the group has three bits. Therefore, five leading zeros can be removed from each data value in the group. Therefore, the coded data values ​​of the group are 011, 100, 001, and 000, and these coded data values ​​are included in the variable size field 2116. An indication indicating that three bits are used to represent each coded data value in the group (e.g., 011) is included in the size indication field 2114. Different groups (e.g., 2x2 groups) may use different numbers of bits for their encoded data values, and each group may have its own indication in the size indication field 1304 of how many bits are used in the variable size field 2116 for the encoded data values ​​for that group.

[0441] As an example, the following table shows how the number of bits of an indication corresponds to a 2x2 group.

[0442]

[0443]

[0444] Note that there is no indication that seven bits are used for each encoded data value. Therefore, in this example, if the largest 8-bit value within a group has only one leading zero, the minimum number of significant bits that can be used to represent each encoded data value in the group is eight (rather than seven). The choice of omitting 7 from the predetermined valid length group of encoded data values ​​is made by examining all possible choices of 3 bit numbers, 8 choices per group. Since there are 9 options (bit lengths 0 to 8), one option is omitted. After evaluating all possibilities for a large test group of images (e.g., trying to omit 0, or 1, or 2...), it was confirmed that omitting "7" gave the best compression level. Note that the possibility of a data value having only one leading zero is small, because the color decorrelation and spatial decorrelation processes will cause the data values ​​to be biased towards zero.

[0445] It will be apparent that the examples described herein involve 8-bit data values, but in other examples, the data values ​​may include a different number of bits (e.g., 6-bit data values), and those skilled in the art will be able to modify the disclosure provided herein to operate using these different numbers of bits.

[0446] For example, if each data value received from the spatial decorrelation module has n bits, and the minimum number of significant bits determined for a particular group of received data values ​​is m, where m≤n, then each received data value of the particular group has at least (nm) leading zeros. In this case, each encoded data value of the particular group consists of the m least significant bits of the corresponding n-bit received data values ​​of the particular group. Referring to the same example as above, if the four n-bit data values ​​in a group (where n=8) are 00000011, 00000100, 00000001, and 00000000, then the minimum number of significant bits determined to represent the maximum value of the group is m=3. The 3-bit data length of each encoded data value is a valid encoding from the above table. Each data value has at least five leading zeros. Therefore, the m-bit encoded data values ​​of the group are 011, 100, 001, and 000.

[0447] Different groups within the block 2100 may be processed in parallel by the entropy coding module 2006. For example, indications of the different groups within the block 2100 may be determined and included in the size indication field 2114 in parallel operations within the entropy coding module 2006. However, because the encoded data values ​​may have variable lengths, they are included in the variable size field 2116 in a predetermined order.

[0448] When all the coded data values ​​of the block have been included in the coded data output 2110, the coded data output is output from the entropy coding module 2006 (box 2220). For each color channel, the coded data output representing the block of pixel values ​​is provided to the packaging module 2008, where they are packaged together. For example, the packaging module 2008 places the coded data outputs of the blocks of data values ​​from different color channels into a data packet. In other words, multiple coded data outputs are formed for corresponding multiple color channels associated with the same pixel, and the multiple coded data outputs for a group of pixels (e.g., 8x8 blocks) are packaged together into a data packet for storage. The coded data block can then be sent to the memory 106 for storage, for example, via the memory interface 114 (e.g., Figure 1 shown).

[0449] The header is stored with a set of coded data blocks, for example, a data block representing an image or frame. For each coded data block (e.g., each 8x8 block of coded data values), a header indication is included in the header to indicate the size of the compressed data for the corresponding coded data block. The header is stored separately from the coded data values ​​(e.g., in a dedicated portion of the coded data output), and due to its small size, a significant portion of the header data can reside in a cache within the GPU. The header allows the size of the coded data block to be known before retrieving the coded data block from memory, so that the coded data block can be retrieved without retrieving irrelevant data. This is very useful for allowing random access to different parts of the coded data. In general, any number of bits can be used in the header as a header indication for the corresponding coded data block, but in the specific example described below, four bits are used for each header indication.

[0450] As mentioned above, although the above reference Fig. 20A The methods described in 21A-B, 21A-B and 22 and the method described in UK Patent No. 2530312 are both inherently lossless, but if either method is used in conjunction with a lossy pre-processing step (e.g., when one or more bits from the fourth pseudo-channel are discarded, as described above with reference to Fig.14 or reference Fig.16 and 18A The resulting compressed data is no longer lossless.

[0451] Any references to specific logic gates above (eg, OR, AND gates, etc.) are by way of example only, and it should be understood that they may be replaced by logic elements that provide the same functionality and may be more broadly referred to as logic blocks.

[0452] The above description describes many different methods, including methods of data compression (e.g., Figure 2A -C, 3A, 4-11 and 19A), bit mapping methods (e.g. Figures 12A-12B ), including conversion from 10-bit to 8-bit formats (e.g. Fig.14 and 16 ). These methods can be used alone, or two or more of these methods can be used together in various combinations, and several examples are described above. Also described above are reverse operations (e.g., data compression, inverse mapping, and conversion from 8-bit to 10-bit format) and hardware for implementing any of these methods or any combination of these methods.

[0453] Fig.23A computer system is shown in which the data compression and decompression methods and apparatus described herein can be implemented. The computer system includes a CPU 2302, a GPU 2304, a memory 2306, and other devices 2314, such as a display 2316, a speaker 2318, and a camera 2320. A data compression and / or decompression block 2321 (which can implement any of the methods described herein) is implemented on the GPU 2304. In other examples, the data compression and / or decompression block 2321 can be implemented on the CPU 2302. The components of the computer system can communicate with each other via a communication bus 2322.

[0454] Figure 2A The data compression hardware of 1-C, 12B and 13B is shown as including multiple functional blocks. This is merely a schematic diagram and is not intended to define a strict division between the different logical elements of these entities. Each functional block may be provided in any suitable manner. It should be understood that the intermediate values ​​formed by the data compression hardware described herein need not be physically generated by the data compression hardware at any point in time, and may simply represent logical values ​​that conveniently describe the processing performed by the data compression hardware between its input and output.

[0455] The data compression and decompression hardware described herein (including any hardware arranged to implement any of the above methods) can be implemented in hardware on an integrated circuit. The data compression and decompression hardware described herein can be configured to perform any of the methods described herein. Generally, any of the above functions, methods, techniques or components can be implemented with software, firmware, hardware (e.g., fixed logic circuits) or any combination thereof. The terms "module", "function", "component", "element", "unit", "block" and "logic" may 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 that performs a specified task when the program code is executed on a processor. The algorithms and methods described herein can be performed by one or more processors that execute the code, and the code causes 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 memory devices that can use magnetic, optical and other technologies to store instructions or other data accessible by a machine.

[0456] 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 a machine language, an interpreted language, or a scripting language. Executable code includes binary code, machine code, byte code, code that defines an integrated circuit (e.g., a hardware description language or a netlist), and code expressed in a 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 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.

[0457] A processor, a computer or a computer system can be any kind of device, machine or special circuit, or a collection or part thereof, which has processing capabilities so that it can execute instructions. A processor can be any kind of general or special processor, such as a CPU, a GPU, a system on a chip, a state machine, a media processor, an application specific integrated circuit (ASIC), a programmable logic array, a field programmable gate array (FPGA), a physical processing unit (PPU), a radio processing unit (RPU), a digital signal processor (DSP), a general processor (such as a general GPU), a microprocessor, any processing unit intended to accelerate tasks outside the CPU, etc. A computer or computer system may include one or more processors. Those skilled in the art will recognize that this processing capability is incorporated into many different devices, so the term "computer" includes set-top boxes, media players, digital radios, PCs, servers, mobile phones, personal digital assistants, and many other devices.

[0458] The present invention is also intended to include software that defines hardware configurations as described herein, such as HDL (Hardware Description Language) software, for designing integrated circuits or for configuring programmable chips to perform desired functions. That is, a computer-readable storage medium may be provided on which is encoded 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 data compression and / or decompression hardware configured to perform any of the methods described herein, or to manufacture data compression and / or decompression hardware including any of the apparatus described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.

[0459] Thus, a method of manufacturing data compression and / or decompression hardware as described herein in an integrated circuit manufacturing system may be provided. In addition, an integrated circuit definition data set may be provided that, when processed in an integrated circuit manufacturing system, causes the method of manufacturing data compression and / or decompression hardware to be performed.

[0460] 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 any level of 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. A higher-level representation that logically defines the integrated circuit (e.g., RTL) may be processed on a computer system that is 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 on 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 for generating a manufacturing definition of the integrated circuit to execute code that defines the integrated circuit to generate a manufacturing definition of the integrated circuit.

[0461] Now refer to Fig.24 An example of processing an integrated circuit definition data set at an integrated circuit manufacturing system to configure the system to manufacture data compression and / or decompression hardware is described.

[0462] Fig.24 An example of an integrated circuit (IC) manufacturing system 2402 is shown, which is configured to manufacture data compression and / or decompression hardware as described in any of the examples herein. In particular, the IC manufacturing system 2402 includes a layout processing system 2404 and an integrated circuit generation system 2406. The IC manufacturing system 2402 is configured to receive an IC definition data set (e.g., defining data compression and / or decompression hardware as described in any of the examples herein), process the IC definition data set, and generate an IC (e.g., which embodies the data compression and / or decompression hardware as described in any of the examples herein) based on the IC definition data set. By processing the IC definition data set, the IC manufacturing system 2402 is configured to manufacture an integrated circuit that embodies the data compression and / or decompression hardware as described in any of the examples herein.

[0463] The layout processing system 2404 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, include synthesizing RTL code to determine a gate-level representation of a circuit to be generated, for example, in terms of logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining the location information of the logic components, the circuit layout can be determined based on the gate-level representation of the circuit. This can be done automatically or with user participation to optimize the circuit layout. When the layout processing system 2404 determines the circuit layout, it can output the circuit layout definition to the IC generation system 2406. The circuit layout definition can be, for example, a circuit layout description.

[0464] As is known in the art, IC generation system 2406 generates ICs according to the circuit layout definition. For example, IC generation system 2406 can implement a semiconductor device manufacturing process for generating ICs, which can include 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 the IC according to the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 2406 can be in the form of a computer readable code that the IC generation system 2406 can use to form a suitable photomask for generating the IC.

[0465] The different processes performed by IC manufacturing system 2402 can all be implemented in one location, for example, by one party. Alternatively, IC manufacturing system 2402 can be a distributed system such that some processes can be performed at different locations and can be performed by different parties. For example, some of the following stages: (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 photomask based on the circuit layout, and (iv) using the photomask to manufacture the integrated circuit can be performed at different locations and / or by different parties.

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

[0467] 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 an apparatus as described herein. Fig.24 The configuration of an integrated circuit manufacturing system is described in a manner that can manufacture the device described herein.

[0468] In some examples, the integrated circuit definition data set may include software that runs on, or in combination with, hardware defined by the data set. Fig.24 In the example shown, the IC generation system can be further 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.

[0469] Those skilled in the art will recognize that storage devices for storing program instructions can be distributed on a network. For example, a remote computer can store examples of processes described as software. A local or terminal computer can access the remote computer and download part or all of the software to run the program. Alternatively, a local computer can download fragments of software as needed, or execute some software instructions at a local terminal, and execute other software instructions at a remote computer (or computer network). Those skilled in the art will also recognize that, by utilizing conventional techniques known to those skilled in the art, all or part of the software instructions can be executed by a dedicated circuit such as a DSP, a programmable logic array, or the like.

[0470] 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 performed according to the common knowledge of a person skilled in the art based on the entirety of this specification, regardless of whether such feature or combination of features solves any problem disclosed herein. In view of the foregoing description, it will be apparent to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1. A method for lossy compressing data, comprising: Divide a pixel block into multiple sub-blocks; as well as For each sub-block: analyzing an alpha channel value of each pixel in the sub-block to select a lossy compression mode from a set of candidate lossy compression modes, wherein the set of candidate lossy compression modes includes two or more lossy compression modes, including at least one compression mode that uses a fixed alpha channel value for all pixels in the sub-block; as well as compressing the sub-blocks using the selected lossy compression mode; Analyzing the alpha channel value of each pixel in the sub-block to select a lossy compression mode from a set of candidate lossy compression modes comprises: Determine a minimum alpha channel value and a maximum alpha channel value according to the alpha channel values ​​of all the pixels in the sub-block; In response to determining that a difference between the maximum alpha channel value and the minimum alpha channel value is greater than a certain difference value, selecting a compression mode that uses variable alpha channel values ​​for the pixels in the sub-block; and In response to determining that the difference between the maximum alpha channel value and the minimum alpha channel value is not greater than the difference value, a compression mode that uses a fixed alpha channel value for all pixels in the sub-block is selected and the fixed alpha channel value is determined. The method according to claim 1 , wherein the difference value is a maximum error value.

3. The method of claim 1 , wherein determining the fixed alpha channel value comprises: In response to determining that the maximum alpha channel value is a maximum possible value, setting the fixed alpha channel value equal to the maximum alpha channel value; In response to determining that the minimum alpha channel value is zero, setting the fixed alpha channel value equal to zero; as well as In response to determining that the maximum alpha channel value is not a maximum possible value and the minimum alpha channel value is not zero, the fixed alpha channel value is set equal to an average of the alpha channel values ​​of all pixels in the sub-block.

4. The method of claim 1 , wherein compressing the sub-block using the selected lossy compression mode comprises, for a compression mode using a fixed alpha channel value for all pixels in the sub-block: for each of the pixels in the sub-block, converting each of a red channel value, a green channel value, and a blue channel value from 8 bits to 5 bits; and The 5-bit red, green, and blue channel values ​​and the fixed alpha channel value of the pixels in the sub-block are packed together to form compressed data for the sub-block.

5. The method of claim 1 , wherein compressing the sub-block using the selected lossy compression mode comprises, for a compression mode that uses variable alpha channel values ​​for the pixels in the sub-block: subdividing the sub-block into a plurality of mini-blocks; For each of the mini-blocks: Calculating the color difference value of each pixel pair in the mini-block; Compare the minimum color difference value with the threshold; as well as In response to determining that the minimum color difference value exceeds the threshold, converting pixel data of each pixel in the mini-block from a first format to a second format including a smaller number of bits than the first format; as well as In response to determining that the minimum color difference value does not exceed the threshold, based on the color difference value, select one of a plurality of encoding modes, determine two or three pixel values ​​for the selected encoding mode, assign one of the pixel values ​​to each pixel in the mini-block, and convert the pixel values ​​from the first format to a third format including fewer bits than the first format.

6. The method of claim 1 , wherein compressing the sub-block using the selected lossy compression mode comprises, for a compression mode using a fixed alpha channel value for all pixels in the sub-block: subdividing the sub-block into a plurality of mini-blocks; For each of the mini-blocks: Calculating the color difference value of each pixel pair in the mini-block; Compare the minimum color difference value with the threshold; as well as In response to determining that the minimum color difference value exceeds the threshold, converting pixel data of each pixel in the mini-block from a first format to a second format including a smaller number of bits than the first format; as well as In response to determining that the minimum color difference value does not exceed the threshold, based on the color difference value, select one of a plurality of encoding modes, determine two or three pixel values ​​for the selected encoding mode, assign one of the pixel values ​​to each pixel in the mini-block, and convert the pixel values ​​from the first format to a third format including fewer bits than the first format.

7. The method of claim 5, wherein selecting one of a plurality of encoding modes based on the color difference value, determining two or three pixel values ​​for the selected encoding mode, assigning one of the pixel values ​​to each pixel in the mini-block, and converting the pixel values ​​from the first format to a third format including a smaller number of bits than the first format comprises: Identify a pixel pair in the mini-block with minimal color difference, represent the pixel pair as a single new pixel value and a pixel pattern code identifying the pixel pair, and convert pixel data of the single new pixel value and pixel data of each other pixel in the mini-block except the identified pixel pair from the first format to a third format including a smaller number of bits than the first format.

8. A data decompression method, comprising: unpacking data from a compressed data block to generate a plurality of sub-blocks of compressed data; For each sub-block: identifying a compression mode from a block mode field within the compressed data block, wherein the compression mode is one of a set of candidate lossy compression modes, the set of candidate lossy compression modes comprising two or more lossy compression modes including at least one compression mode that uses a fixed alpha channel value for all pixels in the sub-block; as well as decompressing the sub-block using a decompression mode corresponding to the selected compression mode; The compression mode is selected from the set of candidate lossy compression modes by analyzing the alpha channel value of each pixel in the sub-block, including: Determine a minimum alpha channel value and a maximum alpha channel value according to the alpha channel values ​​of all the pixels in the sub-block; In response to determining that a difference between the maximum alpha channel value and the minimum alpha channel value is greater than a certain difference value, selecting a compression mode that uses variable alpha channel values ​​for the pixels in the sub-block; and In response to determining that the difference between the maximum alpha channel value and the minimum alpha channel value is not greater than the difference value, a compression mode that uses a fixed alpha channel value for all pixels in the sub-block is selected and the fixed alpha channel value is determined.

9. A data compression unit, comprising: hardware logic arranged to divide a pixel block into a plurality of sub-blocks; hardware logic arranged to, for each sub-block, analyze an alpha channel value of each pixel in the sub-block to select a lossy compression mode from a set of candidate lossy compression modes, wherein the set of candidate lossy compression modes includes two or more lossy compression modes including at least one compression mode that uses a fixed alpha channel value for all pixels in the sub-block; as well as a data compression element arranged to compress the sub-blocks using a selected lossy compression mode; Analyzing the alpha channel value of each pixel in the sub-block to select a lossy compression mode from a set of candidate lossy compression modes comprises: Determine a minimum alpha channel value and a maximum alpha channel value according to the alpha channel values ​​of all the pixels in the sub-block; In response to determining that a difference between the maximum alpha channel value and the minimum alpha channel value is greater than a certain difference value, selecting a compression mode that uses variable alpha channel values ​​for the pixels in the sub-block; and In response to determining that the difference between the maximum alpha channel value and the minimum alpha channel value is not greater than the difference value, a compression mode that uses a fixed alpha channel value for all pixels in the sub-block is selected and the fixed alpha channel value is determined.

10. A data decompression unit, comprising: hardware logic arranged to unpack data from a compressed data block to generate a plurality of sub-blocks of compressed data; hardware logic arranged to, for each sub-block, identify a compression mode from a block mode field within the compressed data block, wherein the compression mode is one of a set of candidate lossy compression modes, the set of candidate lossy compression modes comprising two or more lossy compression modes including at least one compression mode that uses a fixed alpha channel value for all pixels in the sub-block; and a data decompression element arranged to decompress the sub-blocks using a decompression mode corresponding to the selected lossy compression mode; The compression mode is selected from the set of candidate lossy compression modes by analyzing the alpha channel value of each pixel in the sub-block, including: Determine a minimum alpha channel value and a maximum alpha channel value according to the alpha channel values ​​of all the pixels in the sub-block; In response to determining that a difference between the maximum alpha channel value and the minimum alpha channel value is greater than a certain difference value, selecting a compression mode that uses variable alpha channel values ​​for the pixels in the sub-block; and In response to determining that the difference between the maximum alpha channel value and the minimum alpha channel value is not greater than the difference value, a compression mode that uses a fixed alpha channel value for all pixels in the sub-block is selected and the fixed alpha channel value is determined.

11. A computer program product comprising computer readable code, wherein: The computer readable code is configured to cause the method according to any one of claims 1 to 8 to be executed when executed.

12. A computer readable storage medium having encoded thereon the computer readable code of the computer program product according to claim 11.

13. A manufacturing method for manufacturing the data compression unit according to claim 9 using an integrated circuit manufacturing system.

14. A non-transitory computer readable storage medium having stored thereon a computer readable description of an integrated circuit, which, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture the data compression unit according to claim 9.

15. An integrated circuit manufacturing system configured to manufacture the data compression unit according to claim 9.

16. An integrated circuit manufacturing system comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of an integrated circuit, the computer-readable description describing the data compression unit according to claim 9; a layout processing system configured to process the integrated circuit description so as to generate a circuit layout description of an integrated circuit embodying the data compression unit; as well as An integrated circuit generation system is configured to manufacture the data compression unit according to the circuit layout description.

Images