.jxl is Next-Gen Codecs for the image. I may reduce the large amount of space occupied by images. It is important for anki note. Because Anki relies on network transfers to synchronize cards. Smaller images reduce synchronization time and server space usage. As I know, Chrome can also enable support for .jxl images via chrome://flags. As far as I know, anki is also using chrome core?
Beware that it is a self-claimed next generation image codecs. That article you link to briefly explains the differences between competing codecs, and claims to be neutral, but in fact never provides any source of reproducible benchmarking. Beware that it’s extremely common to have tens of competing standards in a very specific field, each claiming to be the “next generation one”.
Not quite. The webengine of the toolkit (Qt) Anki uses is based on chromium, which is the “base” on which chrome is built.
I disagree on this point.
Even if you added support for JPEG XL, most users wouldn’t even use (because most user have other stuff to do), so from the standpoint of the server, the space saved by users who use this format would be marginal.
Also note that these optimizations where though for web delivery, where you want to pass a lot of data very frequently and want to render it quickly, all this through limited bandwidth. In this situation, having an image that is 20% smaller is very important because the time it takes to load that 20% can greatly impact the feeling of “flow” you have when navigating the internet. This is not the case for Anki, since Anki loads these resources directly from your local storage, which is immensely faster and more reliable. This means that it’s already instantaneous, and that you won’t feel the difference.
Besides that, media synchronization does not “block” the user, it happens in the background, so it’s relatively safe to say that a huge share of users wouldn’t even notice if that sync took twice the time it currently takes. Attempting to decrease that time by a bit would really be of marginal benefits.
This is why, all in all, I don’t think it would be very beneficial to add support for the JPEG XL format. But there is an other aspect to be considered, that is, how to actually add that support, because it’s not actually Anki’s responsibility to do so, but the toolkit it is built on. Currently, I think it doesn’t support that format natively, but there is a Qt plugin to add that support, so if you really want that feature, I think you could just install that plugin. Beware that I haven’t tested if it actually works.
2 Likes
It’s very nice to receive such a serious reply from you. I won’t stick to my opinion, I’m just telling some of my thoughts and observations. After all, I am a deep user of Anki myself, so I hope Anki becomes better
1, I’m a photo processing professional, and there is no doubt in my own mind that .jxl is the next-generation image codecs
2, According to the wiki, QT officially supports .jxl now
3, I know that when Anki browses the card is not actually get the image from the server, but directly from the local. But when synchronizing the data, the local images have to be taken from the server, and as a Chinese user, it is very necessary to reduce this amount of data, because it is often difficult for us to access the server.
1 Like
For vector images, .svg will probably last for many years. But for bitmaps, the .jxl revolution will come in the future.
Until it works out of the box on all the platforms Anki supports, adding it will just lead to headaches when people share decks that don’t work on other systems. Maybe it’s the future, but I don’t think it’s ready yet:
2 Likes