Overview of Basis' RDO Mode

in

As we all know, textures and images in your application have to somehow end up as a GPU texture format when they make it to the GPU. GPU formats basically split the image up into tiles, and each tile is independent from other tiles. It works fantastic for GPUs-- the GPU can keep most of the texture compressed while it only accesses what it really needs.

However, this isn't so great for CPU storage. For example, if I had an image that was all red, we'd have a data block that was just lots of identical little red tiles. This repetitive memory structure often leaves us with image files that are often unacceptably large on CPUs. And it's unnecessarily large, too-- CPUs don't need tile-based formats for storage, and we can reduce the image size much more with this in mind.

The most common fix today (other than using Basis) is to losslessly compress that GPU format data. That typically gets you a file 50-75% of the original size.

When we mention that .basis files (our custom file format) can easily be 25% of the size of GPU formats, the major complaint we get is that folks don't have the time to change their codebases to accommodate this.

This is where our RDO (Rate Distortion Optimization) Mode comes into play. You can use Basis, get huge size decreases, and not change your current codebase at all.

RDO Mode replaces your normal GPU format compression, and allows you to trade off quality for storage size. Rate Distortion Optimization is common in the video codec world-- we apply those same techniques to texture compression here. We also intelligently structure this data, knowing that you'll be losslessly compressing it afterward. We can even add custom optimizations if we know exactly which lossless codec you'll be using.

Of course, the .basis format's usually better both in terms of size reduction and in terms of runtime performance (transcoding .basis to the GPU format is faster than lossless decompression), but it uses the same codebase and RDO mode can get you surprisingly good results. And if your only alternative is regular GPU format compression followed by lossless, you'll be far better served with Basis in RDO Mode.

Basis Update: ETC1 Prototype Completed

in

We just finished the first ready-to-ship prototype of Basis, with support for the popular ETC1 format. This version of the compressor covers most mobile platforms (with the main exception being iOS devices without Metal support) as well as platforms like Android TV. In addition, we'll be adding support and optimization for texture arrays as a feature.

The graph below plots size (on the x axis) against quality (y axis), and below are some images compressed with the compressor so you can judge quality for yourself. Green is our compressor with different quality settings, red represents a common current method (losslessly compressing ETC1 with LZMA). The test is for "RDO mode"-- in other words, instead of using our intermediate format we use our compressor to make smart quality tradeoffs in a .ktx file that can be losslessly compressed further. Our custom intermediate format should perform even better, and we'll post updates as development progresses.

Rich does a good job of blogging in-progress updates, so for technical details check out some of his recent posts:

Of course we'll continue to refine this, but you can see for not too much quality reduction we can easily half your storage size. These results are looking promising.

Also remember that we've done this feature as a pre-order request. We are still open to supporting other platforms or features earlier-- if you would like to request that your feature be prioritized, just contact us at info@binomial.info.

If you'd like to try a drop of this, feel free to contact us at info@binomial.info, or sign up for our Google Group at https://groups.google.com/forum/#!forum/binomialcompressor/ for more frequent updates.

 

 

 

Defining Compressor Direction from Pre-Orders

in

As we've announced, we're moving forward in developing a universal compressor that can work across ETC1 and BC7, and have most recently started looking at ASTC as well. For an in depth look into our experiments in this direction, you can check out Rich's blog.

It's become increasingly difficult to balance compressor work with the contract work we do, and we have gotten several companies who have come forward with specific needs, willing to pay to accelerate their features as well as pre-order the product.

Therefore, we're announcing that our development direction will take prioritization from the pre-orders and accelerated feature requests we receive.

We can't say much else until some of these pre-orders get finalized, but we do want to make sure everyone has the opportunity to request features before we decide a direction!

Just a few potential directions we could go in:

  • PVRTC + DXT (iOS and most desktop/consoles)
  • Just highly optimized DXT (basic desktop/console support)
  • DXT + BC (including 7) + ASTC + ETC (most mobile and high quality graphics support on desktop/consoles).
  • Prioritizing features like GPU transcoding

If you know you can pre-order the product and have features you want supported, contact us at info@binomial.info .

Introduction to GPU Texture Transcoding

in

It boils down to sending less data over a network and making users wait less, without killing quality of images.

In many applications, images and textures are essential. They often take up much of the data needed to run a game. One surprising thing here is just how much many games and applications could improve in this sense.

To give a user this data, we often send it over a network. This may look like downloading a game from Steam, or loading a new level in your cloud-based phone game. It can also be essential for projects like wireless VR.

---

Another important thing to consider about textures is how our GPU reads them.

Modern GPUs have problems with memory space. It's often not acceptable to store an image uncompressed on a GPU. Therefore, GPU manufacturers have developed special texture compression formats that allow images to be stored compressed on their GPUs, and then can be decompressed in hardware on the GPU-- this allows the decompression process to be extremely fast.

Therefore, we want our textures to be converted to these GPU formats.

---

You might be asking-- why not just compress to these GPU formats, and send those over the network? The issue here is that these GPU formats are not as small as we'd like. JPEG, for instance, can compress an image to about a fourth of the size of these GPU formats.

Okay, so why not compress the images to JPEG, then while the game is running turn the JPEG images into these GPU compression formats? That's problematic too. JPEG compression introduces artifacts, and then recompressing to these GPU formats will introduce different artifacts. We want to avoid extra, bad-looking artifacts if we can.

This is where crunch comes in. With crunch, you can compress an image to around the size of a JPEG image, and transcode this image directly to your desired GPU format extremely quickly without those nasty double artifacts. Transcoding is the process of going directly from one compressed format to another-- no decompression and recompresssion necessary! We now have that fast network send, less artifacts, and fast decoding. What's not to love?

Your users will be happy as they quickly download games without sacrificing quality!

There's one big problem. Crunch only supports certain GPU formats. If you want to use it on an iOS device, for instance, you can't.

And there's also the matter of speed and data size. Can crunch be even better?

Yes, yes it can. And that's what we're working on.

Transferring Ownership of Crunch to Binomial

in

Today we transferred ownership and maintenance of crunch, the open source advanced DXTc texture compression and transcoding library, to Binomial.

It'll still be open source-- this just means that we are now able to more actively work on this important library, after a period of inactivity that crunch has been through.

We will also continue to work on the new compressor.

You can now find crunch on Github here: https://github.com/BinomialLLC/crunch

 

Sign up for Early DXT, ETC1, and BC7 Updates

in

A brief post today-- we want to announce that we've decided on a development direction.

Our universal compressor will aim to support DXT, ETC1, and BC7 formats in this first phase of development.

We'll continue to post major updates to the blog, but if you'd like a place to give direct feedback, potentially get alpha/beta access, and get more details please sign up to our Google Group:

https://groups.google.com/forum/#!forum/binomialcompressor/

 

Announcing Development on a New Texture Compressor

in

We want to announce development on a new GPU lossy texture compressor. The encoder will be closed source, transcoder open source. Our new compressor will support a custom, tightly compressed intermediate format that can be quickly decoded to any GPU-friendly texture format.

The compressor will have several quality vs. speed settings, so it'll be usable on a desktop but can also scale up to cloud deployment.

Unlike anything out there now, it'll also support all relevant mobile and desktop GPU texture formats in a single library.

As many developers know, the need for this compressor is high. It's crucial for any application that cares about sending texture data over a network quickly, and universal GPU support means the developer never needs to worry because the library will "just work" independent of platform.

If you're interested in watching for updates, have any feedback or feature suggestions, or would be interested in getting in on the alpha/beta releases, feel free to watch this blog or e-mail us at info@binomial.info with "New Texture Compressor" in the subject line.