Submitted by leo_sk5 t3_ygtq5z in technology
candreacchio t1_iub9dpt wrote
Reply to comment by happyscrappy in Google Chrome Is Already Preparing To Deprecate JPEG-XL by leo_sk5
Jp2000 actually has quite a bit of adoption, just not in the spaces you may realize.
All digital cinemas use jp2000 as their compression method (wrapped in a mxf container in xyz colour space)
happyscrappy t1_iubaplq wrote
Your picture is stored in the chip on your passport using JPEG-2000 (US passports).
It's still not much though.
DirectControlAssumed t1_iud7fru wrote
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.
emfiliane t1_iufg1po wrote
The good thing about dead formats is that they're frozen where they stood, instead of having dozens of proprietary and incompatible variations. (Cough, anything IFF-based.) Unless they already made it that far before dying, like PCX. It's the proprietary ones that really painfully disappear, like exclusive Adobe-only formats.
I doubt JPEG XL (or XR or maybe XT/XS, or any other also-rans) will end up in that situation, since they're incorporated into the main Swiss army knife libraries, so some utility or another will be around to deal with them as long as the C language survives. It may not be convenient, let alone integrated into your favorite tools, but nor are most dead formats.
DirectControlAssumed t1_iufhbtu wrote
>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
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
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
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
>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.
ApertureNext t1_iuhy78x wrote
JPEG XL allows lossless conversion between JPEG and JPEG XL, it quite literally can't become more compatible.
DirectControlAssumed t1_iui0sle wrote
>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.
DirectControlAssumed t1_iuhz5ou wrote
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.
ApertureNext t1_iui0xvy wrote
Exactly, so you aren't losing quality if JPEG XL ends up flopping and you need to transfer back to a more compatible format.
Browsers not supporting the format and now dropping support aren't helping.
DirectControlAssumed t1_iuji4g1 wrote
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.
Viewing a single comment thread. View all comments