Updated Basis Universal Yields High Quality Compression, 3~4x Smaller Than JPEG/PNG

[markg85]

i have a broken wrist so I'm actually having a hard time using the keyboard. i just had surgery on it to get bolts in it and am recovering in splints and bandages and painkillers. anything involving shift/ctrl and multiple chords like shell, code is really hard with 1 hand. since you already had the files and probably 2 working hands, i though it might be easier for you to give it a try.

git clone <that basis repo>
cd <that basis repo>
cmake .
make -j <num of cores * 2>
./bin/<the execurtable>

Done.

You do it yourself.
There is no code involved in this.

[raster]

git clone <that basis repo>
cd <that basis repo>
cmake .
make -j <num of cores * 2>
./bin/<the execurtable>

Done.

You do it yourself.
There is no code involved in this.

had to read a lot of help output. i get vastly different results. basis files are significantly smaller than the jpgs i have on disk:

1.4M DSC05839.JPG
5.2M DSC05839.PNG
444K DSC05839.basis
408K circuit-board-computer-hd-wallpaper-2560x1440-4214.basis
748K circuit-board-computer-hd-wallpaper-2560x1440-4214.jpg
4.8M circuit-board-computer-hd-wallpaper-2560x1440-4214.png
336K lanterns-floating-around-the-tree-fantasy-hd-wallpaper-2560x1440-4163.basis
520K lanterns-floating-around-the-tree-fantasy-hd-wallpaper-2560x1440-4163.jpg
3.5M lanterns-floating-around-the-tree-fantasy-hd-wallpaper-2560x1440-4163.png
480K mossy-forest-sight-nature-hd-wallpaper-2560x1440-2787.basis
1.1M mossy-forest-sight-nature-hd-wallpaper-2560x1440-2787.jpg
7.6M mossy-forest-sight-nature-hd-wallpaper-2560x1440-2787.png

varying content from a photo of my office - dscn.. to some wallpapers i have floating about. jpeg quality would be around 90-97% depending on image. so a slightly larger sample size tells me it's consistently better - xz/gzip don't improve size so its already compressed it seems.

[AndyChow]

So this is was warranted a "buckle your seatbeats, we're sending you literally 15+ years ahead in time"?

[polarathene]

Hi @Remdul,

Hmm, oke. So it's not the "10 years ahead" format of it's time, like the initial news about basis suggested when it wasn't released yet. It's "merely" a container format (say like mkv) to have one uniform way of storing textures. Am i getting that right?

Also, i specifically tried this on a picture and a thumbnail thereof. Just to see if a usecase of using basis in desktop applications (think of a file browser with thumbnail previews on) would be a potential use for it.

Basis provides the compressed texture data for storage/transmission at a small file size that can be transcoded to a compressed texture format on the GPU based on what the GPU supports afaik. Not a game dev these days, but I remember having to choose those compressed texture formats to convert to and save on disk for distribution, and web/desktop/mobile along with varying hardware support can mean you might need to have multiple formats on disk, so you have a larger total size to deploy(or have to manage builds for different platforms to account for different texture support) and encoding for the multiple formats is likely going to take longer too.

So with basis you get to work around that and I think at runtime you detect or know what texture types are supported on that hardware/device and transcode to the most suitable format. Unlike with jpg/png, you're not going to be encoding on the fly(not practical) or sending them uncompressed to the GPU(more latency, more vRAM used), so it's a nice win. That said, you may not get quality to the same level as encoding for specific texture maps directly, transcoding avoids another encoding pass, so is lossless in that sense, but the data has already been compressed for generic transcoding to various formats and thus loses some quality/info that certain formats might have retained if you had avoided basis and encoded for them directly(but then you have the drawbacks of size/time).

UASTC for basis provides higher quality at the expense of less compressed size. It's able to provide better quality than earlier basis can even with it's settings tuned to quality. This is more important for textures that cater towards data rather than visual presentation of colour information. A common one is normal maps, this can use two channels of an rgba image, but with basis still can lack in quality. They have a special mode for this which splits each channel, so that one is assigned to rgb(basically a greyscale image that becomes rgb with all 3 channels the same data) and the other into the alpha channel, they're technically two ETC1S textures that get combined into one when used.

Without that, the encoder on just rgb data is focused on compressing visual/colour information, so the image data that is intended for conveying non-colour information gets handled poorly. This is a case where some formats that basis transcode to would better retain the quality if used without basis. If the quality of the compression is not acceptable, then something like UASTC may be preferrable, you could also use png but you'd have larger uncompressed size for transferring to GPU and storing in GPU memory, you'd also have mipmaps(each mipmap level is 25% of previous width/height, they're useful for when content is far away in 3D space, so a small version can be used for performance) to take care of.

I don't think there is much benefit to basis for thumbnails or general web images, webp is pretty good for that. If GPU is used, the browser generally renders tiles of the page, and a compositor for a desktop environment does whatever, but they don't really treat images differently as their own textures I think? Eg the browsers I think render the page contents and composite that onto tiles, where each tile can be texture data that the GPU will use to accel things like scrolling/zoom.

[polarathene]

it's hard to believe. jpegs compress more than 4x, so jpeg will be smaller. and i'm sure png can compress more than 4x and have no quality loss at all. i.e. all this marvel of marketing can provide is reduced pcie bandwidth requirements. which is pointless because web browser has to download picture via smaller internet bandwidth first, i.e. total time will be smaller with jpeg/png. what would be useful is shader which translates jpeg/png to gpu codec, not sure how it is feasible though

It's not intended to compete with jpeg/png for general image use. It's for texture use on GPUs. Your jpeg/png needs mipmaps generated to avoid additional overhead producing those whenever the texture is fetched. The jpeg/png lacks compressed size on GPU memory, it's only good for storage, if you think of the size of BMP images and add lots of large images in that format, it eats away at your GPU memory that could be better used for other things.

PCIe bandwidth used is also important for reduced latency. At 60 FPS, you'll drop frames if you have to fetch texture data that takes too long to grab and process, 16ms per frame, and these days you have gamers wanting double that frame rate or higher, with 2k/4k resolutions or multi-screens, etc. VR is 90FPS with two 1080p or greater frames to render, so the budget to render frames gets quite tight, minimizing latency is pretty important.

On web it might be less important now, as keeping file size down is quite important, nobody will be downloading multi-GB of texture data or running intensive workloads like you'd have with games that'd benefit the most from this. It's still welcome though, as time progresses it may see more benefit. There's already work on 3D favicons... instead of the little 2D images for associating with a website, they're promoting 3D objects for some AR/VR(XR) interface, if stuff like that picks up, it might make quite a difference.

Regarding shader suggestion, that's not how shaders work. The other benefit of basis was mentioned on page 1 by remdul. JPEG/PNG require the full image to operate on, you can't progressively load a region if you were going to point out progressive loading. Data access is different with basis, and with KTX2, there is some streaming, useful for mipmaps(similar to the progressive versions of jpeg/png, but different purpose). If you'd want to compress the texture size on the GPU to reduce vRAM usage, you're going to need to encode the image, that can be quite a bit of overhead to get similar gains in compression size, and as mentioned by remdul, you're re-compressing, not transcoding, so further quality loss. Not ideal for run-time usage.