DirectControlAssumed t1_iufhbtu wrote on October 30, 2022 at 10:43 PM

Reply to comment by emfiliane in Google Chrome Is Already Preparing To Deprecate JPEG-XL by leo_sk5

>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.

emfiliane t1_iufo7gc wrote on October 30, 2022 at 11:32 PM

That's not how kitchen sink libraries work, though; they support a lot of obscure and dead formats with known security problems in the implementation, but none of them are enabled by default. If you want to make a tool that's an everything-to-anything, you turn on all the compile options, and if you make it public, hopefully point out that here there be dragons.

Some binary-only remains might very well require virtualization in the future, the way accessing and converting old Pagemaker files does, but that's something retro enthusiasts seem to relish.

DirectControlAssumed t1_iufqu7f wrote on October 30, 2022 at 11:52 PM

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.

emfiliane t1_iufs7yq wrote on October 31, 2022 at 12:03 AM

Sure, I use j2k (and djvu) every day. 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.

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.

DirectControlAssumed t1_iuftz7f wrote on October 31, 2022 at 12:17 AM

>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.