Best image file format for designing custom GUI & animations ?

[diroxe7660]

Thank you, your take on QOI looks interesting. QOI+LZ4 is indeed a good choice. I wonder how much further compression ratio could be improved with a lossy filter like rdopng.

[eLawnMust]

As someone who uses alot of GUI-Less plugs still for efficiency & fast work I find the lions share of GUI-ed plugs to use too much resources, some disgustingly so. This may seem trivial until you start adding many up & some of us don't have 200 GB RAM to waste burning electrons to heat our homes with.

So might be wise to try different formats as trial run to see what has best savings of resources...

[Guillaume Piolat]

I wonder how much further compression ratio could be improved with a lossy filter like rdopng.

rdopng looks pretty cool, TIL
I think you would get the best results with the rdopng PNG encoder, but using zstd (or brotli) to encode the differential vs miniz. With zstd that is the "ZPNG" codec in the above-posted graph. (but then, JPEG decodes faster than PNG anyway if you can go lossy, so it would be for transparent things).

[mystran]

I wonder how much further compression ratio could be improved with a lossy filter like rdopng.

rdopng looks pretty cool, TIL
I think you would get the best results with the rdopng PNG encoder, but using zstd (or brotli) to encode the differential vs miniz. With zstd that is the "ZPNG" codec in the above-posted graph. (but then, JPEG decodes faster than PNG anyway if you can go lossy, so it would be for transparent things).

The main thing with JPEG is that being a DCT-based block codec, you're always (even at max quality, since it always quantizes no matter what) going to get a bit of blockyness (and color shifts, though those could be an issue for a signal-domain scheme as well) which tends to look rather bad for UI graphics, especially as you typically have fairly clean and sharp shapes that are pretty much the worst-case for such a codec. Assuming rdopng does the lossy optimization directly in signal domain, it should probably be able to produce artifacts that are more likely to remain perceptually insignificant in this particular application.

ps. It is a bit unfortunate that the rdopng examples given on github are mostly photos (or 3D renders aiming for similar look).. because judging by the one example ("high fidelity") with just a gradient and some text, it does seem to distort the gradient quite a bit at more aggressive settings and it'd be interesting to know how it handles something like path-traced GUI panels, where something like JPEG does poorly due to the sharp features, but which still have smooth diffuse gradients (that often need dither to look good even in 8bpp). Don't have the energy to try right now though.

[Music Engineer]

...some of us don't have 200 GB RAM to waste burning electrons to heat our homes with. So might be wise to try different formats as trial run to see what has best savings of resources...

When compressed pixel file formats are used, they will only affect the usage of disk space. In RAM, the images will be present in their uncompressed form anyway, regardless of the chosen storage format. Of course, it's possible to save some RAM usage by not using pixel formats at all, i.e. by using vector graphics instead - but this will then require more CPU to render them - a classic space-vs-time tradeoff....kind of. But it will probably matter only for larger images anyway - like the whole background for a GUI - and not so much for small elements like sliders, knobs, etc. (because their image sizes tend to be very small anyway).

[BONES]

Thank you, your take on QOI looks interesting. QOI+LZ4 is indeed a good choice. I wonder how much further compression ratio could be improved with a lossy filter like rdopng.

There's jsut one problem - how do you make them? It's a file format with pretty much zero support in any commercial graphics package that I am aware of.

As someone who uses alot of GUI-Less plugs still for efficiency & fast work I find the lions share of GUI-ed plugs to use too much resources, some disgustingly so.

I think you will find that has more to do with the GUI-less plugins sounding like shit compared to those with a GUI.

[Guillaume Piolat]

Heh point taken.
Now that I think of it, back in the days the DevIL library (or perhaps SDL_Image) was able to load TIFF JPEG, a format that would allow JPEG with alpha, wrapped inside a TIFF. I think the alpha is compressed as greyscale JPEG inside the container. (I checked and GIMP still support that as input/output, a very nice reduction)

[diroxe7660]

rdopng+QOI+LZ4

There's jsut one problem - how do you make them? It's a file format with pretty much zero support in any commercial graphics package that I am aware of.

Even if you used PNGs, JPGs or SVGs, you'd still run those produced by your editor of choice through a number of post processing programs to optimise for size, so moving to your own asset format really is the same amount of work.

Not a good choice if you want users to be able to make their own themes though, but few developers are open to the idea anyway.

[BONES]

No, you don't and no, it's not. Photoshop takes care of all that for you, as do most other pro or even semi-pro applications. With a GUI, and multi-sizes, we're talking hundreds of images. DUNE, for example, has more than 200 separate bitmaps for each skin size. There are four different sizes so a full set of skins means processing almost 900 image files. There is no way you want to be processing those multiple times. You want to create them and save/export them once for each size.