Patent Description:
This application also claims priority to <CIT>.

Images are compressed for efficient storage, retrieval, and transmission. In general, there are two types of image compression, lossless compression and lossy compression. Lossless compression involves the preservation of the image without the loss of any information and therefore without the loss any details. Lossy compression allows loss of information during compression and therefore less than perfect reproduction of the original image. Lossy compression has higher levels of compression ratios because less information is needed to represent the compressed image.

The following document:
<NPL>
discloses the idea of rotating image blocks before performing the DCT (and after IDCT) to ensure that the edges (local directional features) are aligned with the horizontal/vertical directions. The DCT transform leads then to less non-null coefficients and, thus, to a higher compression. The rotation angle is derived by optimisation or as the main direction within a block.

The invention is defined by the computer-implemented methods of annexed independent claims <NUM> and <NUM>, by the computer-readable storage medium of independent claim <NUM> and by the computer system of independent claim <NUM>.

It should be noted that these Figures are intended to illustrate the general characteristics of methods, structure, or materials utilized in certain example implementations and to supplement the written description provided below. These drawings are not, however, to scale and may not precisely reflect the precise structural or performance characteristics of any given implementation, and should not be interpreted as defining or limiting the range of values or properties encompassed by example implementation.

During image compression, an image can be divided into pixel blocks (e.g., <NUM> x <NUM> pixel blocks or can be referred to as blocks or as blocks of pixel values). A discrete cosine transform (DCT) is applied to each of the blocks to convert information in the blocks from a spatial domain to a frequency domain. In the spatial domain, the values of pixels in an image change based on a location of a pixel in the image. The frequency domain deals with the frequency at which the values of the pixels in the image change and most of the values of pixels in the frequency domain have zero values resulting in higher compression ratio. The compression may further include quantizing information in the frequency domain to remove unnecessary information and performing entropy encoding to generate a compressed bit stream.

However, the compression mechanism described above may lead to technical problems when compressing images that have texture features that are not aligned (e.g., unaligned, not co-aligned, not parallel, etc.) with an axis (e.g., a horizontal axis, a vertical axis) of the image that is being compressed. Texture features may include natural or man-made objects, for example, a telephone wire, a brick wall, etc. During compression of an image with unaligned texture features, the above-described compression mechanism generates DCT coefficients that are mostly non-zero values resulting in lower compression ratios. In other words, if an image of a house contains a telephone wire that runs across the image such that the telephone wire is not aligned with an axis (e.g., a vertical or x-axis, or a horizontal or y-axis) of the image, the generated DCT coefficients are mostly non-zero values resulting in lower (e.g., inefficient) compression ratios (because non-zero need higher number of bits to represent them).

A proposed solution to this technical problem includes rotating (or geometrically transforming) texture features that are not aligned (e.g., non-parallel, misaligned, diagonally aligned, etc.) with at least an axis of the image to be aligned with at least an axis of the image before performing DCT. This results in generating DCT coefficients (of a block) with mostly zero values. The rotating also generates rotation (or geometrically transformation) values that are used for restoring the texture features to their original positions during decompression. The technical advantages of rotating prior to performing DCT include achieving better compression ratios, faster transmission, and/or higher decoding rates.

The proposed solution, which can be implemented in encoders and/or decoders, is more efficient because the rotating of texture features such that they are aligned with at least one axis of the image generates DCT coefficients that are mostly zeroes which achieves better compression ratios because compression mechanisms rely on reducing or removing redundant information (e.g., zero values) in an image during compression. For instance, in order for the compression mechanism to be effective, patterns (e.g., zeroes) in the data are identified and utilized. The probabilities associated with a likelihood of occurrence of a symbol (e.g., zeroes) are determined and symbols with a high probability of occurring are represented with a smaller number of bits and symbols with a low probability of occurring are represented with a greater number of bits. For example, the rotation of the texture features to be aligned with at least one axis of the image results in DCT values of mostly zeroes, where a value of zero maybe represented with a smaller number of bits resulting in higher compression ratios.

<FIG> illustrates an image <NUM> with various texture features. For example, <FIG> includes a model of a house with a texture feature <NUM>, e.g., a fence, which may be aligned with the y-axis (e.g., vertical axis) of the image. The alignment of the texture feature <NUM> can be compressed with a relatively high compression ratio because most of the DCT coefficients generated during the compression of the texture feature <NUM> are zero values.

In addition, <FIG> illustrates a texture feature <NUM>, e.g., a telephone wire, across the roof of the house. The texture feature <NUM> is not aligned with either x-axis (e.g., horizontal axis) or y-axis (e.g., vertical axis) of the image. This may result in generating DCT coefficients with mostly non-zero values during the compression of the texture feature <NUM> of the image <NUM> resulting in lower (or inefficient) compression ratios during the compression of the image <NUM>. In <FIG>, block <NUM> represents a block of pixels associated with the texture feature <NUM> that are compressed during the compression of the image <NUM>.

<FIG> is an example illustration <NUM> that shows a telephone wire <NUM> representing the texture feature <NUM>. As shown in <FIG>, the telephone wire is not aligned with either the x-axis or the y-axis of the image, but, is considered to be slanted (e.g., diagonal, oblique, etc.) relative to the horizontal and vertical axes of the image. Since, the telephone wire is not aligned with either x-axis or y-axis of the image, the DCT coefficients are mostly non-zero values result in lower compression ratios.

<FIG> illustrates an image <NUM> with the non-aligned texture features shown in <FIG> rotated, according to at least one example implementation. As shown in <FIG>, the texture feature <NUM> of <FIG> is rotated to a position represented by texture feature <NUM> such that the texture feature <NUM> is aligned with an axis of the image (e.g., x-axis in <FIG>). This rotation can allow for generation of DCT blocks with mostly zero values which can result in a relatively high compression ratio. The rotation may be also referred to as geometric transformation, geometric conversion, etc..

<FIG> is an example representation <NUM> that shows a telephone wire <NUM> representing texture feature <NUM>. As shown in <FIG>, the telephone wire <NUM> is rotated (or geometrically transformed) by angle of rotation <NUM> such that the texture feature is aligned with an axis of the image. The rotation (or geometric transformation) may involve rotating a texture feature about a fixed point to generate a rotated (or geometrically transformed) texture feature that is parallel to an axis of the image. In some implementations, for example, the rotation/geometric rotation may involve rotating the texture feature <NUM> about a fixed point (e.g., <NUM>) to generate the texture feature <NUM> such that the texture feature <NUM> is parallel to an axis (e.g., x-axis) of the image.

The rotation described above generates DCT blocks with mostly zero values which results in higher compression ratios. An example of such a DCT block that can be compressed with a high compression ratio is shown in at least, for example, <FIG>. The rotation (or geometric transformation) values for a row (or a column), e.g., row <NUM> of <FIG>, are stored during the compression as the row <NUM> is generated upon rotating of row <NUM> about x-axis.

Referring back to <FIG>, in some implementations, the rotation generates rotation values based on the angle of rotation <NUM>. The angle of rotation <NUM>, for example, may be determined such that the rotation is reduced or maintained at a minimum for the aligning the texture features with an axis of the image. For example, the rotation may be performed such that the texture feature <NUM> is aligned with the x-axis if the angle of rotation <NUM> is smaller than the angle of rotation for aligning the texture feature with the y-axis. This can result in managing the number of bits used to represent the rotation values (e.g., keeping the number of bits low). In some implementations, for example, the rotation may be performed such that the texture feature <NUM> is aligned with the y-axis if the angle of rotation about that y-axis is smaller than the angle of rotation for aligning the texture feature with the x-axis. This can result in managing (e.g., keeping the number of bits low) the number of bits used to represent the rotation values. In addition, in some implementations, for example, the rotation may be performed such that the texture feature <NUM> is aligned with another axis (e.g., z-axis or some other axis) if the angle of rotation for that axis is smaller.

In some implementations, the geometric transformation is performed on the pixels blocks of the image (e.g., block <NUM>). The geometric transformation is performed on the blocks associated with texture features that are not aligned with an axis of the image (e.g., texture features <NUM>). For example, texture feature <NUM>, after rotation or transformation, is illustrated by texture feature <NUM> with the angle of rotation shown by <NUM>. The geometric transformation generates geometric transformation values used by a decoder during the inverse geometric transformation for decompressing the image.

In some implementations, for example, a set of <NUM>-bits may be used to represent the rotation (or geometric transformation) values. This is just an example because any number of bits may be used to represent the rotation (or geometric transformation) values. The rotation (or geometric transformation) value may be stored and/or compressed with the rotated blocks and shared with the decoder. The rotation may be based on any type of geometric transform (e.g., affine transform, etc.) and the values that represent the rotation are stored and compressed during the encoding process as they are used during the decoding process. The geometric transformation is just one example and any type of transform (e.g., affine transform, etc.) may be used for rotating the texture features.

<FIG> illustrates a block diagram of an image processing system <NUM>, according to at least one example implementation. In some implementations, for example, an encoder <NUM> may perform pre-processing <NUM> and geometric transformation <NUM> of image <NUM> prior to performing compression <NUM> to compress the image <NUM> to generate a compressed bit stream <NUM>. <FIG> further illustrates performing inverse geometric transformation <NUM> and post-processing <NUM> after decompression <NUM> to decompress the compressed bit stream <NUM> to generate image <NUM>. The image <NUM> is generated with minimal loss (or no loss) in quality that is visible to a human eye.

<FIG> illustrates generalized compression and decompression mechanisms that can be applied to a variety of compression and decompression algorithms (or formats), for example, JPEG, WebP, Pik, etc. In some implementations, for example, the encoding/decoding mechanisms described below may be implemented for video as well. A more specific example of compression and decompression mechanisms are described below in detail in reference to <FIG>.

<FIG> illustrates a block diagram of an image processing system <NUM>, according to at least one example implementation. In some implementations, <FIG> illustrates compression of the image <NUM> by the encoder <NUM> to generate the compressed bit stream <NUM>. <FIG> further illustrates decompression of the compressed bit stream <NUM> by a decoder <NUM> to generate the image <NUM>, with minimal or no loss in quality.

As shown in <FIG>, the image <NUM> is compressed (or encoded) by an encoder <NUM>. The compression mechanism includes the pre-processing <NUM> which may include color space conversion <NUM>, geometric transformation <NUM>, and the compression <NUM> (which may include one or more of discrete cosine transform (DCT) <NUM>, quantization <NUM>, and entropy encoding <NUM>). The compression mechanism receives the input image <NUM> and generates a compressed bit stream <NUM> as output.

In some implementations, for example, the encoder <NUM> performs color space conversion <NUM> to convert the image <NUM> from one color space (e.g., RGB color space) to another color space (e.g., YCbCr color space) because compression in YCbCr color achieves higher compression ratios. The conversion from RGB color space to YCbCr color space includes converting RGB values of pixels in the image <NUM> to luminance (e.g., Y) and chrominance (e.g., Cb and Cr) values. A luminance value indicates brightness of a pixel and chrominance values indicate blue and red values. The conversion to YCbCr color space is just one example and any other color space conversion with compression ratios similar to YCbCr may be used. In some implementations, for example, either before or after the color space conversion <NUM>, the encoder <NUM> may convert the pixels in the image <NUM> into blocks <NUM> (e.g., <NUM> x <NUM> block) as part of the compression mechanism. The blocks may be of any size (e.g., <NUM> x <NUM> blocks in some example implementation).

The encoder <NUM> performs geometric transformation <NUM> on the blocks <NUM> (e.g., on the pixels of the blocks). In some implementations, for example, the geometric transformation <NUM> may be performed on the blocks (e.g., block <NUM>) associated with texture features (e.g., texture features <NUM>) that are not co-aligned with either axes of the image (e.g., image <NUM>). The encoder <NUM> may determine a rotation (or transformation) that allows the texture features <NUM> to be co-aligned with either axes of the image, as illustrated in <FIG>. For example, texture features <NUM> after rotation are illustrated by texture features <NUM> with the angle of rotation <NUM>. The performing of the geometric transformation <NUM> generates rotation values that are used by the decoder <NUM> during the inverse geometric transformation <NUM>. In some implementations, the geometric transformation values may be stored, quantized, and/or entropy encoded as part of <NUM>.

The rotation may be performed to allow the texture features that are not co-aligned (e.g., are non-parallel) with at least one axis of the image to be co-aligned (e.g., are parallel) with at least one axis of the image to make the representation of the texture features less expensive (e.g., using a lower number of bits). The rotation may be based on any type of geometric transformation (e.g., affine transform, etc.) and the values that represent the rotation are stored and compressed during the encoding process as they are used during the decoding process, for example, during inverse geometric transformation <NUM>.

For example, in some implementations, geometric transformation may include rotating an object (e.g., texture feature (e.g., texture feature <NUM>) by a center of rotation (e.g., <NUM>) and by an angle of rotation (e.g. <NUM>) such that the non-parallel texture feature <NUM> is parallel to a x-axis or y-axis of the image. In some implementation, inverse geometric transformation may include restoring the geometrically transformed pixel values to their pre-rotation values so that the decompressed image can accurately depict the decompressed texture features.

In some implementations, the rotation values are stored on a tile basis. The tile may be of any size, and in some implementations, the size of the tile is <NUM> x <NUM> pixels (vs the size of a block which may be <NUM> x <NUM> pixels in some implementations). In addition, the four corners of a tile may be used to identify the location of the tile in the image during the decoding process such that they are mapped accordingly. Although the pixels in the image are compressed on a block basis (e.g., <NUM> x <NUM> pixels), the rotation values are stored on a tile basis (e.g., <NUM> x <NUM> pixels) to reduce the number of bits needed to store the rotation values.

Referring back to <FIG>, the encoder <NUM> performs discrete cosine transform (DCT) <NUM>, for example, on each of the blocks. The DCT <NUM> transforms the values of the pixels in the blocks from the spatial domain to DCT coefficients in the frequency domain, as described above, and further described in detail in connection with at least <FIG>, <FIG>, and <FIG>.

Referring to <FIG>, a matrix <NUM> represents texture features (e.g., texture feature <NUM> of <FIG>) that are aligned with the x-axis of the image (e.g., <NUM> of <FIG> or <NUM> of <FIG>). In <FIG>, the texture features <NUM> correspond to row <NUM> (<NUM>) of the matrix <NUM> and with pixel values of <NUM>. A pixel value of <NUM> represents a full pixel (and a pixel value of <NUM> represents a half-filled pixel). The encoder <NUM> performs DCT <NUM> on the matrix <NUM> and generates a DCT matrix <NUM> which includes two-dimensional DCT coefficients of the texture features <NUM>. For example, the DCT matrix <NUM> has non-zero values in the first column <NUM> and zero values in the other columns. The zero values, for example, in columns <NUM>-<NUM> of the DCT matrix <NUM>, achieves higher compression ratios during the quantization <NUM> and entropy decoding <NUM>, described below in detail.

However, <FIG> illustrates a matrix <NUM> that represents the texture features <NUM> that are not aligned with either x-axis or y-axis of the image (e.g., <NUM> of <FIG> or <NUM> of <FIG>). The pixel values of the texture features <NUM> are illustrated by pixel values highlighted in bold in the matrix <NUM>. As illustrated by the values in bold, the pixels with non-zero values are spread over the matrix <NUM>. The encoder <NUM> performs the DCT <NUM> on the matrix <NUM> and generates a matrix <NUM> of <FIG> which includes two-dimensional DCT coefficients of the texture features <NUM>. As shown in the matrix <NUM> of <FIG>, the DCT matrix <NUM> contains mostly non-zero values (e.g., relative to the matrix <NUM> of <FIG> associated with the texture features <NUM> of <FIG>) and are spread all over the matrix <NUM> (for instance, not limited to just one row or a column). The non-zero values spread out over multiple rows/columns of the DCT matrix <NUM> results in lower compression ratios.

In some implementations, because of the rotation being performed prior to the compression on blocks associated with the texture features that are not co-aligned with either axes of the image <NUM> (e.g., texture features <NUM>), the DCT matrix generated based on the geometric transformation <NUM> is shown by DCT matrix <NUM> of <FIG>. As illustrated in <FIG>, row <NUM> (<NUM>) of the DCT matrix <NUM> has non-zero values and all other rows have zero values. This achieves higher compression ratios (when compared to matrix <NUM> of <FIG>). Although, the rotation values have to be encoded and/or transmitted for the decoder to properly decode the compressed bit stream <NUM> and generate the image <NUM>, the benefits (e.g., reduction in the number of bits) of higher compression ratios outweigh the burden associated with the extra number of bits needed for representing rotating values.

Referring back to <FIG>, the encoder <NUM> performs quantization <NUM> to quantize the DCT coefficients <NUM> and generate quantized DCT coefficients <NUM>. The quantization process maps values within a relatively large range to values in a relatively small range and thus reducing the amount of data needed to represent the quantized DCT coefficients <NUM>. During the quantization <NUM>, many higher DCT coefficients are zeroed out for better compression ratios.

The encoder <NUM> further performs entropy encoding <NUM> to entropy encode the matrices. During entropy encoding, the values in the top left of the matrices are given relatively higher importance and the values in the right and/or bottom (to the DC coefficient) are given relatively lower importance and are encoded in a zig-zag pattern. This results in cells with zero values appearing at the end of the zig-zag pattern and therefore efficiently compressed. After encoding all the blocks that correspond to the image <NUM>, the encoder <NUM> generates a compressed bit stream <NUM> (e.g., a compressed or encoded image).

The decoder <NUM>, upon receiving the compressed bit stream <NUM> performs a decoding process to decompress the compressed bit stream <NUM> and generate image <NUM>. The image <NUM> may be similar to the image <NUM>, with very minimal or no loss in quality. The decompression process includes one or more of entropy decoding <NUM>, dequantization <NUM>, inverse discrete cosine transform (IDCT) <NUM>, inverse geometric transformation <NUM>, and inverse color space conversion <NUM>. The decompression process generates the image <NUM>.

In some implementations, for example, the decoder <NUM> performs entropy decoding <NUM> of the compressed bit stream <NUM> and generates quantized DCT coefficients <NUM>. The decoder <NUM> further performs dequantization <NUM> of the quantized DCT coefficients <NUM> and generates DCT coefficients <NUM>. For example, one DC coefficient and <NUM> AC coefficients may be generated for each block upon the dequantization <NUM>. The decoder <NUM> further performs an inverse discrete cosine transform (IDCT) <NUM> on the quantized DCT coefficients <NUM> and generates geometrically transformed pixel values <NUM>. The geometrically transformed pixel values <NUM> may be used for generating the image <NUM>.

The image <NUM> generated from geometrically transformed pixel values <NUM> may include features that are rotated. Therefore, the decoder <NUM>, in some implementations, for example, performs inverse geometric transformation <NUM> on the geometrically transformed pixel values <NUM> and generates pixel values <NUM>. The decoder <NUM> use the rotation or geometric transformation values received from the encoder to perform the inverse geometric transformation <NUM> such that the texture features can be restored to their original position. For example, in some example implementation, upon performing the inverse geometric transformation <NUM>, the texture features <NUM> will be restored to their original position <NUM>. The decoder <NUM> performs inverse color space conversion <NUM> to convert the pixel values from the second color space (e.g., YCbCr) to the first color space (e.g., RGB) and outputs the pixel values in RGB color space <NUM> which the decoder uses to generate the image <NUM> for displaying (e.g., on a device, in a browser, in an application, etc.).

As described above, the compression of images that include texture features that are not aligned with either axis of the image being compressed may be improved by rotating/geometrically transforming such texture features to be aligned with one of the axes of the image being compressed. This achieves better compression ratios and/or can result in an improvement in user experience.

In some implementations, for example, the image <NUM> may be further refined during the decoding the process. For example, the decoder <NUM> may perform entropy decoding, dequantization, IDCT, inverse geometric transformation, full-image regularization, de-blocking, and detailing, geometric transformation, DCT, constraining regularized and de-blocked DCT coefficients with possible values ranges defined by dequantization, IDCT, inverse geometric transformation, and inverse color space conversion to generate the decompressed images to further improve the quality of the image <NUM>.

<FIG> illustrates a block diagram of an encoder system <NUM>, according to at least one example implementation.

The encoder system <NUM> may be understood to include various standard components which may be utilized to implement the techniques described herein, or different or future versions thereof. As shown in <FIG>, the encoder system <NUM> includes the at least one processor <NUM>, the at least one memory <NUM> (e.g., a computer readable storage medium), a controller <NUM>, and an encoder <NUM>. The at least one processor <NUM>, the at least one memory <NUM>, the controller <NUM>, and the encoder <NUM> are communicatively coupled via bus <NUM>.

The at least one processor <NUM> may be configured to execute computer instructions associated with the controller <NUM> and/or the encoder <NUM>. The at least one processor <NUM> may be a shared resource. For example, the encoder system <NUM> may be an element of a larger system.

The at least one memory <NUM> may be configured to store data and/or information associated with the encoder system <NUM>. For example, the at least one memory <NUM> may be configured to store buffers including, for example, buffers storing geometric data, portions of the geometric data, positions of data points in the geometric data, a number of data points associated with a portion of the geometric data, geometric transformation values, and/or the like. For example, the at least one memory <NUM> may be configured to store models, training algorithms, parameters, data stores, and the like.

The controller <NUM> may be configured to generate various control signals and communicate the control signals to various blocks in encoder system <NUM>. The controller <NUM> may be configured to generate the control signals in accordance with the method described below. The controller <NUM> may be configured to control the encoder <NUM> to encode geometric data using a model according to example implementations as described herein. For example, the controller <NUM> may generate and communicate a control signal(s) indicating a model and/or parameter associated with the model.

<FIG> illustrates a block diagram of a decoder system <NUM>, according to at least one example implementation.

In the example of <FIG>, a decoder system <NUM> may be at least one computing device and should be understood to represent virtually any computing device configured to perform the methods described herein. As such, the decoder system <NUM> may be understood to include various standard components which may be utilized to implement the techniques described herein, or different or future versions thereof. By way of example, the decoder system <NUM> is illustrated as including at least one processor <NUM>, as well as at least one memory <NUM> (e.g., a computer readable storage medium), a controller <NUM>, and a decoder <NUM>. The at least one processor <NUM>, the at least one memory <NUM>, the controller <NUM>, and the decoder <NUM> are communicatively coupled via bus <NUM>.

The at least one processor <NUM> may be configured to execute computer instructions associated with the controller <NUM> and/or the decoder <NUM>. The at least one processor <NUM> may be a shared resource. For example, the decoder system <NUM> may be an element of a larger system (e.g., a mobile device). Therefore, the at least one processor <NUM> may be configured to execute computer instructions associated with other elements (e.g., web browsing or wireless communication) within the larger system.

The at least one memory <NUM> may be configured to store data and/or information associated with the decoder system <NUM>. For example, the at least one memory <NUM> may be configured to store a model and parameters associated with the geometric data, and/or the like.

The controller <NUM> may be configured to generate various control signals and communicate the control signals to various blocks in decoder system <NUM>. The controller <NUM> may be configured to generate the control signals in accordance with the methods described below. The controller <NUM> may be configured to control the decoder <NUM> to decode compressed data associated with geometric data using a model and parameters according to example implementations as described above.

The method steps described with regard to <FIG> may be executed as software code stored in a memory (e.g., at least one memory <NUM>, <NUM>) associated with an encoder and/or decoder system (e.g., as shown in <FIG>) and executed by at least one processor (e.g., processor <NUM>, <NUM>) associated with the encoder and/or decoder system. For example, the memory can be a non-transitory computer-readable storage medium having storing computer executable program code which, when executed on a computer system, causes the computer system to perform steps described below with regard to <FIG>. However, alternative implementations are contemplated such as an encoder or a decoder embodied as a special purpose processor.

For example, the method steps may be performed by an application-specific integrated circuit, or ASIC. For example, the ASIC may be configured as the encoder <NUM>, the decoder <NUM>, and/or the controller <NUM>/<NUM>. Although the steps described below are described as being executed by a processor, the steps are not necessarily executed by a same processor. In other words, at least one processor may execute the steps described below with regard to <FIG>.

<FIG> illustrates a flowchart <NUM> of a method of decompressing or decoding an image, according to at least one example implementation. In some implementations, for example, the method may be performed by decoder of <FIG>, <FIG>, and <FIG>.

At block <NUM>, a decoder may receive a block of geometrically transformed pixel values. In some implementations, the decoder <NUM> may receive a block of geometrically transformed pixel values (e.g., <NUM> of <FIG>).

At block <NUM>, a decoder may perform inverse geometric transformation on a block of geometrically transformed pixel values to generate a block of pixel values. For example, in some implementations, the decoder <NUM> and/or the inverse geometric transform component <NUM> may perform inverse geometric transformation <NUM> on a block of geometrically transformed pixel values <NUM> to generate a block of pixel values <NUM>. The block of pixel values <NUM> represent texture features (e.g., texture feature <NUM>) of the image <NUM> that are not co-aligned with either x-axis or y-axis of the image <NUM>. The decoder <NUM> and/or the inverse geometric transformation component <NUM> perform the inverse geometric transformation on a block basis and the block being one of the blocks of the image <NUM>.

At block <NUM>, the decoder may generate at least a portion of the image based on the first block of pixel values. For example, in some implementations, the decoder <NUM> may generate at least a portion of the image <NUM> based on the first block of pixel values <NUM>.

Thus, the decompression of an image that includes texture features that are not co-aligned with either axes of the image can be performed such that the achieved compression ratios of the image is better by rotating or geometrically transforming the texture features to be co-aligned with one of the axes of the image. This mechanism will make the transmission of images faster and improve the end user experience during the decompression process.

<FIG> shows an example of a computer device <NUM> and a mobile computer device <NUM>, which may be used with the techniques described here. Computing device <NUM> is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Computing device <NUM> is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart phones, and other similar computing devices.

In some implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory.

In some implementations, the storage device <NUM> may be or contain a computer-readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid-state memory device, or an array of devices, including devices in a storage area network or other configurations. The computer program product can be tangibly embodied in an information carrier.

The high-speed controller <NUM> manages bandwidth-intensive operations for the computing device <NUM>, while the low speed controller <NUM> manages lower bandwidth-intensive operations. In some implementations, the high-speed controller <NUM> is coupled to memory <NUM>, display <NUM> (e.g., through a graphics processor or accelerator), and to high-speed expansion ports <NUM>, which may accept various expansion cards (not shown).

Each of the components <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate.

In addition, an external interface <NUM> may be provide in communication with processor <NUM>, to enable near area communication of device <NUM> with other devices. External interface <NUM> may provide, for example, for wired communication in some implementations, or for wireless communication in some implementations, and multiple interfaces may also be used.

In some implementations, a computer program product is tangibly embodied in an information carrier.

In addition, short-range communication may occur, such as using a Bluetooth, Wi-Fi, or other such transceiver (not shown).

These various implementations can include implementation In some or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. Various implementations of the systems and techniques described here can be realized as and/or generally be referred to herein as a circuit, a module, a block, or a system that can combine software and hardware aspects. For example, a module may include the functions/acts/computer program instructions executing on a processor (e.g., a processor formed on a silicon substrate, a GaAs substrate, and the like) or some other programmable data processing apparatus.

Some of the above example implementations are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations as sequential processes, many of the operations may be performed in parallel, concurrently or simultaneously. In addition, the order of operations may be rearranged. The processes may be terminated when their operations are completed, but may also have additional steps not included in the figure. The processes may correspond to methods, functions, procedures, subroutines, subprograms, etc..

Methods discussed above, some of which are illustrated by the flow charts, may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a storage medium.

Specific structural and functional details disclosed herein are merely representative for purposes of describing example implementations. Example implementations, however, be embodied in many alternate forms and should not be construed as limited to only the implementations set forth herein.

For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element. As used herein, the term and/or includes any and all combinations of one or more of the associated listed items.

It will be understood that when an element is referred to as being connected or coupled to another element, it can be directly connected or coupled to the other element or intervening elements may be present. In contrast, when an element is referred to as being directly connected or directly coupled to another element, there are no intervening elements present. Other words used to describe the relationship between elements should be interpreted in a like fashion (e.g., between versus directly between, adjacent versus directly adjacent, etc.).

The terminology used herein is for the purpose of describing particular implementations s only and is not intended to be limiting of example implementations. As used herein, the singular forms a, an, and the are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms comprises, comprising, includes and/or including, when used herein, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.

For example, two figures shown in succession may in fact be executed concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which example implementations belong.

Portions of the above example implementations and corresponding detailed description are presented in terms of software, or algorithms and symbolic representations of operation on data bits within a computer memory. These descriptions and representations are the ones by which those of ordinary skill in the art effectively convey the substance of their work to others of ordinary skill in the art. An algorithm, as the term is used here, and as it is used generally, is conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of optical, electrical, or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

In the above illustrative implementations, reference to acts and symbolic representations of operations (e.g., in the form of flowcharts) that may be implemented as program modules or functional processes include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types and may be described and/or implemented using existing hardware at existing structural elements. Such existing hardware may include one or more Central Processing Units (CPUs), digital signal processors (DSPs), application-specific-integrated-circuits, field programmable gate arrays (FPGAs) computers or the like.

Unless specifically stated otherwise, or as is apparent from the discussion, terms such as processing or computing or calculating or determining of displaying or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical, electronic quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Note also that the software implemented aspects of the example implementations are typically encoded on some form of non-transitory program storage medium or implemented over some type of transmission medium. The program storage medium may be magnetic (e.g., a floppy disk or a hard drive) or optical (e.g., a compact disk read only memory, or CD ROM), and may be read only or random access. Similarly, the transmission medium may be twisted wire pairs, coaxial cable, optical fiber, or some other suitable transmission medium known to the art. The example implementations not limited by these aspects of any given implementation.

Claim 1:
A computer-implemented method, comprising:
receiving (<NUM>), by a decoder, a compressed bit stream of an image;
performing, by the decoder, entropy decoding (<NUM>) on the compressed bit stream of the image to generate a block of quantized DCT coefficients;
performing, by the decoder, dequantization (<NUM>) on the block of quantized DCT coefficients to generate a block of dequantized DCT coefficients;
performing (<NUM>), by the decoder, inverse discrete cosine transform, IDCT, (<NUM>) on the block of dequantized DCT coefficients to generate a block of transformed pixel values, wherein the block of transformed pixel values have been transformed by an affine transformation such that texture features are parallel with the horizontal or vertical axis of the image;
performing, by the decoder, an inverse affine transformation (<NUM>) on the block of transformed pixel values to generate a first block of pixel values, the transformed pixel values representing the texture features of an image that are non-parallel with a vertical axis or a horizontal axis of the image, and the first block of pixel values being one of a plurality of blocks of the image;
generating (<NUM>), by the decoder, at least a portion of the image based on the first block of pixel values;
wherein performing the inverse affine transformation includes performing the inverse affine transformation using affine transformation values,
characterized in that
the affine transformation values are included in the compressed bit stream on a tile basis.