JPEG XL

they organized contest that led to selection of Pik and FUIF teams and i think gave some input about codestream details

but saying that they created it is disingenuous

or well. it's not JPEG who's claiming it so i guess just incorrect, not disingenuous

well I mean it in the loose sense of the word

in loose sense of the word google developed the most of it...

while they did not develop it, they put their stamp on it. so it's officially part of the JPEG specifications

yeah i just think that that sentence could be improved

somehow

🤔

or replaced by something more useful than giving authority to JPEG because im not sure if that's actually something what people consider hip

yeah I agree

kinda nitpicking here though, its not really too incorrect and is probably fine

Both Cloudinary and Google participated in JPEG to turn their fuif and pik proposals into what became jxl, between 2018 and now (bitstream finalized in 2020 but the spec work is still going on, as well as the work on libjxl).

The original JPEG format was designed in the 1980s (based mostly on technology from the 1950s, 60s and 70s). I don't think any of the current JPEG members were already around back then.

Yes, I was able to very easily use `declarativeNetRequest` to set the `Accept` header appropriately. Now I’m currently trying to decide what the best way is to *detect* JPEG XL images in pages to replace appropriately. I spent a lot of time considering various options, and I feel like the best approach might honestly be to intercept `error` events in `<img>` elements through a content script and reissue the request, then check the `Content-Type` header appropriately before trying to decode the body. This has the added benefit that if browsers start supporting JPEG XL, this will work entirely as a noop. The drawback is that requests are made twice (though only until the headers are received), and can also be made to images that are not JPEG XL. I’d also have to make sure to handle `<picture>` appropriately. Honestly, it might not be necessary to check the `Content-Type` since decoding would otherwise fail, but it might be a good idea to enforce it anyway. E.g. in case someone is using the extension to test their own website, it might be misleading if they are able to get away with an improper `Content-Type` for their JPEG XL images, since that isn’t meant to work.

I suppose I could elide it altogether. Or perhaps say it was “published by the same comittee” (talking about the specification), which (unlike saying “group”) doesn’t seem to imply the same people who worked on JPEG also worked on JPEG XL. I suppose I just wanted to clarify why it’s called “JPEG XL”, and that it’s only related to JPEG (the format) by legacy (i.e. that it is a different format).

It's historically confusing that the committee and the file format use the same acronym

like MPEG? 😛

<@171381182640947200> How fast is the decoder in the extension? Is it as fast as libjxl?

nice! I'm guessing it could be possible to use the same API to block the initial request for the <picture> use case to prevent double requests (kinda like an adblocker does)

no, it's like a portable wasm version <https://github.com/niutech/jxl.js> so it's not like native support also on the test page something strange <https://jpegxl.info/test-page/>

MPEG is a little different, people know mp3 and mp4 but maybe not so much the original mpeg video codec, since it was mostly used in broadcast and other use cases where you don't really get to see the files as an end-user...

MPEG2 is the first one you start seeing files for.

That looks like it renders at dpr1 (so 2x upsampled on a dpr2 screen) even though the html says it should render at 1:1...

Oh, I thought it was literally libjxl in an extension.

No native code in chrome extensions since 2014 😔

Well actually NPAPI was superseded by PPAPI but that was removed in 2020

I thought native code was in addons. Flash, JavaApplets, etc

Well, it *kinda is* “literally libjxl in an extension”, since jxl.js uses Squoosh’s build of libjxl. Now, I have been working on updating the extension to suit its own use cases better instead of using jxl.js, so I decided to build libjxl to Wasm myself, and I have been writing the necessary glue code in JavaScript. Some thoughts: - Using error events seems to work fine! - I still need to implement conversion to sRGB from other color profiles. (I’d love if someone offered to help with this.) - I still need to make it run on a worker rather than on the main thread. (Should be fairly straightforward.) - It seems some JPEG XL images are being served as `application/octet-stream` on jpegxl.info, even though I’m sending the correct `Accept` header, so I disabled MIME type checking for now. - It seems some images are failing to load! At least all the images in jpegxl.info/art seem to be fine, but others might not, not fully sure why (and libjxl’s error reporting is a bit sparse). - I still need to make it handle `<picture>` correctly again, as well as CSS backgrounds and borders, etc., and perhaps SVG `<image>`. - I still need to upload what I have somewhere! 😅 - Once I can solve the regressions, I can submit version 0.2 to the Chrome WebStore and Mozilla’s addon listings. - It might be nice to eventually support animations, though I’m unsure about how trivial that would be.

Also, an interesting way to make the extension even better would be to somehow have a way for the extension to view JXL images that you drag into the browser.

Also to open local jxl files in browser

wouldn't lossless webp be better or would it be slower?

lossless webp still only supports 8 bit huh? (Hmm, I wonder, maybe with some dithering and an appropriate color profile, could 10-bit be dithered down to 8-bit without anyone noticing the difference on a good monitor? Visually lossless?)

nobody can notice 10 bit

it's only hdr but that's a different problem

8-bit sdr without dithering can have some noticeable banding on displays that go bright enough...

uhhh no. with dithering u can get close enough but still not exactly the same

if u look for it u can notice

not that many look for it

unless its made obvious w no dithering and sky gradients

8 bit yuv is obvious

8 bit rgb is arguable even up to 600 nits

<@456226577798135808> had some example images where 8 bit rgb has visible banding on my 400 nit or so screen

i guess we have to use avif <:trollface:834012731710505011>

So, some more thoughts: - I spent way too long trying to figure out how to separate the processing into a worker. It turns out you can’t just create a worker with an extension URL at all! I tried some wacky things such as using `iframe` instead. But then I realized it was working on the existing extension, so I went to study how it managed to do that. And apparently, it just works completely normally if you instead use `importScripts` from a `data:` or `blob:` URL. The caveat is that then the worker will have that URL as its base URL (and also its origin), but other than that, it works completely fine! - I feel like the number of images that don’t seem to be working is actually worringly high. I need to figure out what I’m doing wrong, but I honestly just compiled libjxl with Emscripten and followed pretty much every example I could find to the dot, so I don’t know why it just doesn’t work for some images. - Maybe it’d be worthwhile to set up a proper repository for it, instead of uploading it to a GitHub Gist. - I made it work with `<picture>` through `MutationObserver`, but maybe I should make CSS out of scope for it. - I still need to figure out how to convert images to sRGB in case they aren’t.

The extension currently converts images to 8‐bit per channel sRGB always. And by “currently”, I mean that WIP one I’m working on, and also the one uploaded to the Web Store / Mozilla Addons.

I don’t think it really matters that much, since the images are only kept in RAM.

I have used extensions that can affect the “image tabs” before, so at least I know it’s possible. I could definitely investigate it.

what ever is the point of 10-bit then?

depends on the context and who you ask

but for images on the web, 🤷‍♂️

I mean for HDR images displayed on a good monitor

also HDR on the web is practically non existent right now but eh

Higher bit depth is necessary for hdr

because of how it has been defined

can't wait to scroll down a discord chat and get flashbanged

I don't think there is a way to define hdr without higher bit depth. Transfer curves can do a lot but ultimately if you want more dynamic range, then you also need more bits.

lol

shouldn't it possible to detect if the jxl is 10 bit, along with resolution, and save it as a png if webp can't support the image?

Is sRGB (0, 0, 0) meant to be absolute blackness? Or it's meant to be slightly illuminated?

It's supposed to be absolute black

SDR content like SRGB has a black level and a white level

and a constrast ratio (typically 1:1000)

which is the absolute light level of black to the absolute light level of white

true black is only for HDR, not for SDR

In the real world, true black cannot be produced - especially in a not perfectly dark room...

Would it be possible for the JPEG XL images on jpegxl.info/art to be served as `image/jxl` rather than `application/octet-stream`?

I don't think so — it's hosted by github pages, which apparently does not know image/jxl yet

Maybe we can open an issue about it somewhere? I don't know where though

Well, I recently made a repository for my extension, and also made a new release candidate available! <https://github.com/zamfofex/jxl-crx/releases/tag/v0.2-rc1> Please do try it out and let me know whether it works well, as well as your thoughts. Note that I still haven’t warted out those issues I was running into, but it can be done in a later version if it’s not too disruptive. Also note that I uploaded the build results to the release page, but if anyone wouldn’t mind trying to build it, I’d love to know if anyone runs into build issues so I can resolve them. Note that I can’t test it on Firefox (because I don’t have it installed) and because `OffscreenCanvas` is not available in IceCat yet (since it is based on Firefox 102 ESR), so I’d love to know whether it seems to be working fine. (I could resolve this later too.)

challenge accepted ! I'm sure we could have hdr on a floating point format defined on 8 bits 😄 higher dynamic but lower resolution at the same time 😅

They should both work the same. The manifest v3 one doesn’t currently work in Firefox (as far as I know), whereas the manifest v2 one cannot be uploaded the the Chrome Web Store.

It’s the same for v0.1, where it will be mv2 for Firefox, but mv3 for Chrome.

seems on the way : Firefox is adding support for Manifest Version 3 (MV3) extensions in Firefox 109, which releases to general availability January 17, 2023 https://extensionworkshop.com/documentation/publish/distribute-manifest-versions/ even if I still don't understand what is a manifest...

Accepted jpeg-xl 0.7.0-9 (source) into unstable: https://www.mail-archive.com/debian-devel-changes@lists.debian.org/msg785751.html

Did you end up trying the extension out? Did it seem to be working well?

if I understand well, the mv2 should be usable with firefox ?

I really don't know how 😅

Yes! In `about:debugging`, in the “This Firefox” tab (on the left), you should see an option “Load Temporary Add‐On…” that you can use to choose the ZIP file.

noice, I try

amazing ! would it be hard to add it to the store ?

It would not! Does it seem to be working well enough? I found that it didn’t work for some JEPG XL images (more so than the v0.1).

Didn't test extensively yet, i guess it must be reloaded this way each time I restart firefox ?

Yes.

If you prefer to install it more permanently, in `about:addons`, you can select “Install Add‐on From File…” in the cog menu.

But it might not work because I didn’t add an extension id to it yet. 🤔

nonetheless ! nice piece of code, I'll try to use it a bit (which version of libjxl run behind ?)

Commit `b94f43527b36d9fc5bcb367164c7a9379f166daf`

In case anyone feels like they wouldn’t mind taking a look (in case there is something immediately obvious), this is how I use libjxl from the extension: <https://github.com/zamfofex/jxl-crx/blob/v0.2-rc1/worker.js#L44-L76> A lot of images are failing under either the first or second call to `JxlDecoderProcessInput` for some reason. The return values seem to always be (very nondescriptively) just 1 (`JXL_DEC_ERROR`). I suppose I could try making those calls from C or C++, but I don’t think it should make a difference, right?

if you use a debug build it prints the error to STDERR

which is nice for debugging

Ah, I see! Is it sufficient to elide `-DCMAKE_BUILD_TYPE=Release` from the call to `cmake`?

change "Release" to "Debug"

as release is the default

upon further inspection you're not calling things in the right order

Oh? 🤔 Which things, specifically?

you call JxlDecoderSetInput first, then you call JxlDecoderProcessInput, and then you call JxlDecoderReleaseInput

JxlDecoderSetInput passes a buffer, JxlDecoderProcessInput returns a status flag

and JxlDecoderReleaseInput returns the number of bytes that it **didn't** consume from the buffer

i.e. the number of bytes you passed it that must be fed again

and you do this in a loop

I see! 🤔 But I didn’t see anything that actually needed to do that at all. In fact, the source of the previous Wasm binary didn’t, for example. It was taken from Squoosh: <https://github.com/GoogleChromeLabs/squoosh/blob/dev/codecs/jxl/dec/jxl_dec.cpp>

strictly speaking JxlDecoderReleaseInput is optional, but it is required if you want to call JxlDecoderSetInput again

In my case, the whole input image is passed in at once, so I shouldn’t need to make multiple calls to `JxlDecoderSetInput`, right? (I even call `JxlDecoderCloseInput`.)

that should be correct. however, you also do this: `Module._JxlDecoderSubscribeEvents(decoder, 0x1000)`

`if (Module._JxlDecoderProcessInput(decoder) !== 5)`

You aren't subscribed to events `0b101`

in particular, it's probably *never* going to equal 5

because 5 isn't a flag

It says on the documentation that only events after `JXL_DEC_BASIC_INFO` in the enum need to be subscribed to, but `JXL_DEC_NEED_IMAGE_OUT_BUFFER` (5) comes before it. Note that this does work just fine for some JPEGL XL images, just not for some others (maybe most).

it's very possible that BASIC_INFO event fires before NEED_IMAGE_OUT_BUFFER

if the JXL image is small enough

in fact it frequently *will* fire first, because the image out buffer size depends on the basic info, usually

maybe always

I actually found that the very small images in jpegxl.info/art (except for one of them) all work fine, but other larger images don’t seem to.

either way if you use a debug build you'll be able to see exactly what libjxl doesn't like about what you're doing

Thank you for your help, by the way! I really appreciate it.

Well, it seems that (as a surprise to probably no‐one) I am actually stupid. Turns out everything was working as expected, it’s just that support for `<picture>` was broken, so it was actually trying to load the fallback images into libjxl. Since I did most of my tests with `<picture>`, it’s no wonder they’d all fail! However, the failure with the image in jpegxl.info/art was legitimate, but I’m assuming it’s some change in the defaults of limits of the library, because the error I get is “Too many pixels covered with splines”, which seems like an explicit limit set to avoid performance exploits rather than an actual problem with the image.

So does <picture> work now?

Yes! I was just updating Firefox on my other computer to test things out on it, and I should be able to push my changes soon, and eventually upload it to the Chrome and Firefox extension repositories! I think everything’s working as expected (and wanted) by now, except for CSS and SVG `<image>`.

yeah that's correct for some of the jxlart images

<@171381182640947200> the extension is pulling APNG (breaking animation) & PNG and blobbing them to.

What do you mean by that? It shouldn’t even be able to do anything to PNGs at all, and specially not converting them to blobs.

I can see how it might be able to affect PNG `<img>` elements, but not how it would be able to make them into `blob:` URLs.

Retested must of been a fluke.

Sorry for the ping. <:NotLikeThis:805132742819053610>

https://github.com/SimpleMobileTools/Simple-Gallery/issues/2669

I think this could be fixed by looking at the currentSrc property (it's a read-only property) of the <img> -tag and then doing a search and replace in the srcset from the currentSrc URI to the blob uri. so that at 2 DPR ``` <img src="something.jxl" src="somethingelse.jxl 2x, thirdimage.jxl 2x" alt=""> ``` becomes ``` <img src="something.jxl" src="blob:https://jpegxl.info/0b38d852-354e-47e4-8322-935408afcdb8 2x, thirdimage.jxl 3x" alt=""> ```

https://www.phoronix.com/news/OpenMandriva-ROME-23.01 "there is JPEG-XL image format support added,"

Basilisk browser now has JPEG-XL support too

*Updated.

Openmandriva had JXL support ever since 4.3.

Reading the PKGBUILD for the ffmpeg-jxl AUR package is a little disheartening... (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ffmpeg-jxl) > Maintainer: raine > > Q: Why does this package exist? > A: Unfortunately, current ffmpeg package maintainer Maxime Gauduin is refusing to enable JXL support that is available in ffmpeg, and all discussions are currently being shut down with replies disabled, without giving a chance to respond to his opinionated decisions. > A few examples of issues that got shut down: > - https://bugs.archlinux.org/task/75830 > - https://bugs.archlinux.org/task/75982 > - https://bugs.archlinux.org/task/76106 > - https://bugs.archlinux.org/task/76277 > in some cases with some cheerleading from another package maintainer: > - https://bugs.archlinux.org/task/76643 > > The given reasoning is > - libjxl is in [community], I'm not bringing and maintaining that package and all its dependencies in [extra] > - depending on libjxl brings 47.6MB of additional dependencies > - there's ffmpeg-full, aka ffmpeg-bloatfest in AUR

it took arch linux several years for HTTP/2 support in cURL

they just decided users didn't need it

I was wondering what was the current position of cloudinary ? will they use jpeg-xl internally, despite the rebutal from Chromium ? will they push for an optimized jxl.js or an extension as I saw here ? or on the fly conversion to jpeg ?

We use it internally. Externally, using polyfills is not really an option for most of our use cases, since we only control image delivery, not markup generation. Our customers pay us to handle their images so they don't have to worry about them, so asking them to implement stuff on their end is generally not something we do.

If a browser gets full default JXL support, will you activate browser JXL support?

as far as I'm aware they send JXL provided that the browser sends image/jxl in the accept header

which will happen sorta by default once browsers start supporting jxl images

That sounds like it would help advertisers with browser fingerprinting

wym

It very much sounds like the opposite

It means that browsers that send the Accept: image/jxl header would probably be more unique because not many browsers send that header.

At least, until something like Chrome supports JXL and a few update cycles later 70% of the web supports it.

https://github.com/WaterfoxCo/Waterfox/pull/2936#issuecomment-1379087536 Waterfox has finally actually implemented JPEG XL by default. (PR for disabling Nightly check got merged)

For animation, transparency, progressive decoding, and color profiles, there is still some discussion going on: https://github.com/WaterfoxCo/Waterfox/pull/2938

it seems like MrAlex94 might not be aware that those changes are not actually in firefox

*but if it's supported by default it's not really narrowing down anything other than users simply having up to date browsers?*

Honestly, it's probably not much worse than just reading off the User-Agent, so while in *theory* it does "help fingerprinting", you're right, it just identifies the user as having an up-to-date browser, which you already know by the User Agent.

exactly

Unless you're spoofing that for some reason, then it might affect things.

If you have jxl by default and you *disable* jxl, that's a huge fingerprint

ye I don't see how it provides more info than user-agent

Is this applicable to Waterfox Classic too?

palemoon's support for jxl could be used as a base to add support to waterfox classic

At the moment it's opt-in, customers who want to already send jxls to (the small set of) user agents that can decode it, they can, but it's not enabled by default since with such small amount of browsers supporting it, customers likely don't want to pay for additional encodes and storage just for 0.something percent of viewers... Once a big browser enables by default, we will likely reconsider that — though atm even avif isn't enabled by default yet in f_auto iirc.

To be fair, pretty much EVERYTHING about "the web" helps advertisers with fingerprinting. Because "the web" was never designed to have... any kind of design at all. It's just an ugly, throbbing tumor at this point, with mysterious "leadership" team at Google that is unknown and unaccountable to anyone else, that decides what "the web" is or isn't these days.

It didn't start off that way but that's what the tumor grew to become.

The modern web is an atrocity and should have been replaced a long time ago with something that isn't designed to run scripts on your PC without user approval or interaction by default.

But it's probably no coincidence that the modern web is designed to give advertisers and other malevolents everything that they want, and at the same time Google has near-total-control over the design of the modern web.

I would imagine that's no coincidence at all.

rbyers@chromium.org updated this feature: JPEG XL decoding support (image/jxl) in blink Components: Blink>Image Implementation status: Proposed Estimated milestones: No milestones specified Changes: feature_notes: old: new: Had an experimental implementation in chromium behind a flag, but that was removed. https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/xX-NnWtTBQAJ impl_status_chrome: old: In developer trial (Behind a flag) new: Proposed

So it went from "In developer trial (behind a flag)" back to "Proposed". Does that mean anything? Is this good news (it's still "proposed", not "deprecated" or something), bad news, or neutral/no news?

I’d imagine it’s just reflecting the fact it’s not available behing a flag anymore.

Yes, clearly that status needed to be updated. Just not sure if what kind of choice they had in what to change it to, and if it means anything.

This is application from KDE Maui Project called INDEX. Running on Android. With patched Qt (to know new mimetypes) and Qt plugins for AVIF and JPEG XL it is my first APK for Android.

<:Hypers:808826266060193874> https://github.com/WaterfoxCo/Waterfox/pull/2938

finally another browser with jxl

I first saw this through an announcement on the av1 discord lol

there is one place I out found out very recently that has waterfox jxl crash though https://kampidh.com/jxltests/

That's a nice test page, hadn't seen it before.

So we now have Pale Moon, Basilisk and Waterfox supporting jxl by default. Feels like momentum is building, but in terms of market share that's still of course only 0.something percent atm...

Cool! Where can we find it?

oh wait that's the old domain, only used as a backup and testing around (and often down, haha)~ the public one goes right here: https://saklistudio.com/jxltests/

oh lol

huh, has extra buttons on the backup one, and kampidh.com points to that one being a mirror site

yeah I assumed that "kampidh.com" was the main site and that "saklistudio.com" was the backup site because of that

yup

"kampidh.com" is the one I have been sending around to people since I thought it was the main one

it was the main one, but since it's self hosted and the connection wasn't so great here, I moved it to a remote host~

I haven't migrate all of them xD

I would like to note that the crash that happens on this page might be fixed with a one line code change however I have not had the abllity to get any custom compiled builds of waterfox to test with

there may be a more proper fix however It is out of the realm of what I am able to do

What about librewolf? does that support jxl?

I might I think I remember seeing something related to that however if it does it's only the very basic support from default firefox

I found original APK here: https://download.kde.org/Attic/maui/index/2.1.2/ apkanalyzer indicated: <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="28" /> Binaries in the APK used armeabi-v7a and Qt 5.15.2 so I tried to build plug-ins using the same. It is not enough to add libplugins_imageformats_qavif_armeabi-v7a.so and libplugins_imageformats_qjpegxl_armeabi-v7a.so . Images will not show without proper mime type detection. It was necessary to add XML from shared-mime-info 2.2 and rebuild libQt5Core_armeabi-v7a.so I used apktool to extract and build the APK again and apksigner to sign APK at the end. I am new in Android development, but API level 28 indicate Android 9 (21 is Android 5.0). ARMv7-A is 32bit, so I believe it should work on old devices. I have Android 11. The The Pix image gallery from MauiKit can be extended in the same way, I believe.

The Index file manager http://188.121.162.14/jxl/index-2.1.2-avif-jxl.apk Pix image gallery http://188.121.162.14/jxl/pix-2.1.2-avif-jxl.apk

both working well for me, sony xperia 5 ii, android 12

> Hey Jon, Your email was indeed received, thank you for the feedback!

so it's not going to /dev/null, that's good to know

I saw that reply and basically facepalmed 😛

Waterfox new supports JPEG-XL! (minus HDR images) https://www.waterfox.net/docs/releases/G5.1.2

it hasn't been pushed to the update system yet but can be downloaded from here https://www.waterfox.net/download

I have found out the image crashing waterfox on that page is this https://saklistudio.com/jxltests/beach-cmyk.jxl

yeah it insta crashes on load

(wanna make it clear for anyone reading that the whole browser doesn't crash just the tab that tries loading the image)

ah, should I remove that cmyk test?

no

hmm, maybe 5 channel triggers it? it's a CMYKA image (although I didn't use any transparencies)

it just exposes a bug that should be fixed, i need to get waterfox building again and debug it

gotcha

though it really doesn't want to build anymore for some reason lol

strangely the crash doesn't happen with this custom build of firefox which includes all the jxl patches https://dist.grass.moe/firefox-108.0.en-US.win64.installer.exe which leads me to believe that the fix for the crash is either a one line fix or newer versions of firefox fix something internally that was causing the crash

or maybe something to do with the icc?

eg. before I was worked with krita's cmyk jxl support, it often triggers segfault when the output is expecting RGB but being fed by CMYK icc instead. had to properly detect whether it's really a CMYK jxl file or not.

What's the difference between waterfox and librewolf?

librewolf seems like it is just firefox with increased privacy and changed default settings along with being bundled with ublock origin while waterfox is similar but has a little bit less of a focus on privacy compared to librewolf but has better privacy compared to firefox and waterfox is bundled by default with the lepton theme (previously called firefox ui fix) and also some extra features like an unload tab button, restart button and optional status bar along with options to change the tab bar and bookmark bar positions also librewolf is based on the current lastest version of firefox while waterfox is based on the current esr version

basically waterfox is focused more on features while librewolf is more focused on privacy

atleast that's what it looks like to me

what's lepton/ui fix

https://github.com/black7375/Firefox-UI-Fix/

unload tab is increadibly useful... mozilla is so incredibly incompetent and full of fail for not doing basic things like that to make things better and simpler, for ignoring basic fix patches for JXL for over a year, and for shoving Pocket(TM) down our throats...

oh another feature waterfox has is private tabs so you can have normal tabs and private tabs in the same window

Also for ousting the founder and creator of Javascript, that was a pretty bad move too...

And firing all of the developers working on the next gen browser engine... Mozilla is basically if Fail was a company

They don't care about building a browser at all.

It only exists to collect donations and privacy-invading sponsorships and liquidate their reputation.

they keep doing random things that don't make sense like colorway for example

Completely sell what remains of the reputation they have built over the years that they used to earn

Whatever makes them money. And then the crazy corporate leadership either pockets it all or blows it all on whatever their latest pet project or political activism is.

Instead of paying developers

Embarrassing sellouts.

I doubt any of the people in charge now even know how to code.

Can you make a similar log with original https://download.kde.org/Attic/maui/index/2.1.2/index-2.1.2-signed-stable.apk ? Then we can report it to the developer. One problem I see is: dlopen failed: cannot locate symbol "__register_atfork" referenced by "libpoppler_armeabi-v7a.so" Probably that library (which is in INDEX and not in PIX app) needs API level 23, Android 6.0

Is it just me or is their release notes for G5.1.2 404'ing

No, worse: it's temporarily 404'ing <:monkas:853502640967909376>

Hashtag just jamstack things

creating javascript seems like fair grounds to fire someone

Haha, yes, but he originally was going to create a different language but the higher ups told him "Hurr durr make it object oriented, our shareholders want to ride the Java hype train!"

We could have had a dialect of Lisp be a popular language. But instead we have JavaScript.

at least it is a very good outcome for a week's work, its core design didn't change for 2+ decades

Yeah...

That's why firing him made no sense at all. Just a really stupid stunt and the beginning of a trend of firing developers and driving mozilla into the ground by wasting all their money on whatever ego-driven pet projects the CEO feels like instead of paying developers to work on Firefox.

mozilla used to hire a lot of software developers.

All that is a waste of money now apparently, in the eyes of the current leadership

That's why it made no sense to fire him, I mean.

Actually I don't think he was actually fired, but some really loud and ambitious power-thirsty idiots in high places were demanding that he step down and he did I guess.

that increasingly sounds like off-topic though

are we just gonna gloss over his homophobia and how he then went on to create a cryptocurrency scam? I'm not so sure he would've made a good CEO.

> Whatever makes them money. And then the crazy corporate leadership either pockets it all or blows it all on whatever their latest pet project or political activism is. > Instead of paying developers the political activism is done by the foundation, which has wholly separate funding from the corporation that develops the browser.

why would you want lisp

lisp is just `)))))))))))))))))`

compare that to JS, which is just `}); }); }); }); }); }); }); }); `

much better!

Always sad to see consequences of Chrome's decision out in the wild.

Overall VLC-like image viewer/gallery for android that doesn't rely on OS decoders would be nice: with jpeg2000, tga, tiff, etc. support. There's this: https://play.google.com/store/apps/details?id=com.sharpened.androidfileviewer , but it doesn't support jpeg xl and is not freeware.

https://forum.palemoon.org/viewtopic.php?f=1&t=29363

So Bankowski (on2, Google) seems to be speaking a lot for other people, when he announced the decision of dropping JPEG XL. "WE decided... WE heard from OUR PARTNERS..." But he seems to only be speaking for himself and is simply using this weasely language to avoid taking responsibility for the decision and make it sound like he's acting on behalf of nebulous "others" without specifying who any of them are. Later on other Google members say "until leadership decides..." and Bankowski is in a senior-leadership position on the Chrome codec team. So just judging by appearances, this looks like a unilateral decision by Mr. Bankowski.

Everyone else seems beholden to his whim and apparently he is our God who through his almighty wisdom alone determines what media formats will be successful and when to delete a huge chunk of other peoples' hard work from the Chromium source tree. He also led the technical engineering teams that brought the world WebM and AVIF.

Previously known as MKV and MOV

I doubt it was a unilateral decision by a single person, there are likely more high-ranking people in the Chrome codec team who also wanted jxl out in order to better promote avif/aom.

(He also helped lead the VP8/9 and AV1 codec development teams as well.)

Maybe? But since all he says is weasel language like "We" and "Our Partners" and he's the only one with a Senior Leadership role saying anything, I have to assume he's only speaking for himself...

On2 was acquired by Google and many of the ex-On2 ended up in the Chrome codec team, working on vp8, vp9, av1.

https://en.wikipedia.org/wiki/On2_Technologies

Matt Frost is also a high-ranking Googler now and chair of AOM

Yaowu Xu also has a high rank in Chrome

I never imagined that the On2 codec team would see JXL as a "threat" or as competition...

Pretty sure Jim/James/whatever he goes by these days is still Yaowu's supervisor.

And so he takes responsibility for whatever his team does.

Or at least supposedly

I think they consider AOM to be a strategically very important alliance (and it is, and in principle a noble one too: getting hw and sw companies aligned to implement royalty-free codecs instead of the patent-encumbered stuff coming from MPEG is quite nice).

JXL being successful would in their minds be a blow to the AOM.

Nevermind that JXL is also royalty-free, it is coming from JPEG which in their minds is the same thing as MPEG: they're in the same subcommittee of ISO after all...

Maybe he was hoping that AVIF will be in digital cameras and the default picture taking format on Android but if JXL became popular with its ability to losslessly crush existing JPEG those dreams would be squashed...

I dunno, it's silly to speculate because it's such a ridiculous way of thinking...

They were never competitors... Everybody wins either way with either format.

You have to sign a contract with Google to contribute to libjxl, libjxl is a fork of the Google PIK codebase, it's basically a Google product more than it is a JPEG product...

I do think that if jxl gets traction, it will be harder for avif to get traction (except for the animation / gif replacement use case), and in a way that would reduce the power/influence of the AOM over web codec standards.

I don't think this was ever about Google's bottom line or anything like that. I think it's more about the strategic goal of getting codec standards creation out of the hands of ISO and into the hands of AOM.

Both have problems imo: ISO is an arcane bureaucracy, has a paywall policy, and stays neutral on patent policies (allowing trolls to put patent-encumbered stuff in standards). However ISO does imo have the benefit at least in theory that anyone can participate and the process is quite open and transparent (although also quite arcane and slow).

AOM on the other hand is an industry alliance, i.e. only (big) companies are represented and the standardization process is not necessarily very open or transparent (it's basically a matter of negotiations between businesses when important scope/design decisions get made).

I think a hybrid solution is doable: AOM steers the standard development, ISO verifies and approves the standard. a good example is Unicode which is an industry standard but also synchronized to ISO/IEC 10646.

Yeah but JPEG doesn't want to be just a rubberstamping committee. They did that with JPEG XR and they still regret that.

what Unicode and ISO/IEC 10646 do is not just a rubberstamping AFAIK though

national bodies are only in ISO and not in Unicode, and yet will give feedback and opinions to Unicode (to make the eventual approval smooth)

AVIF was submitted as a proposal for JXL, and I think they were looking for getting it rubberstamped. JPEG made it clear that they wouldn't do that, that they would open up the spec for discussion and likely change things, and then the AVIF proposal got retracted, likely because hw design was already underway and they didn't want to endanger that.

sure, at this point Unicode can probably live by its own without an ISO approval, but there's no reason for Unicode to do that

yeah that sounds like an AVIF's fault to me

maybe Unicode was successful at that because Unicode is an incremental, "ever-changing" standard

even after the basic design and principles are set, national bodies can reasonably pitch their opinions

yet another example coming to my mind is PNG, which is also an industry standard cum an ISO standard, to my knowledge with almost no change

I don't want ISO or AOM to be in charge of anything.

I don't want gatekeepers and rubberstampers. I just want whatever has merit to succeed without politics to interfere with that.

So many people were literally just waiting for JXL support to be enabled by default. Why should everyone have to bow down to the whims of someone's ego?

And throw away all of the hard work and man hours prepared in anticipation

Deleting the implementation from the source tree was very senseless and spiteful. That code had undergone a lot of patches and polish to get to the state it was in before it was just deleted on an arbitrary whim.

Doesn't JPEG have any power to help with adaptation, e.g. some media campaign? (e.g. in collaboration with Adobe) ... also for the Chrome discussion - enforcing own first WebP, now AVIF for the entire Internet ...

reverting the commit that deleted it all is easy enough 🙂

JPEG itself is not going to do campaigning for adoption afaiu, they can put some info on jpeg.org but that's about all they can/want to do. But perhaps we should get some of the companies who did show interest in jxl (Adobe, Intel, Meta, etc) and people from foss projects like Gimp/Krita/Darktable/ImageMagick/ffmpeg together to brainstorm on a strategy to promote jxl adoption.

Indeed many players could help with such campaign, however, JPEG seems the best as its main face. JPEG2000 was their last widely adapted codec from 2 decades ago, and JXL brings a real hope - but some organized action seems necessary. Somehow MPEG was more successful with HEIC adaptation ...

I'm not sure how well an awareness campaign is going to work if the google decision is more of a political one than technical one. I think most consequential way to improve adoption would be to have jxl support in other browsers such as firefox and safari (especially on mobile)

if adoption is high enough and chrome is the only browser without support it could be enough to force google's hand so they would have to revisit their decision

fun fact, yesterday was the fist time I saw an avif image in the wild, it looks like bilibili is using the format in their video thumbnails. at least to my knowledge the avif uptake has been really slow because of the issues with the current encoding speed

Political decisions are often changed with media pressure - such campaign should also stimulate discussion about that decision, revisiting it in more open, objective way

I have seen at least two articles by CDN companies saying they are not supporting AVIF yet due issues related to slow encoding speed

If only a large program like Photoshop or Firefox would officially add JPEG XL support. That would probably be enough for most mainstream media to at least mention the whole Chromium JXL debacle.

was also wondering about that

Or have they already done so?

I think we can hope for official jxl support in Adobe products before the end of 2023. I am hoping Windows and MacOS will follow once Adobe adds support.

Hopefully Adobe and OS support will help JPEG XL not become the "WebP" of image formats: technically superior but annoys everyone who uses them because of a lack of software support.

I think Intel&Co are already negotiating with other companies behind the closed doors, because they want JXL's HDR capabilities.

Well, JPEG XL's main use is also for web delivery, but it is good as a general-purpose image format nonetheless.

<@794205442175402004> any update on this or can you still not share details? (I know <@456226577798135808> was asking the same above but i'm not sure if you noticed the message link as the message you responded with was in response to the prospect of adobe supporting jxl)

People on Twitter complain quite often that they downloaded an AVIF picture from a website and it doesn't work for them like JPG and PNG. There are still some people who don't know to open WebP. When people start to complain about JXL, that will be a signal it is used on web. People wish the websites use old formats only when their software doesn't support it yet (instead of demanding support from application vendors).

No updates yet at this time.

webp was not even technically superior...

well it is with lossless at least

thing is it lacks support for higher resolutions and higher bit depths

yeah that is an issue with it

A myopic format that was forced down everyone's throats

we should get blender to add jxl

blender already adopted jpeg 2000 for output

if someone put together a well made pull request it's likely it would be accepted

or well hopefully it's likely to be accepted

I haven't looked into blender's history with stuff like that

🤔

not too surprised by that one, jpeg 2k is used extensively in digital cinema right?

i've never looked into blender's source code before

Has Firefox given the green light to JXL? 👀

As far as I can tell, no change in their stance whatsoever.

This fork of jpegview added jxl support some days ago

https://github.com/sylikc/jpegview

What does "worth prototyping" mean? https://github.com/mozilla/standards-positions/pull/523/files/a124bc20ac53dbfa60b5bef5ad5d6f7ac8b70904

Nothing since even that pull request is not getting merged. The recent approval means nothing, anyone can approve it (I just tried).

Seems like a permission issue, it's likely will be fixed

When are they going to merge the damn patches that have been sitting ignored for years that fix basic bugs in the firefox JXL decoder?

probably never I would assume they are just gonna remove jxl support altogether at some point

Might as well if they "don't have enough manpower" to click the merge button on patches that are already written

If they can't fix basic bugs

This is shameful and embarrassing that it's been like this for years and the fix is already written and proposed and all they have to do is click "merge"

mozilla seems like to me that they have pretty much barely any manpower especially in recent years so they have very little care for stuff like jxl since i'm pretty sure as far as they are concerned jxl doesn't matter unless chrome supports it

If it's indeed the issue of lacking staff and not some soft of management's decision. On some open-source projects there are a monetary bounty system, does firefox have anything like that?

lacking staff in management

Does this aesopian language basically mean “we will add support when Chrome does it, but go hate them we are nice and neutral”? https://github.com/mozilla/standards-positions/issues/522#issuecomment-1409539985

What does it mean for Nightly's image.jxl.enabled?

anyone posted the response here already? https://github.com/mozilla/standards-positions/issues/522

Sigh, basically they're saying: we'll support it when the others do, but avif is good enough.

AFAIK there never was an entry for AVIF in that positions document, which seems like a real problem to me.

in many senses AVIF was "fast-tracked" without a good enough justification

Yeah that's what their missing. They need to spend more money on management salaries for people who don't know how to code :)

That's what Mozilla is missing

the work's already done

they just dont care

AVIF was "fast-tracked" by AOM, HEIF by MPEG ... couln't JPEG try to do something for its "long-term" format once per few decades?

Organizations like MPEG or JPEG (or even AOM) don't have power by themselves — the only power they have is through the people and companies involved in them.

> We acknowledge that JPEG-XL offers some potential advantages, both in terms of features and performance. Overall, we don't see JPEG-XL performing enough better than its closest competitors (like AVIF) to justify addition on that basis alone. Similarly, its feature advancements don't distinguish it above the collection of formats that are already included in the platform. ...Sounds like Chrome. "Yeah it's good, but fuck you. Oh and have you heard of this amazing format called AVIF? Let's all use that forever and never mind all the crippling limitations or the fact that it was fast tracked."

Let's just use this inferior, fast tracked format with myopic design instead.

What's disappointing (but not unexpected) to me is that Mozilla is just repeating Chrome ('not sufficient incremental benefit over avif') instead of doing their own research or at least being open to research not presented by the avif team. I remember a time when Mozilla resisted webp based on their own research...

So what changed since then? Mozilla instantly, reflexively greenlit AVIF right away, maybe because it actually does have very large and meaningful compression gain over webp?

But it did seem totally automatic with hardly any deliberation at all compared to webp, so that is strange now that you mention it. I wonder what changed at mozilla since then.

Maybe just firing all of their engineers and researchers.

And shifting their focus to shameless e-begging instead

without actually producing an actual product aside from what's left of their accrued popularity and clout

I don't think they have anyone on their payroll right now that is a programmer or researcher or anyone capable of evaluating any technical decisions

So maybe that's all that needed to change

JPEG has lost power due to lack of success for the last two decades, JXL could revive it but it needs some action ... like just people contacting media, writing articles ... I haven't seen any action from JPEG

It's not really their job to take action...

this way MPEG and AOM are succesful ... and JPEG has nearly vanished

JPEG is not like MPEG or AOM.

Honestly I am surprised if AOM is not involved at all in JXL

it has less power, but not using the only success for 20 years show they have zero power

AOM has competing product

so at the pinnacle of its career what did JPEG do anyway?

other than publishing a very much influential standard

if JPEG are mostly academics, still they can e.g. contact media, write articles ... I haven't seen any action

It's not competing and it isn't a product

I thought it's just an "alliance" to develop open formats.

for the web

the strength of such organizations is in suceess of their products

Not to make money but to have open standards to communicate and preserve human culture

I think AVIF would need a licence for hardware implementations - making JXL real competition costing them money

The whole point of standards is interoperability, which of course only matters if it actually gets used in the first place.

off the top of my head, I doubt AVIF needs a license for any use case. I don't even know if they offer hardware certification

https://aomedia.org/license/

https://aomedia.org/license/patent-license/

I thought the only reason why AOM exists is so people aren't forced to pay Apple royalties forever

"1.3. Defensive Termination. If any Licensee, its Affiliates, or its agents initiates patent litigation or files, maintains, or voluntarily participates in a lawsuit against another entity or any person asserting that any Implementation infringes Necessary Claims, any patent licenses granted under this License directly to the Licensee are immediately terminated as of the date of the initiation of action unless 1) that suit was in response to a corresponding suit regarding an Implementation first brought against an initiating entity, or 2) that suit was brought to enforce the terms of this License (including intervention in a third-party action by a Licensee)."

it means they can sue your corporation, but if you sue them then you have to rip off all AVIF e.g. from your products

https://aomedia.org/license/patent-license/

It looks like you don't have to buy a license. They are giving it away for free, regardless if your implementation is hardware or software.

Do they even sell hardware certification services?

It doesn't look like they make money at all. They are giving it all away for free just to give the finger to Apple.

JXL seems like it would line up with such a worthy goal. To give the finger to Apple's HEIF image format

Of course AVIF was their response to HEIC but it didn't change anything about the format other than the codec

Same format different frame codec

JXL needs a real promotion to stimulate real discussion ... e.g. by people of JPEG, to give any power to this organization

JPEG has the least amount of power out of everyone who was involved in JPEG-XL

because of lack of success in the last decades - JXL could give it

as far as I know, many (or all) manufacturers pay sisvel for each device for av1, even if sisvel is just a patent troll, just to avoid litigation, because it will be more expensive and longer https://www.sisvel.com/licensing-programs/audio-and-video-coding-decoding/video-coding-platform/license-terms/av1-license-terms

Just because they have a serious-sounding name like JPEG doesn't mean it amounts to any real power or influence over the ecosystem unless they were to rally a whole bunch of hardware vendors and other people with actual real influence together.

Like if they were to help create some sort of industry lobby group of a bunch of commercial vendors that commit to integrating JXL in their products and services in order to lobby for broader adoption.

You know, what makes this sound exactly like Chrome is how this guy is also using the word **"we"** a lot.

Without ever defining who he's referring to.

still JPEG could do something e.g. make some media campaign, ask members to contact media and write articles ... but seems it did nothing, even though JXL success would increase influence of this organization

Now it's up to Microsoft. If it implements default support (when libjxl is actually ready in ~2025) in the OS, browsers will be forced to support it.

That's called weasel language

also Adobe e.g. in PDF 2.0

Well, that's because Microsoft was involved in the format...

and basically created it

The most effective thing anyone could do to promote JXL is, improve the tooling so its foolproof for noobs to start taking advantage of, improve the lossy performance so it's competitive with AVIF at low bitrates, and create some sort of industry lobby group with a website that has a list of commercial and non-commercial organizations that commit to integrating JPEG-XL into their products and services.

So basically, make JPEG XL better?

Or at least, the tooling around it I guess

Better, easier to use, and unite the supporters into a loud lobbying/promotion effort

If there was a website with a list of everyone using/planning to use JXL, with a blurb or statement from each one explaining how they use it, that would be nice and psychologically encouraging and might help with the appeal for getting browsers to support it

Basically it would imply, "Hey, this format is already rolling out in all of these different places, when are you getting on board?"

"you" being, Mozilla, Chrome...

When are THEY smelling the coffee...

firefox had three times the market share in 2014 compared to today so I guess they could actually take a stand on something like open standards

these days it seems like they are just doing what chrome does

Well back then they also paid people with degrees in the hard sciences who knew how to code and it was their codec engineers that objected to webp

They don't pay anyone except purple haired managers with zero coding experience to work at mozilla these days

At least that's who I am guessing they pay these days

They fired everyone capable of actually creating the product they're supposed to sell

that's a bit of a stretch, think it's more likely they see where the winds are blowing regards AVIF and are mainly just trying to cling to their diminishing market share rather than trying to promote open standards. that's probably more likely reason rather than that they hired someone with blue hair who did gender studies

Back then when mozilla put up resistance to webp, it was from their codec development team. And they developed mozjpeg as a response to the webp proposal. Because they actually had people who knew how to code working at mozilla back then.

If they'd just say "we're too small to matter, we'll do it when the big browsers do it but we won't do it until they do", that would be a fair point. It just feels a bit weak that they pretend to take an independent position and thoroughly contemplate decisions based on technical merits and Long Term Thinking, but then they basically just regurgitate what chrome's codec team previously said...

They literally couldn't do the same thing today because all of those people were fired. Anyone who had actual talent and actually did something useful for mozilla was fired

Back then they could literally just develop a competing image encoder on a dime.

just to prove a point that webp is stupid

They don't work there anymore. They are all gone.

The purple haired managers in charge now consider it a waste of money to develop a product. But at least they are enlightened enough to remove the derogatory and offensive term "master password"

I wonder if firefox will at some point just switch to Blink too and become a chromium-derived browser like the rest of them.

That is an inevitability if there is no "manpower" driving development of their browser engine. You can't even get basic patches merged that fix years old bugs

Not likely

Their incompetence is making it difficult for even the open-source community volunteers to maintain their browser engine for them

They are literally so helpless that they can't even accept freely volunteered help.

clicking the merge button is too much effort

I remember when I was much younger I thought it would be really cool to get a job working at mozilla

But I don't think I have enough hair dye

Mozilla had data compression team e.g. mozjpeg, opus, daala - the latter collaborated on AV1

mainly Terriberry ( https://dblp.org/pid/79/1862.html ) and Valin ( https://dblp.org/pid/87/6271.html )

yes, also Nathan Egge and some others. Mozilla fired them all in 2020, when they fired 25% of their staff

It would be funny if it weren't so sad. And yet I'm still laughing my ass off for some reason.

It's just one of those things that's so stupid that it's funny.

FWIW Apple *is* a member of AOM

(founding member, even)

And yet they are the only ones who don't have hardware-accelerated AV1

Weird

No public plans to either

Apple doesn't ever make public plans

True :)

Apple supports AVIF it looks like.

But they are the odd ones out when it comes to hardware AV1

AV1 encoding is essentially impossible on a Mac, hardware or software.

I heard rav1e might have some preliminary ARM support

Not sure what the status is though

or if it's capable of encoding 1 frame yet

https://bugs.webkit.org/show_bug.cgi?id=208235

Is the latest message from WebKit maintainers the one about handling color spaces in libjxl?

https://github.com/mozilla/standards-positions/pull/741#issuecomment-1410904980 this is me getting angry politely

You know, the most bizarre thing to me is, why do these people think it's their job to be the gatekeepers deciding what formats are worth it and whether or not to allow something to be used

Nobody appointed anyone to be in that position

If people want to use something let them use it, why do these people get such a big head and think they're in charge of deciding what everyone else gets to use?

I guess people like to think they're important. In any case, the big browsers (today that's only really chrome and safari, but to some extent, mostly historically, firefox too) are the effective gatekeepers of the web, so it makes sense that they take their role in it seriously. What makes less sense is having a non-transparent decision process and refusing to take input from the community, as chrome seems to be doing, and we'll see if firefox is any better...

https://gitlab.com/librewolf-community/browser/source/-/merge_requests/47 LibreWolf also has jxl support

also pulse-browser: https://github.com/pulse-browser/browser/discussions/162

https://libreddit.freedit.eu/r/jpegxl/comments/10pkm01/mozillas_position_on_jpegxl_neutral/j6pb8d3/?context=3

This is my favorite comment

> "That salad has too much sodium! I have to watch what I eat!" *inhales four donuts*

The argument is of course that webp and avif come for free since vp8 and av1 are available anyway — but even that is not really true: afaiu webp uses its own vp8 implementation so they can do incremental decode, and avif currently doesn't do that but if they want to make avif images load incrementally, they'll need to do that too. Also there's a bunch of stuff that the video codec does not handle (such as alpha or icc profiles) and that does need extra code just for the image format. See also https://twitter.com/jonsneyers/status/1596965036131426304?s=20

Yeah, it's a myth and misconception. They do not get it for free. They have to link an additional library. libwebp and libavif.

If these self-appointed web-lords had any intelligence or actual concern for ease of implementation, then you could put a "video" file in an <img> or <picture> tag and the HEIF container would just be a regular MP4 container, or better yet just use the superior matroska container if a container is necessary.

since av1 and vp8/9 already use matroska

which Google just shamelessly decided to slap their own branding on as if they invented matroska

tbf WebM is a strict subset of matroska that only supports a small list of things

And essentially renamed someone else's project from a cool sounding "matroshka" to a ridiculous "weppy"

"webbem."

so a WebM-compliant matroska file can be decoded without a generic matroska demuxer

They could have defined a web subset without branding it with such a humiliatingly-stupid name.

Like if they were honest they could just call it matroska web-subset or something along those lines

instead of slapping their own ludicrous-sounding branding on someone else's work

calling it a "humiliatingly-stupid name" is somewhat subjective

yeah I know it is, but I dare you to argue that it doesn't sound incredibly awful

webbem.

weppy.

I dare you to say that sounds cool.

Try using those terms in front of friends and family members

It's an unbelievably stupid-sounding thing to even verbalize

WebM doesn't sound awful to me

¯\_(ツ)_/¯

how it sounds doesn't matter much (jpeg xl also sounds kind of silly), but what is clear from the WebP / WebM naming is that these formats/codecs are designed for one particular use case (The Web) and this does kind of show: for other use cases, they are lacking in features

I mean I can't provide an argument, since it's literally a subjective opinion

they'll just go "what's that" or "oh he's talking about coding again lol"

I don't know, I hear people say that JPEG XL sounds silly to them but it kinda makes sense. Bigger is better right? And JXL is EXTRA BIGGER

webp being limited to 16k x 16k and 8-bit are design decisions directly inspired by it being _only_ created for the web

I mean I like to think of JPEG XL as "JPEG eXtended Life" but that's not actually what it stands for

First time I mentioned it, someone thought it meant JPEG but bigger file size

X is just borrowed from other JPEG X? variants and L stands for Long-Term

I think it's funny in a good way

after j2k, basically all new JPEG codecs except the Pleno ones have a name with an X

XT, XR, XS, XL

no idea why the X though — I think it was originally for "extended", i.e. XR brought "extended range" (since it can do HDR and that was the main thing Microsoft wanted to use it for iirc), and XT is literally "jpeg extended with all sorts of stuff"