It's an appropriate comparison, and Oodle Texture is a different thing. I've actually been meaning to explain this for a while, as it doesn't seem to be well explained anywhere, and there's a lot of misunderstanding and misinformation on the topic. So I hope you don't mind if I go on a bit of a digression, and explain some things you likely already know, just for the sake of providing a complete account of things.
Block Texture Compression
Texture compression has been a thing for a long time, with the goal of textures taking up less space not just on-disk, but in memory as well. In order for textures to be kept in memory as a compressed format, they have to be decompressed extremely quickly by the GPU, so they have to use very specific compression techniques. If we think about a compressed format like a zip file, or even a JPEG image, if you want a single piece of data from the file, you have to decompress the entire thing. For textures held in memory decompressing the entire texture every time the GPU needs a single texel would be extremely inefficient, so instead they use a technique called block encoding.
The way block encoding works is by first dividing the texture up into blocks (typically 4x4 pixels) and compressing each block individually, with a fixed compressed size (usually 128 bits). The benefit of this is that the GPU can know exactly where the texture data it needs is, and only decompress the individual 128-bit block it needs, rather than the entire texture. The compressed encoding used for the blocks is intentionally simple, so that GPUs can process a very large number of texture samples each frame.
The widespread use of block texture compression started in the late 90s when a graphics card manufacturer called S3 Graphics developed a block compression format called S3TC for their graphics cards. This was licensed for use in the Gamecube, and also became the basis of the texture compression formats Microsoft added to DirectX, and therefore became the standard for PC graphics cards. Microsoft have defined a range of texture compression formats referred to as BC formats, from BC1 to BC7. The first three of these are, I believe, direct implementations of S3TC's different modes, and then Microsoft added a few more to handle specific texture types and compression ratios. The last two of these formats to be added, BC6H and BC7, were introduced with DirectX 11 and have been supported widely since 2010, including on all modern games consoles.
There's also an alternative texture compression algorithm called ASTC, which was introduced by ARM and AMD in 2012. It's designed as a more flexible alternative to BC compression, as it allows for a variety of block sizes and number of channels. As it was never adopted by MS for DirectX, it didn't gain traction in the desktop GPU market, and isn't supported by any of Sony or MS's consoles, but did gain some support in the mobile market, and is fully supported by Apple's chips, and on Switch's TX1.
On-Disk Compression
One downside of using block compression formats is that, because they compress each block individually, they don't achieve the smallest possible file size. This is a worthwhile trade-off in memory, where you want to be able to decompress only a small part of the texture at a time, but when storing the textures on disk, this isn't really important. You're going to load the full texture from disk to memory at once, so you might as well use a technique that keeps the on-disk file size as small as possible.
For this reason almost all games (including on consoles like Switch, without dedicated decompression hardware) add an additional layer of compression when storing texture data on disk, usually a general purpose lossless compression algorithm like DEFLATE (aka Zlib). Decompressing this data when pulling it off a hard drive/SSD/game card can be a lot of work for the CPU, which can become a bottleneck, which is why Sony, MS and Nintendo now all have hardware specifically to handle decompression for algorithms like these.
Lossless Compression Algorithms
One thing that's important to note here is that there's no such thing as a free lunch with lossless compression algorithms, and there's no "inside out" compression algorithm that's going to come along and magically reduce file sizes by large amounts. There's a mathematically minimum size that any data can be losslessly compressed to based on its entropy, and compression algorithms have been circling that minimum since the 1980's.
For general-purpose compression algorithms, there's generally a trade-off between compression speed, decompression speed and compression ratios, with different algorithms being better at one or two of these three compared to others. To the extent that better compression ratios have been achieved over the years by newer algorithms it's largely because the increase in speed of CPUs has allowed for algorithms that would have been too slow otherwise. The big increase in CPU cache sizes has also allowed for algorithms that work with more data at once, which generally allows for better compression ratios. These differences are actually pretty minor, though, with differences in compression ratios often being single digit percentages between state of the art and much older compression algorithms.
The other big factor is precisely what kind of data the algorithm is compressing. Different compression algorithms can be better or worse for different data types by relatively large amounts, so there can be a big benefit to choosing a compression algorithm that's specifically tailored for the data you're trying to compress.
PS5 Decompression Hardware
PS5 has decompression hardware that supports two compression algorithms: DEFLATE and Oodle's Kraken format. DEFLATE is a widely used general purpose compression algorithm that's been around for about 30 years. Kraken doesn't have many published details, as it's proprietary, but one important thing to note here is that it's a general purpose compression algorithm, not one which is specifically designed for game data. They advertise around 10% better compression ratios than DEFLATE, although many of their examples are of non-game data, and as with any vendor provided benchmarks, I'm always a little suspicious that they may be cherry picked. I wouldn't be surprised if it does outperform DEFLATE in general though, as even a very similar LZ-based compression algorithm could provide better results by using a much larger sliding window to leverage modern CPUs' much larger cache sizes.
Rate Distortion Optimisation and Oodle Texture
Now we get to Oodle Texture. Oodle Texture is a piece of texture compression software than runs on the developers side which implements something called Rate Distortion Optimisation (RDO), and outputs textures in the standard BC formats.
To explain RDO, it's first necessary to explain in a bit more detail how block texture compression works. Each block effectively consists of two parts, one of which is an ID for a pattern, and the second is a set of colours to map to that pattern. Each block texture format has a specific set of pre-defined patterns that can be mapped to, and the texture compression software's job is to choose the pattern and colours which match the original texture data for that block as closely as possible.
Because of the way block encoded textures have a fixed block size, the choice of which patterns and colours are used for each block has no impact on the size of the final texture, so generally the compression algorithm will just want to choose whichever produces the best match to the original, uncompressed data. However, people realised that the choice of blocks does impact that second stage of running the texture through a general-purpose lossless compression algorithm. So, a technique called RDO was developed, where instead of encoding each block based on the best representation of the original texture data, block encodings are chosen to minimise the overall texture size after compressing with a general-purpose algorithm like DEFLATE or Kraken.
Oodle Texture is an implementation of RDO, and there are some important things to note about it. Firstly, it's not exclusive to PS5 by any means, it's just something Sony have licensed and made available to PS5 developers. It's already been widely used during the PS4/XBO generation, either by developers writing their own RDO implementations in-house or licensing from a company like Oodle. As it runs on developers computers, it's also doesn't depend on any specific hardware functionality in PS5, aside from BC texture support, which as mentioned has been standard for a long time now. In fact you could use RDO-optimised textures on the Gamecube if you really wanted to.
Another important note is that Oodle Texture/RDO doesn't impact texture sizes in memory. Block compression formats have a fixed size by design, so every 2K BC7 (say) texture is always going to come out the same size, whether you're using RDO or not. In fact, RDO actually makes the in-memory texture
worse, not better. Because RDO relies on choosing non-optimal block encodings, there's inherently a quality loss vs non-RDO compressed textures. RDO is trading off worse in-memory representation of textures for better on-disk compression of textures, and the more you reduce file sizes with RDO, the more loss of quality you get on the textures. This can be a worthwhile trade-off if the quality loss is low enough not to be noticeable, but there's always going to be some loss of texture quality from it.
Xbox Series X/S Compression Hardware
The Xbox Series S and X also have decompression hardware for lossless compression algorithms. The first one supported is DEFLATE, which is also supported on PS5's decompression hardware and is a general-purpose lossless algorithm. The second one is much more interesting, and it's called BCPack. BCPack isn't something MS have talked much about publicly, but here's their description of it from
their public documentation:
The really important thing here is that BCPack isn't a general purpose algorithm. Unlike DEFLATE and Kraken, which treat texture data the same as they would a regular text file, BCPack is specifically designed to compress BC format block-encoded textures. This is pretty important, as lossless compression algorithms designed for a very specific structured data type will always beat general-purpose algorithms, and block-encoded texture data is exactly the kind of highly structured data that's well suited to custom lossless compression algorithms.
We get a couple of hints about how BCPack works. Firstly they separate colour data from pattern data, which is a pretty easy win, as the colour data is likely to be highly correlated across a texture. Secondly, they use rANS, which is variant of Asymmetric Numerical Systems, a class of compression algorithms used in, for example, the Zstd format. There's likely some extra secret sauce in there in terms of choosing a specific implementation of rANS which works best with BC-encoded texture data.
We don't have any hard numbers on the compression ratios achieved by BCPack, but Richard Geldreich, who worked on both texture compression and lossless compression at Valve, Ensemble, and others,
estimated the following:
There's definitely a significant advantage to a dedicated compression algorithm like BCPack. Sony can get close by using RDO, but that means reducing texture quality, whereas BCPack completely side-steps the need for RDO and can achieve high levels of on-disk compression without any loss to texture quality.
Why Textures Are Important
The reason that I'm focussing to much on textures here is that they comprise the bulk of the data that decompression hardware will have to deal with. Audio and video can take up quite a bit of space, but they use compression algorithms like MP3/H264/etc. which already have an entropy encoding stage, so there's no benefit to recompressing them a second time with DEFLATE or Kraken. Other game data like code will benefit from compression, but takes up very little space comparatively.
PS5's Kraken will give a small benefit to the compression ratios of non-texture data over Xbox's DEFLATE, but as most of the data that needs compressing is texture data, and BCPack likely has a much more significant benefit in compressing texture data, the Xbox decompression hardware overall is much better suited to video games. Using RDO on PS5 can close the gap, but with a quality loss that you don't get on Xbox.
Where Nintendo Stands
We know the T239 chip used in Switch 2 has a File Decompression Engine (FDE), but we don't really know anything about it, like the compression standards it supports. It's probably a safe bet that it supports DEFLATE at least. There's a reason both Sony and MS's hardware support the algorithm, as it's extremely widely used so it's easy for developers to integrate into their pipeline (and many probably already use it on Switch).
Ideally Nintendo and Nvidia would also implement a custom compression algorithm for textures like MS have, possibly optimised around the ASTC format Switch supports (which I assume is used by most well-optimised Switch games, although I may be wrong on that). It's the kind of thing that's in Nvidia's wheelhouse.
Even without a custom algorithm for game data, the FDE should still be a big win. The benefit of decompression hardware isn't really to achieve smaller file sizes, or to make SSDs "equivalent" to much higher speeds, they're to take the work of decompression off the CPU. Games were already using compression on PS4, XBO and Switch, and the games that have achieved significantly smaller file sizes on current gen consoles have largely done so by removing duplicate data that was necessary because of mechanical hard drives' slow seek speeds, not by additional compression.
On Switch, CPU decompression was a big bottleneck, so removing that and moving decompression to dedicated hardware is a win-win. Effective storage speeds can increase considerably thanks to faster decompression, and the CPU is freed to work on other things. If they also include support for a custom algorithm for texture data then they could also achieve a modest game size reduction without the need for RDO and the associated texture quality hit, but honestly that's a relatively small win compared to having dedicated decompression hardware in the first place.