Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 29 is objected to because of the following informalities:
Claim 29 depends on claim 1 and claims the at least one interleaved texture. However, an interleaved texture is not previously defined in claim 1 and lacks antecedent basis.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-7, 11-18, 21-26, 30-43, 46-49 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wihlidal (US 20200051287, hereinafter “Wih”) in view of Garigapati (“Pyramid Level Lossy Image Compression preserving Crucial Details, Things to Know,” hereinafter “Gar”).
Re claim 1, Wih teaches a method, comprising:
at a device: (see abstract: a computer implemented method).
transcoding by at least one neural network at least a portion of a single texture representation ([0003] In accordance with a first aspect, this specification describes a computer-implemented method, comprising: receiving a texture map; segmenting the texture map into a plurality of pixel regions, and for each of the plurality of pixel regions: inputting a vector representation of the pixel region to a compression parameter neural network, wherein the compression parameter neural network is configured to: process the vector representation of the pixel region through one or more layers of the compression parameter neural network; and generate an output indicating a compression parameter set for compressing the pixel region. The method further comprises inputting the pixel region and the compression parameter set to a compressor, wherein the compressor is configured to compress the pixel region to a compressed representation of the pixel region in accordance with the compression parameter set. The method further comprises storing a compressed representation of the texture map to a memory accessible by a graphics processing unit, wherein storing the compressed representation of the texture map comprises storing the compressed representations of each of the pixel regions to said memory, and selectively decompressing portions of the compressed representation of the texture map using the graphics processing unit)
into at least a portion of the textures with a hardware-supported compression format ([0003] In accordance with a first aspect, this specification describes a computer-implemented method, comprising: receiving a texture map; segmenting the texture map into a plurality of pixel regions, and for each of the plurality of pixel regions: inputting a vector representation of the pixel region to a compression parameter neural network, wherein the compression parameter neural network is configured to: process the vector representation of the pixel region through one or more layers of the compression parameter neural network; and generate an output indicating a compression parameter set for compressing the pixel region. The method further comprises inputting the pixel region and the compression parameter set to a compressor, wherein the compressor is configured to compress the pixel region to a compressed representation of the pixel region in accordance with the compression parameter set. The method further comprises storing a compressed representation of the texture map to a memory accessible by a graphics processing unit, wherein storing the compressed representation of the texture map comprises storing the compressed representations of each of the pixel regions to said memory, and selectively decompressing portions of the compressed representation of the texture map using the graphics processing unit) and ([0039] In step 240, the current pixel region is compressed to an appropriate compression format and stored to memory accessible by the GPU. The compression to the appropriate compression format includes determining appropriate compression parameters using the compression parameter neural network. The compression format may be BC7 or BC6H, or another suitable compression format such as ASTC. An example method by which compression and storage of the pixel region may be performed is illustrated in FIG. 3. Execution then returns to step 230).
and outputting the at least a portion of the of textures with the hardware-supported compression format ([0003] In accordance with a first aspect, this specification describes a computer-implemented method, comprising: receiving a texture map; segmenting the texture map into a plurality of pixel regions, and for each of the plurality of pixel regions: inputting a vector representation of the pixel region to a compression parameter neural network, wherein the compression parameter neural network is configured to: process the vector representation of the pixel region through one or more layers of the compression parameter neural network; and generate an output indicating a compression parameter set for compressing the pixel region. The method further comprises inputting the pixel region and the compression parameter set to a compressor, wherein the compressor is configured to compress the pixel region to a compressed representation of the pixel region in accordance with the compression parameter set. The method further comprises storing a compressed representation of the texture map to a memory accessible by a graphics processing unit, wherein storing the compressed representation of the texture map comprises storing the compressed representations of each of the pixel regions to said memory, and selectively decompressing portions of the compressed representation of the texture map using the graphics processing unit). Wih teaches outputting at least a portion of textures with hardware supported compression format (stored compressed representation of each pixel region to memory that is supports graphics processing unit).
Wih does not explicitly teach wherein the single texture representation is of a plurality of textures in a set of textures and transcoding into at least a portion of the plurality of textures
However, Gar teaches wherein the single texture representation is of a plurality of textures in a set of textures (see images on p. 2-5, wherein a single texture representation is shown as an input image that represents the plurality of textures in a set of texture levels of detail).
and transcoding into at least a portion of the plurality of textures (see figures on p. 2-5, wherein the single texture representation is transcoded into at least a portion of a plurality of levels of texture, such as a pyramid of feature levels of grids, as shown on p. 2).
Wih and Gar teaches 1. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wih’s image-based compression system to explicitly include a single texture representation is of a plurality of textures in a set of textures, as taught by Gar, as the references are in the analogous art of image-based neural network compression. An advantage of the modification is that it achieves the result of allowing for varying levels of image compression within a multi-level image pyramid structure of feature levels.
Re claim 2, Wih and Gar teaches claim 1. Furthermore, Gar teaches wherein the single texture representation is a compressed representation of the plurality of textures included in the set of textures (see p. 3 and 4, pyramid wherein a single texture representation is a compressed representation of a plurality of image/texture representations in the set). For motivation, see claim 1.
Re claim 3, Wih and Gar teaches claim 2. Furthermore, Gar teaches wherein the compressed representation is generated using at least one compression method (see p. 2, “There are a ton of image compression algorithms in use, like DCT, JPG, HEIF and etcetera which can perform lossy image compressions by ignoring the high frequency components of image), (p. 5, From the laplacian pyramid, drop off some details in the intended layer. We can do this by using a lossy compression where we control the amount of quality drop. JPEG is a good example for this kinda usecase. Not only JPEG, but we can do multiple experiments by using multiple image compression techniques…), (and see 5-7, using naïve cv2’s resize as the lossy compression technique and using pixel value quantization as the lossy compression technique). For motivation, see claim 1.
Re claim 4, Wih and Gar teaches claim 2. Furthermore, Gar teaches wherein the compressed representation is generated using at least two compression techniques (see p. 2, “There are a ton of image compression algorithms in use, like DCT, JPG, HEIF and etcetera which can perform lossy image compressions by ignoring the high frequency components of image), (p. 5, From the laplacian pyramid, drop off some details in the intended layer. We can do this by using a lossy compression where we control the amount of quality drop. JPEG is a good example for this kinda usecase. Not only JPEG, but we can do multiple experiments by using multiple image compression techniques…), (and see 5-7, using naïve cv2’s resize as the lossy compression technique and using pixel value quantization as the lossy compression technique). For motivation, see claim 1.
Re claim 5, Wih and Gar teaches claim 1. Furthermore, Gar teaches wherein the single texture representation is learned using a neural network (See p.4-5, “In this post, I will be using the CNN for the same purpose: To evaluate the recognisability of a subject(cat or dog / car or plane) during compression process….” And compression model and compression algorithm, wherein a neural network is used to learn a texture representation). For motivation, see claim 1.
Re claim 6, Wih and Gar teaches claim 5. Furthermore, Wih teaches wherein the single texture representation is further generated by applying an entropy encoding to an output of the neural network ([0028] The compression parameter neural network 166 is a neural network for generating compression parameters based on the vector representations of the pixel region. In some implementations the neural network may comprise a feedforward neural network having a softmax output layer. The neural network may be trained based on a cross entropy loss function, as described in more detail below. The neural network may receive a vector representation of the pixel region as an input, processes the received input through one or more layers of the neural network, and outputs a vector from which a corresponding set of compression parameters may be determined. The output vector may comprise a number of elements with each element having a value giving a probability that a compression parameter set represented by that element is an optimal parameter set (as estimated by the network). The compression parameter set corresponding to the element with the highest probability may then be selected for compressing the pixel region to texture compression format. The compression parameter set includes one or more compression parameters, which may for example indicate a compression mode, partition bits and/or rotation bits) and ([0063] The loss measure to be minimised may be any suitable loss measure. Examples of suitable loss measures, also known as loss functions, include cross entropy loss, logistic loss and square loss. In this context, the values of the loss measure may be determined based on the probability assigned to the correct set of parameters, or the vector element relating thereto, by the neural network, and optionally, the probabilities that the network assigns to incorrect sets of parameters. For example, in the case of cross entropy loss, the loss measure would be… the weights may then be updated using this loss measure using a method including backpropagation).
Re claim 7, Wih and Gar teaches claim 1. Furthermore, Gar teaches wherein the single texture representation is a pyramid of a plurality of feature levels, wherein each feature level of the plurality of feature levels includes a plurality of grids (see pyramid on p. 2, wherein different feature levels are shown with grids). For motivation, see claim 1.
Re claim 11, Wih and Gar teaches claim 1. Furthermore, Wih teaches wherein the hardware-supported compression formation is a block compression format ([0002] Modern texture block compression formats, such as BC7 and BC6H, achieve high-quality image data compression by providing a wide range of compression modes and compressing each pixel block with the most appropriate mode. The resulting compressed data may be stored on a persistent storage device where it can be quickly accessed as needed by applications).
Re claim 12, Wih and Gar teaches claim 11. Furthermore Wih teaches wherein the block compression format is a BCx format ([0039] In step 240, the current pixel region is compressed to an appropriate compression format and stored to memory accessible by the GPU. The compression to the appropriate compression format includes determining appropriate compression parameters using the compression parameter neural network. The compression format may be BC7 or BC6H, or another suitable compression format such as ASTC. An example method by which compression and storage of the pixel region may be performed is illustrated in FIG. 3. Execution then returns to step 230).
Re claim 13, Wih and Gar teaches claim 11. Furthermore, Wih teaches wherein the block compression format is one of an ETCx format or an ASTC format ([0039] In step 240, the current pixel region is compressed to an appropriate compression format and stored to memory accessible by the GPU. The compression to the appropriate compression format includes determining appropriate compression parameters using the compression parameter neural network. The compression format may be BC7 or BC6H, or another suitable compression format such as ASTC. An example method by which compression and storage of the pixel region may be performed is illustrated in FIG. 3. Execution then returns to step 230).
Re claim 14, Wih and Gar teaches claim 1. Furthermore, Wih teaches wherein the transcoding is performed at load time when loading graphics data to memory for use by processing unit during rendering ([0003] In accordance with a first aspect, this specification describes a computer-implemented method, comprising: receiving a texture map; segmenting the texture map into a plurality of pixel regions, and for each of the plurality of pixel regions: inputting a vector representation of the pixel region to a compression parameter neural network, wherein the compression parameter neural network is configured to: process the vector representation of the pixel region through one or more layers of the compression parameter neural network; and generate an output indicating a compression parameter set for compressing the pixel region. The method further comprises inputting the pixel region and the compression parameter set to a compressor, wherein the compressor is configured to compress the pixel region to a compressed representation of the pixel region in accordance with the compression parameter set. The method further comprises storing a compressed representation of the texture map to a memory accessible by a graphics processing unit, wherein storing the compressed representation of the texture map comprises storing the compressed representations of each of the pixel regions to said memory, and selectively decompressing portions of the compressed representation of the texture map using the graphics processing unit) and ([0032] When one or more instructions of the game executable 132 requiring a portion of the texture map to be used for rendering is executed, the compressed texture 174 is loaded into the RAM 181 of the GPU 180 so that the GPU 180 can perform the requested rendering. It should be noted that the compressed texture 174 is significantly smaller than the uncompressed representation but is larger than the compressed image 134, since each of the regions of the texture map is compressed to a fixed number of bits).
Re claim 15, Wih and Gar teaches claim 14. Furthermore, Wih teaches wherein an entirety of the single texture representation is transcoded at load time ([0003] In accordance with a first aspect, this specification describes a computer-implemented method, comprising: receiving a texture map; segmenting the texture map into a plurality of pixel regions, and for each of the plurality of pixel regions: inputting a vector representation of the pixel region to a compression parameter neural network, wherein the compression parameter neural network is configured to: process the vector representation of the pixel region through one or more layers of the compression parameter neural network; and generate an output indicating a compression parameter set for compressing the pixel region. The method further comprises inputting the pixel region and the compression parameter set to a compressor, wherein the compressor is configured to compress the pixel region to a compressed representation of the pixel region in accordance with the compression parameter set. The method further comprises storing a compressed representation of the texture map to a memory accessible by a graphics processing unit, wherein storing the compressed representation of the texture map comprises storing the compressed representations of each of the pixel regions to said memory, and selectively decompressing portions of the compressed representation of the texture map using the graphics processing unit).
Re claim 16, Wih and Gar teaches claim 1. Furthermore, Wih teaches wherein the transcoding is performed at install time when an application has been downloaded and installed onto a storage device of a computer ([0022] The game distributions server 110 and/or the external storage medium 120 contain a game package 130. The game package 130 may be a losslessly compressed archive, e.g. a Zip or 7z file or a compressed tar archive. The game package 130 may also be an installer or archive configured for use by a particular gaming platform. For instance, the gaming platform may be any of PC, Mac, Xbox One, PlayStation 4 or Nintendo Switch) and ([0017] The described system is particularly advantageous in the context of video games. Many modern video games have a vast number of high-quality textures. By reducing the amount of persistent storage required to store these textures, the described system can greatly reduce the overall storage requirement for such video games. Moreover by reducing the amount of data needed to represent textures, in accordance with various implementations described in this specification, significant improvements may be made in network download sizes, game installation times and loading times).
Re claim 18, Wih and Gar teaches claim 17. Furthermore, Wih teaches wherein a portion of the single texture representation is streamed to the memory for transcoding while a portion of the plurality of textures is being rendered ([0032] When one or more instructions of the game executable 132 requiring a portion of the texture map to be used for rendering is executed, the compressed texture 174 is loaded into the RAM 181 of the GPU 180 so that the GPU 180 can perform the requested rendering. It should be noted that the compressed texture 174 is significantly smaller than the uncompressed representation but is larger than the compressed image 134, since each of the regions of the texture map is compressed to a fixed number of bits) and ([0033] The GPU 180 may use specialized decompression hardware 180 to retrieve the portion of the compressed texture 182 and decompress it in to raw pixel data usable for rendering. The GPU may use small portions of the texture map for rendering at any time. However as described above, the compressed texture 174 is adapted for selective access so that selected portions of the compressed texture may be loaded in to the decompression hardware 182. The decompression hardware 182 may comprise an application-specific integrated circuit adapted for performing texture decompression. The decompressed portion of the texture 184 may be output by the decompression hardware 182 and stored in the texture cache 184).
Re claim 21, Wih and Gar teaches claim 1. Furthermore, Wih teaches wherein at least two different portions of the single texture representation are transcoded to at least two different portions of the plurality of textures with a same hardware-supported compression format ([0015] In accordance with various example implementations, compression parameters for each pixel block in an image are determined using a compression parameter neural network. A compressed representation of the image may be stored in a conventional compressed format such as JPEG2000 format. When the image is needed by an application requiring a block compressed representation, e.g. a 3D renderer, the JPEG2000 compressed version of the image is decompressed. Then the decompressed image is efficiently recompressed into the respective modern block compression format using compression parameters obtained using the compression parameter neural network. Compression parameter neural networks described herein can determine compression parameters with fewer computational resources than brute force methods used by many block compressors), ([0039] In step 240, the current pixel region is compressed to an appropriate compression format and stored to memory accessible by the GPU. The compression to the appropriate compression format includes determining appropriate compression parameters using the compression parameter neural network. The compression format may be BC7 or BC6H, or another suitable compression format such as ASTC. An example method by which compression and storage of the pixel region may be performed is illustrated in FIG. 3. Execution then returns to step 230).
Re claim 22, Wih and Gar teaches claim 1. Furthermore, Wih teaches wherein at least two different portions of the single texture representation are transcoded to at least two different portions of the plurality of textures with different hardware-supported compression formats ([0015] In accordance with various example implementations, compression parameters for each pixel block in an image are determined using a compression parameter neural network. A compressed representation of the image may be stored in a conventional compressed format such as JPEG2000 format. When the image is needed by an application requiring a block compressed representation, e.g. a 3D renderer, the JPEG2000 compressed version of the image is decompressed. Then the decompressed image is efficiently recompressed into the respective modern block compression format using compression parameters obtained using the compression parameter neural network. Compression parameter neural networks described herein can determine compression parameters with fewer computational resources than brute force methods used by many block compressors), ([0039] In step 240, the current pixel region is compressed to an appropriate compression format and stored to memory accessible by the GPU. The compression to the appropriate compression format includes determining appropriate compression parameters using the compression parameter neural network. The compression format may be BC7 or BC6H, or another suitable compression format such as ASTC. An example method by which compression and storage of the pixel region may be performed is illustrated in FIG. 3. Execution then returns to step 230).
Re claim 23, Wih and Gar teaches claim 1. Furthermore, Wih teaches wherein the transcoding is performed using a single neural network ([0028] The compression parameter neural network 166 is a neural network for generating compression parameters based on the vector representations of the pixel region. In some implementations the neural network may comprise a feedforward neural network having a softmax output layer. The neural network may be trained based on a cross entropy loss function, as described in more detail below. The neural network may receive a vector representation of the pixel region as an input, processes the received input through one or more layers of the neural network, and outputs a vector from which a corresponding set of compression parameters may be determined. The output vector may comprise a number of elements with each element having a value giving a probability that a compression parameter set represented by that element is an optimal parameter set (as estimated by the network). The compression parameter set corresponding to the element with the highest probability may then be selected for compressing the pixel region to texture compression format. The compression parameter set includes one or more compression parameters, which may for example indicate a compression mode, partition bits and/or rotation bits).
Re claim 24, Wih and Gar teaches claim 1. Furthermore, Wih teaches wherein the transcoding is performed using at least two neural network ([0028] The compression parameter neural network 166 is a neural network for generating compression parameters based on the vector representations of the pixel region. In some implementations the neural network may comprise a feedforward neural network having a softmax output layer. The neural network may be trained based on a cross entropy loss function, as described in more detail below. The neural network may receive a vector representation of the pixel region as an input, processes the received input through one or more layers of the neural network, and outputs a vector from which a corresponding set of compression parameters may be determined. The output vector may comprise a number of elements with each element having a value giving a probability that a compression parameter set represented by that element is an optimal parameter set (as estimated by the network). The compression parameter set corresponding to the element with the highest probability may then be selected for compressing the pixel region to texture compression format. The compression parameter set includes one or more compression parameters, which may for example indicate a compression mode, partition bits and/or rotation bits).
Re claim 25, Wih and Gar teaches claim 1. Furthermore, Wih teaches wherein the at least a portion of the plurality of textures with the hardware-supported compression format is output to the hardware for decompression ([0033] The GPU 180 may use specialized decompression hardware 180 to retrieve the portion of the compressed texture 182 and decompress it in to raw pixel data usable for rendering. The GPU may use small portions of the texture map for rendering at any time. However as described above, the compressed texture 174 is adapted for selective access so that selected portions of the compressed texture may be loaded in to the decompression hardware 182. The decompression hardware 182 may comprise an application-specific integrated circuit adapted for performing texture decompression. The decompressed portion of the texture 184 may be output by the decompression hardware 182 and stored in the texture cache 184).
Re claim 26, Wih and Gar teaches claim 25. Furthermore, Wih teaches wherein the hardware further renders the decompressed at least a portion of the plurality of textures ([0033] The GPU 180 may use specialized decompression hardware 180 to retrieve the portion of the compressed texture 182 and decompress it in to raw pixel data usable for rendering. The GPU may use small portions of the texture map for rendering at any time. However as described above, the compressed texture 174 is adapted for selective access so that selected portions of the compressed texture may be loaded in to the decompression hardware 182. The decompression hardware 182 may comprise an application-specific integrated circuit adapted for performing texture decompression. The decompressed portion of the texture 184 may be output by the decompression hardware 182 and stored in the texture cache 184).
Claim 30 claims limitations in scope to claim 1 and is rejected for at least the reasons above.
Claim 31 claims limitations in scope to claim 2 and is rejected for at least the reasons above.
Claim 32 claims limitations in scope to claim 5 and is rejected for at least the reasons above.
Claim 33 claims limitations in scope to claim 11 and is rejected for at least the reasons above.
Claim 34-35 claims limitations in scope to claim 14-15 and is rejected for at least the reasons above.
Claim 36-38 claims limitations in scope to claim 16-18 and is rejected for at least the reasons above.
Claims 39-40 claim limitations in scope to claims 21-22 and is rejected for at least the reasons above.
Claim 41 claims limitations in scope to claim 23 and is rejected for at least the reasons above.
Claims 42-43 claim limitations in scope to claims 25-26 and is rejected for at least the reasons above.
Claim 46 claims limitations in scope to claim 1 and is rejected for at least the reasons above.
Claim 47 claims limitations in scope to claim 23 and is rejected for at least the reasons above.
Claim 48-49 claims limitations in scope to claim 25-26 and is rejected for at least the reasons above.
Claim(s) 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wihlidal (US 20200051287, hereinafter “Wih”) in view of Garigapati (“Pyramid Level Lossy Image Compression preserving Crucial Details, Things to Know,” hereinafter “Gar”) and Wronski (“Dimensionality reduction for image and texture set compression,” hereinafter “Wronski1”).
Re claim 8, Wih and Gar teaches claim 1. Wih and Gar do not explicitly teach wherein the set of textures represents a material.
However, Wronski1 teaches wherein the set of textures represents a material (see p. 1-2, dimensionality reduction for image and texture set and examples of different textures including albedo textures, specular color textures, gloss maps, etc.).
Wih, Gar, and Wronski1 teaches claim 8. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wih and Gar’s image-based compression system including textures to explicitly include textures representing materials, as taught by Wronski1, as the references are in the analogous art of image/texture compression of data. An advantage of the modification is that it achieves the result of explicitly including textures that represent material properties for visualization to a user.
Re claim 9, Wih, Gar, and Wronski1 teaches claim 8. Furthermore, Wronski1 teaches wherein each texture of the plurality of textures represents a different property of the material (see p. 1, The main use-case I had in mind is for Physically Based Rendering materials with large sets of multiple textures representing different physical material properties (often different sets per different material/object!), but can be extended to more general images and textures – from simple RGB textures, to storing 3D HDR data like irradiance fields). For motivation, see claim 8.
Re claim 10, Wih and Gar teaches claim 1. Wih and Gar do not explicitly teach wherein at least one texture of the plurality of textures includes a plurality of channels. However, Wronski1 teaches wherein at least one texture of the plurality of textures includes a plurality of channels (see p. 1-2, dimensionality reduction for image and texture set and examples of different textures including albedo textures, specular color textures, gloss maps, etc.) and (see p. 2, “Uff, that’s a lot! And some of those use more than one texture channel! (like albedo maps that use RGB colors, or normal maps that are usually stored in two or three channels). Furthermore, with increasing target screen resolutions, textures also need to be generally larger. While I am a fan of techniques like “detail mapping” and using masked tilers to avoid the problem of unique large textures everywhere, those cannot cover every case – and the method I am going to describe applies to them as well). Wih, Gar, and Wronski1 teaches claim 10. For motivation, see claim 8.
Claim(s) 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wihlidal (US 20200051287, hereinafter “Wih”) in view of Garigapati (“Pyramid Level Lossy Image Compression preserving Crucial Details, Things to Know,” hereinafter “Gar”) and Knittel et al. (“Hardware for Superior Texture Performance”).
Re claim 19, Wih and Gar teaches claim 1. Furthermore, Wih and Gar do not explicitly teach wherein the single texture representation enables random access such that only a portion of the single texture representation is transcoded.
However, Knittel teaches wherein the single texture representation enables random access such that only a portion of the single texture representation is transcoded (see p. 476, Commonly used image compression schemes such as JPEG, however, are not suitable for texture mapping since they do not fulfil two essential requirements for texture mapping since they do not fulfil two essential requirements for texture mapping: The decompression has to be simple and very fast, and random access to texels must be possible. Here, we propose to use a specific compression scheme which meets the above requirements) and (see p. 477, Block Truncation coding/color cell compression, wherein compressed data for a block consists of only two colors and 16 bits that indicate which one of the two colors is assigned to each of the 16 pixels. Figure 3 shows the principle of the BTC/CCC).
Wih, Gar, and Knittel teaches claim 19. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wih and Gar’s image-based compression system including textures to explicitly include the single texture representation enabling random access, as taught by Knittel, as the references are in the analogous art of texture compression. An advantage of the modification is that it achieves the result of using random access to improve rendering times.
Re claim 20, Wih, Gar, and Knittel teaches claim 19. Furthermore, Knittel teaches wherein the portion of the single texture representation is a block of texels included in the single texture representation (see p. 476, Commonly used image compression schemes such as JPEG, however, are not suitable for texture mapping since they do not fulfil two essential requirements for texture mapping since they do not fulfil two essential requirements for texture mapping: The decompression has to be simple and very fast, and random access to texels must be possible. Here, we propose to use a specific compression scheme which meets the above requirements) and (see p. 477, Block Truncation coding/color cell compression, wherein compressed data for a block consists of only two colors and 16 bits that indicate which one of the two colors is assigned to each of the 16 pixels. Figure 3 shows the principle of the BTC/CCC). For motivation, see claim 19.
Claim(s) 27-29, 44-45, 50-51 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wihlidal (US 20200051287, hereinafter “Wih”) in view of Garigapati (“Pyramid Level Lossy Image Compression preserving Crucial Details, Things to Know,” hereinafter “Gar”) and Harris et al. (US 20130229422).
Wih and Gar do not explicitly teach further comprising, at the device:
interleaving the output at least a portion of the plurality of textures to form at least one
interleaved texture.
However, Harris teaches at the device: interleaving the output at least a portion of the plurality of textures to form at least one interleaved texture ([0043] FIG. 4B illustrates an example of interleaved tiled storage of RGBA data, according to one embodiment. A set of interleaved tiles 410 may include four tiles representing sixteen pixels of RGBA image data. Each of the four interleaved tiles 410 includes four RGBA pixels with interleaved red, green, blue, and alpha values. The interleaved tiles 410 are configured in a non-planar, interleaved format such that red data is stored alongside green data, green data is stored alongside blue data, blue data is stored alongside alpha data, and so on) and ([0063] In one embodiment, a pixel shader 222 on the GPU 170 may be used to convert pixel data from an RGBA interleaved contiguous texture to a format appropriate for a CPU-based tiling system. The pixel shader 222 may be given descriptions of the destination tiled image in order to reorder the data into an efficient format for use on the CPU. The description data may include the starting origin in the destination tile, the destination tile size, and the width and height of the source image. In one embodiment, one pixel shader program may be used to handle conversion to a planar tiled format, and another pixel shader program may be used to handle conversion to an interleaved tile format. The planar conversion process may write into an RGBA texture in order to maximize the volume of data that can be processed in parallel).
Wih, Gar, and Harris teaches claim 27. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wih and Gar’s image-based compression system including interleaving the output at least a portion of the plurality of textures to form at least one interleaved texture, as taught by Harris, as the references are in the analogous art of texture compression. An advantage of the modification is that it achieves the result of using interleaving on texture data to reduce complexity and improve performance.
Re claim 28, Wih, Gar, and Harris teaches claim 27. Furthermore, Harris teaches wherein the hardware accesses the at least one interleaved texture for rendering ([0009] Various embodiments of systems, methods, and computer-readable storage media for conversion of contiguous interleaved image data are disclosed. Image data in a contiguous interleaved format may be received at a graphics processing unit (GPU). The GPU may generate converted image data in a tiled format based on the image data in the contiguous interleaved format. The tiled format may be readable by an image editing program running on a central processing unit (CPU)). For motivation, see claim 27.
Re claim 29, Wih and Gar teaches claim 1. Wih and Gar do not explicitly teach wherein shader code accesses the at least one interleaved texture, computes which texel locations to access and sends the locations to the hardware for use in fetching the texels.
However, Harris teaches shader code accesses the at least one interleaved texture, computes which texel locations to access and sends the locations to the hardware for use in fetching the texels ([0043] FIG. 4B illustrates an example of interleaved tiled storage of RGBA data, according to one embodiment. A set of interleaved tiles 410 may include four tiles representing sixteen pixels of RGBA image data. Each of the four interleaved tiles 410 includes four RGBA pixels with interleaved red, green, blue, and alpha values. The interleaved tiles 410 are configured in a non-planar, interleaved format such that red data is stored alongside green data, green data is stored alongside blue data, blue data is stored alongside alpha data, and so on) and ([0063] In one embodiment, a pixel shader 222 on the GPU 170 may be used to convert pixel data from an RGBA interleaved contiguous texture to a format appropriate for a CPU-based tiling system. The pixel shader 222 may be given descriptions of the destination tiled image in order to reorder the data into an efficient format for use on the CPU. The description data may include the starting origin in the destination tile, the destination tile size, and the width and height of the source image. In one embodiment, one pixel shader program may be used to handle conversion to a planar tiled format, and another pixel shader program may be used to handle conversion to an interleaved tile format. The planar conversion process may write into an RGBA texture in order to maximize the volume of data that can be processed in parallel). Wih, Gar and Harris teaches claim 29. For motivation, see claim 27.
Claims 44-45 claim limitations in scope to claims 27-28 and is rejected for at least the reasons above.
Claims 50-51 claim limitations in scope to claims 27-28 and is rejected for at least the reasons above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Peter Hoang whose telephone number is (571)270-1346. The examiner can normally be reached Monday-Friday 8:00 am - 5:00 pm PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hajnik F. Daniel can be reached at (571) 272-7642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/PETER HOANG/ Primary Examiner, Art Unit 2616
Prosecution Insights