You are not wrong, I was talking about the "some long forgotten DVD on the attic" scenario when you suddenly find that you used some unusual image format to store your data for archival purpose because, e.g., you wanted to put more images on that DVD and now you don't know how to get it back because the only software that supports it is some Linux CLI tool that requires compilation with right flags to make it work. Or something even more arcane, who knows.

See digital dark age, though I am not talking about intergenerational problem - seeing how fast technology changes today and how more complex it becomes every day makes me think that such problems can happen even within our lifetime.

>it quite literally can't become more compatible.

BTW, it can. There is JPEG XT that is just JPEG + additional data that adds new features. The existing JPEG software that doesn't know about JPEG XT still can read its plain old JPEG part.

You can't open JPEG XL re-compressed JPEGs with the code that supports JPEGs (that is basically omnipresent and will be supported for foreseeable future without any doubt). If you want your JPEG back, you have to decompress it with djxl first.

So, you still have to rely on JPEG XL specific code which can start to "rot" (due to various reasons) with time if nobody maintains it.

Looks like a very good candidate for another grave on the Google's already big product graveyard

>I'm just saying that major public formats don't just disappear, even if they become inconvenient to use; most major obsolete undocumented formats are still usable in some inconvenient way or another.

I agree with that.

> They're one possible format to transfer archived files and scans to, although being business, PDF/A is preferred over any raw image format in this group.

AFAIK, PDF/A-2+ allows J2K images, so it works there too (if you want it) and, as you obviously know, PDF/A exists precisely for digital preservation.

Also, AFAIK, Adobe hasn't allowed any other "JPEG successors" in their PDF standard, either.

Well, compiling stuff with appropriate flags isn't easy for people who are not programmers. Most of them probably would just give up.

Even if that wasn't a problem I still don't like the idea of putting my precious images into the shaky state of dependence on some format that is susceptible to whims of a single company.

In the end of the day Google didn't really wanted ultimate-rule-them-all image format, they just need something that requires less bandwidth from their networks than JPEG. AVIF and WebP seem to be good enough for that role now. But this is basically endless battle - tomorrow they'll start thinking about even more compact formats and will declare JPEG XL/AVIF/WebP obsolete effectively abandoning them. If nobody else takes the burden of their maintenance in their hands, the files using these formats will become a large PITA for their owners.

JPEG 2000 is already here and one of its primary usages is exactly digital preservation, e.g it is one of the preferred formats of Library of Congress (with TIFF, JPG and PNG)

EDIT: https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reasons

RIP JPEG XL, even your own creator hasn't really liked you.

>some utility or another will be around to deal with them as long as the C language survives

...or some nasty security vulnerability is found and related code would be easier to throw away to reduce attack surface rather than maintain because nobody either wants or knows how to deal with it.

It was a lesser problem with historical dead formats that are basically as dumb as P(B,G,P)M (like BMP) but the new ones are very complex because of their advanced compression algorithms, metadata and stuff and require a lot of code to work.

However, as I said in another comment, if you store your images as JP2, there are much better chance to be able to open them in 20 or 30 years than AVIF/JPEG XL/HEIF and other newborn megacorp-backed standards because JPEG 2000 is 20 years old, alive and even is still being developed (e.g. ISO/IEC 15444 Part 15 and Part 16 were published in 2019)!

Have you ever heard of JPEG XR? It was Microsoft's attempt at JPEG replacement that was standardized by ISO too and I'm not sure you can even open such images on anything but Windows (and I am not even sure latest Windows versions still support it). There is a reference codec on jpeg.org that wasn't updated since 2012 and that's it.

>It'll join JPEG-2000 on the pile.

IMHO, JPEG-2000 seems to be the safest bet among all these "JPEG replacements" in a sense that if you store some photos with it for a long time you will not going to find yourself in a situation where the format is abandoned and there will be literally no software to open or transcode the photos in the future

JPEG-2000 is already 20 years old (i.e. U.S. patents on core coding have expired in addition to the fact that it was supposed to be royalty-free since the beginning), there are many codec implementations out there; there are image viewers supporting the format and there are industries that use it very extensively - digital cinema, medical imaging, geographic information systems, digital archives, etc. JPEG/ISO keeps publishing new parts (new features) for the format standard and that means there are people who actually care about it.

It is mostly absent on the consumer devices, yes, but who knows, maybe it will become more prominent since the patents are dead. It is also vendor-neutral unlike AVIF/JPEG XL/HEIF - there is no megacorporation behind it who constantly try to overtake its competitors in format wars. Google (who is the main sponsor of JPEG XL) is especially notorious for ruthlessly killing stuff people use.

I have recently played with JPEG-2000 and found that it has some very nice features. E.g. unlike plain JPEG you can make your image fit into specific size constraints - want to get 1Mb image out of 5Mb JPG? Easy! I also found that its lossless compression consistently beats PNG.

My very limited test also made me question JPEG XL superiority. While lossless JPEG XL constantly beated lossless JPEG 2000, I am not so sure about lossy compression. There are two modes of JPEG 2000 lossy compression (integer/real or reversible/irreversible). While default integer (reversible) lossy JPEG-2000 compression was usually worse than lossy JPEG XL for the same size, real (irreversible) was much better according to PSNR/NCC/AE metrics and directly competed with AVIF (though AVIF was usually better). JPEG-2000 artifacts also looked less ugly than JPEG XL's (though that may be due to the JPEG XL codec immaturity).

I don't know what JPEG-2000 lossy mode people use to make comparisions but I wouldn't be surprised if one of the reason why they find JPEG-2000 lossy performance lacking is that they use default compression settings.

There is also a very interesting thing named "arithmetic coded JPEG". It is a plain JPEG that has its lossless stage (Huffman coding) replaced with more efficient arithmetic coding. It demonstrates significant disk usage improvements over plain JPEG, especially for large images. You can convert JPEGs between Huffman and arithmetic coding without any quality losses - the images would be mathematically equal. This is similar to JPEG XL lossless JPEG re-compression but unlike JPEG XL it is not a brand new format - it is a part of JPEG specification since very long times! The reasons it wasn't used widely are patents that have long expired. Reference codecs like libjpeg supported it for a long time but the feature was often omitted by app developers because of patents so many image viewers still do not support it directly. The lossless nature of such recompression (and the fact that it is a part of plain old JPEG specification) means that you can use it to truly losslessly compress JPEGs for long storage.

I have done limited comparison of arithmetic coding and JPEG XL's JPEG recompression and haven't found absolute winner - sometimes it was arithmetic JPEG who was better, sometimes it was JPEG XL