starting to investigate this. picked 4 images from my images folder to test on. posting this as a reference for myself, to see what we can manage to achieve.
shows in order, file size on disk, texture byte size to send to gpu, and pixel resolution
View attachment 4367392
(idk what happened with those floating brackets, powershell is tripping, they dont exist)
from what i found here
You must be registered to see the links
we might be able to achieve a 6:1 compression ratio with DXT1 (actually, maybe even more, that wiki mentions 6:1 from 24bit RGB to DXT1, but we're currently using RGBA which i assume is 32bit, so 32bit RGBA * 16pixel per chunk / 64bits per DXT1 chunk = 8:1 compression). but converting to that format might take time. will probably do something like, first time an image is loaded, if not correct format it gets converted then overwritten to disk. means all images will be .dds from now on, when this is all worked out. also, it mentions that DXT1 is an extension, not part of opengl spec, so might not work on all gpus?
EDIT: yep, 800% compression ratio
View attachment 4367520
thats the first image, the 18.2mb on gpu and 5.8mb on disk. crazy how dxt1 gets even better compression than the original png image (btw thats "race of life" banner)
now next problem is that i used this wand library, its basically image magick. ideal would be to have just dxt1 conversion in python without extra dependencies, but pillow doesnt do that from what i can see. could maybe include the magickwand .dll / .so
some preliminary vram results, with opening the tool to 12 collections gif banners:
background baseline usage before opening the tool: 1.6gb
no compression: 3.5gb (1.9gb used by the tool)
dxt1 with wand library: 2.1gb (0.5gb used by the tool)
dxt1 with opengl compression: 2.7gb (1.1gb used by the tool)
dxt1 with opengl compression and reapplying after compressing: 2.0gb (0.4gb used by the tool)
so yeah, 800% compression ratio between 1.9gb uncompressed and 0.4gb dxt1
what i gather from this is that dxt1 usage is same between these options, just with some caveats. opengl can compress in realtime, but seems like some of the uncompressed data is left behind. this is fixed by applying the texture uncompressed, letting opengl compress it, then reapplying the compressed texture. that gives 2.0gb, which id say is same usage as the wand library 2.1gb, probably just some background fluctuation on my pc in the meantime.
what im not super sure about is visual quality. dxt1 is lossy, i had not realized this when i started looking into this. it compresses in 4x4 pixel chunks, so after compression you can see some artifacts in some cases. its especially evident in gifs, where the different pixel chunks have slightly different color shades and are pretty visible. the original gifs already had some artifacts due to small color palette, but dxt1 makes it a bit more noticeable when zooming in. still tho, very much usable from what i can see. might make it only compress images above a certain resolution later on.
i cant really tell which would work best between opengl and wand, they both have some pros and drawbacks:
- opengl seems to cause more artifacts on smooth gradients, while wand seems to cause more artifacts around well defined shapes
- opengl compresses while applying the texture thus blocking the interface while compressing, wand is a separate step so interface is responsive during compression
- opengl is already here, wand would be a new dependency and a new dll to include and adds complexity
- opengl might compress differently between gpu vendors, wand would be same for everyone
overall the visual quality seems better with wand, and i think im leaning towards using that one. still tho, would be nice to get some feedback.
ive pushed build 1410 that includes some initial testing of these modes, you can switch between them at the bottom of the sidebar settings.
i am still trying to figure out how to bundle image magick, for now youll need to install it from
You must be registered to see the links
(any of the "dll" options) if you try this build.
KEEP IN MIND: images will load slower with compression. for now, the files on disk are left untouched, so compression is done every time the image is loaded. the idea eventually is to compress once, then store on disk, which will make images loading much faster and occupy less disk space. but for now, i am looking for feedback on vram usage and on visual quality of compressed images. once that is figured out and compressed textures will start being saved to disk, we might even be able to make it unload images when offscreen, if loading textures will be fast enough for that. would mean constant vram usage for how many are on screen, not exponential with more games in library.
Dukez FaceCrap ascsd