Sony Files Patent to Shrink Game Graphics Files Stored on Disk
Game worlds are built from millions of tiny pixel squares, and Sony's filing shows a way to store them with less detail on disk, then expand them back into the standard format with no further loss.
What Sony's slimmed-down game texture blocks do
Imagine you're downloading a big new game, and every character's jacket, brick wall and patch of grass is stored as a picture file. Those pictures, called textures, are a big reason games eat so much room on your drive.
Sony's filing goes after that bloat. Game textures are cut into tiny squares of 4 by 4 pixels, and each square usually stores a lot of fine detail about how its colors blend. Often a square doesn't need that much detail. So the system picks a leaner version for each square, trading a sliver of accuracy for a smaller file, and it decides using a size-versus-quality score.
When the game loads, those slimmed-down squares are expanded back into the standard format your graphics chip already understands. That expansion step loses nothing further, so the graphics hardware never has to know anything changed.
… compressing, without first compressing into a standard block compression format, the block of uncompressed source pixels directly into a reduced-bitrate storage block by at least selecting a reduced number of bits of precision for interpolation indices using rate-distortion optimization (RDO); …
Translation: Sony's method shrinks image data directly into a smaller file without using standard compression first.
How Sony picks fewer bits for each pixel block
The filing starts from a common graphics format called BC7. It splits a texture (the image data wrapped around 3D objects) into 4 by 4 pixel blocks. Each block keeps two endpoint colors plus a blend index for each of its 16 pixels, which says how far that pixel sits between the two colors. In the standard version those indices take 4 bits each, and the whole block takes 128 bits.
Sony's idea is to store a leaner version on disk. Claim 1 covers compressing raw source pixels directly into the slim block, with no standard BC7 block made first, and choosing fewer bits for the indices using rate-distortion optimization (a scoring rule that weighs file size against image error). In the description, the score is the expected compressed size times a user-set value, plus the error.
The description gives these storage-only options:
- 3-bit indices: 112 bits per block
- 2-bit indices: 96 bits per block
- 1-bit indices: 80 bits per block
- A fourth mode with 2-bit indices, lower-precision colors and fully opaque pixels (alpha, the transparency value, fixed at 255): 64 bits per block
On load, the colors are copied and each short index is remapped to a 4-bit value. For example, 2-bit indices 0, 1, 2, 3 become 0, 5, 10, 15, so the graphics chip sees ordinary BC7. One flag bit per block, plus two more bits for slimmed blocks, marks which blocks use the new modes.
Techniques are described for storing BC7 texture blocks on-disk with lower precision index data and transcoding back to the GPU-native BC7 format when the data is loaded.
Translation: Game graphics are saved on the hard drive in a smaller format and instantly converted back for the graphics card.
What this means for game install sizes
Texture data is a big part of how large a game is, and the filing's own background says it's desirable not to ship large texture data to a rendering device. If a studio used this kind of storage, you could see smaller installs, quicker downloads and more games fitting on your console or PC drive. The filing gives no real-world savings for any game, only per-block numbers, with the best case cutting a block from 128 bits to 64.
For developers, the appeal is that the graphics chip still receives the standard format it already reads. The cost is a small amount of added error when the textures are compressed, and the quality setting lets artists decide how much of that they will accept.
That makes this Sony's 20th filing we've tracked since July in the GPU rendering race, following applications like one to speed graphics compression and one to reduce cloud game lag.
Claim 1 is written broadly. It never mentions BC7 or any particular bit count, only "a standard block compression format" and "a reduced number of bits" for the settings that tell each pixel how to blend between two colors. The dependent claims then list specific formats, from BC1 through BC7.
The narrow part is the route. The claim describes going straight from raw pixels to the slim storage block, skipping the usual step of making a standard file first, and picking the bit count with a size-versus-quality rule. The other route, shrinking already-finished files afterward, appears in the description but not in claim 1's wording. If granted, the claim would sit in the way of anyone building an encoder with that same direct path.
As engineering it is a modest, practical trim. Each block drops from 128 bits to as little as 64 in the description's examples, and across a game's worth of textures that adds up.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time Sony patent news breaks.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
7 drawing sheets from US 2026/0340878 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in