My hope is for MP3tag to offer support for the JPEG XL (.jxl) format. It's easily the best quality and most efficient lossless image format we have right now. It's also gaining widespread system support: Apple since macOS 14, iPadOS 17 and iOS 17, and even using it as a container for their ProRAW format; Microsoft since Windows 11 24H2 (with the free JPEG XL Image Extension installed from the Microsoft Store); and even Linux (starting with Ubuntu 18.04).
To demonstrate, I uploaded a 3000x3000 album art of Beyoncé's Renaissance. Here's the size comparison between formats in maximum settings:
Now, let's get them to a more reasonable 1080x1080 size. I'm still going to use max settings for this comparison's sake but know that most content providers and most users will likely use less extensive/more compressed settings, so file sizes are going to be even smaller.
When you have to embed them to a file and said file has to be decoded in real-time, it makes a lot of difference, i.e. no lags. I think JPEG XL is the future. It just needs support. And it's happening now. I'm hoping MP3tag would offer support too. It's a royalty-free, open standard too!
The problem will most likely be the support by players.
The id3 standard suggests png and (normal) jpeg - any other format like e.g. gif or tiff cause trouble.
It is not up to MP3tag to set the (id3) standard it uses the existing standard.
MP3tag managed to add support for WebP, as did most players, barring MusicBee. WebP is not in the official spec, but it works. JXL is also backwards compatible with JPG.
If you set the file filter to e.g. *.jxl then you will get also the jxl-files to select and MP3tag will embed that file. (The same happens to gifs BTW.)
So, if you want, you can already today embed jxl files.
Player support is a different thing.
The cover artwork of vinyl "Renaissance" contains strong JPEG artifacts. Best to obtain a copy in JPEG or save as such to avoid spending unnecessary space.
If the goal is to be "decoded in real-time and no lags," then the decoding speed should be considered, which can be observed in IrfanView. The speed of JPEG vs PNG vs JXL Lossless is approximately related as follows: 1 : 2 : 8 . They depend on the final bitrate achieved, but JXL will be quite slow even with a square of the same color.
If you are mousing through a library of many files, you will end up decoding many images at once. It's strange to assume that 30% disk space is very expensive, and yet an infinitely fast CPU is available.
JXL has the feature that it can compress old JPEG even more without introducing more artifacts, without doing reencoding. But it is definitely slower. And few software support the incremental loading which would mitigate that problem somewhat.
But I would love to see more support as it has very good quality.