If you think PNG is complex have a gander at webp. That plane crash is a single frame of vp8 video. Outside of a Rube Goldberg web browser the format is useless.
I don't know about other platforms but .webp is very well supported on Linux. I've got .webp files showing up just fine from Emacs and picture viewers and ImageMagick's tools do support .webp just fine.
Lossless WEBP is smaller than optimized/crushed PNG files.
And I'd say that's quite a feat, which may explain the complexity of the format.
So WEBP may be complicated but if my OS supports it by default, where's the problem? It's not as if I needed to write another encoder/decoder myself.
If you want to handle the format by yourself from scratch it's super complex indeed, but OTOH everyone just uses libwebp which has a very simple API, especially compared to something like libpng. I have added WebP support via libwebp into Allegro 5 myself and didn't even have to stop to think, it was as straightforward as it gets - and implementing animated WebPs wasn't hard either.
WebP is useful for lossless image storage for games/game engines, it takes roughly 80% of the time to load/decode vs the same image stored as a png, and is usually significantly (multiple megabytes) smaller for large textures. That stuff doesn't matter too much in a web browser, but in a game where you have potentially hundreds of these images being loaded and unloaded dynamically and every millisecond counts, it's worthwhile.
Erm, aren't both WebP and PNG rather useless for games? How do you convert those formats on the fly into one of the hardware-compressed texture formats consumed by the GPU (like BCx, ETC or ASTC)? If you're decoding PNG or WebP to one of the linear texture formats, you're wasting a ton of GPU memory and texture sampling bandwidth.
Hardware compressed texture formats introduce compression artifacts, which is fine for some art styles or PBR maps that don't need to be super accurate, but for some styles (such as pixel art or "clean" non-pixel styles, in both 2d and 3d) lossless compression is preferred, and yeah they're just decoded into bitmap data on the fly. Whether it wastes memory or not is subjective and dependent on use case. Yeah if you're pushing 4k PBR maps for terrain to the gpu using lossless formats for storage that's not smart, but you could argue that for many textures, using VRAM formats wastes disk/download space vs lossless (especially on mobile devices or webgl/wasm where space matters more). If disk space/download size isnt a concern then uncompressed vram formats can work for smaller textures. Though there is an initial decoding/upload cost to compressed lossless images, and they're not optimised well for streaming, at least with pixel art that's not a huge concern as textures tend to have small dimensions, though a spritesheet in a VRAM format can quickly baloon to ridiculous sizes for what is otherwise low resolution artwork. Of all the open formats that support lossless compression, are easy to link against, with wide platform support, webp is good, and smaller/faster than png for basically all images. Basis universal is a decent solution to the disk size problem of traditional VRAM formats, but it still isn't lossless (afaik?). Oodle is new to me, it looks good, appears to solve all of the above if the blurb is to be believed; it's a shame it's proprietary. I'd use it right away if it was FOSS.
IME most 2D games use uncompressed textures. Looking perfect matters less if you're going to stretch it across a 3D tri and do a bunch of fancy lighting.
Lossless WEBP is smaller than optimized/crushed PNG files.
And I'd say that's quite a feat, which may explain the complexity of the format.
So WEBP may be complicated but if my OS supports it by default, where's the problem? It's not as if I needed to write another encoder/decoder myself.