JPEG XL Is a Stupid Name(mark-pekala.dev)
mark-pekala.dev
JPEG XL Is a Stupid Name
https://www.mark-pekala.dev/posts/jpeg-xl
50 comments
> Ironically, this would lead me to the right choice of file type if I had a large image.
This is it, I think it works out just fine in the end.
This is it, I think it works out just fine in the end.
You probably missed this though:
> Or if someone said "should I send you the .jpeg or the .jpegxl" and I was low on disk space, I'd find it plausible to say "hmm, no reason to send the large version, the jpeg should be fine".
> Or if someone said "should I send you the .jpeg or the .jpegxl" and I was low on disk space, I'd find it plausible to say "hmm, no reason to send the large version, the jpeg should be fine".
I'm entirely on board with this rant. That the XL means anything other than "extra large" is news to me.
Funny coincidence in Scandinavian, XL "extra liten" (extra small), also works for XS "extra stor" (extra large).
Not in Sweden (any more at least). Language in public space here is so anglicised that it gets embarrassing sometimes.
Nor in Danish.
On the other hand Europe will amount to nothing if it remains a tower of babel.
I think it is a strength of Europe going forward. It’s a pain at the beginning but once education levels pick up to a point where being bilingual at least is a standard, it becomes an advantage — and remains one.
Not sure from where in Scandinavia, but this is not the case in either Norway or Sweden. XL is extra large, and XS is extra small.
However pizzas often come in L and S, small and large respectively...
I was recently at the kiosk at an Odeon cinema in Norway and I noticed that their popcorn buckets were helpfully labeled S, M, and L. Stor, Middels, Liten. No X-sizes in that case though. At least with popcorn you can plainly see that S is much bigger than L is when you pick it up yourself.
Ah, yes, for foodstuff one does often use S, M and L as localized sizing labels, Burger King does the same, I think. However, in the context of localizing XS as being extra large, and XL being extra small, that's still wrong. Anecdotally, wherever XS to XL sizing labels are used it's always been direct counterparts. XS bring extra small, and XL being extra large.
Agreed. Doesn't matter what it actually means, everyone, including myself, will initially just see Extra Large.
I'm still not clear what it actually stands for after reading OPs post though.
Extra Large it is.
I'm still not clear what it actually stands for after reading OPs post though.
Extra Large it is.
eXtremely Late (to be implemented in browsers).
eXtremely Late to the party: JPEG was so preoccupied with trying to generate revenue streams that they were totally blindsided by WebP/AVIF which made "generate revenue streams" an explicit non-goal.
JPEG XL is a royalty-free codec and "generating revenue streams" was never a goal for the project. You can see this already in the very first draft call for proposals from 2017: https://jpeg.org/downloads/jpegxl/jpegxl-draft_cfp.pdf
(see section 5 on page 7)
Which is my point: "JPEG XL" is "too little too late" after JPEG tried to monetize its brand with various other, pretty much failed initiatives:
- JPEG 2000 is popular in the medical imaging space but everywhere else shunned like the patented abomination it is until the patents fizzled out.
- JPEG XR is covered by Microsoft's patents that are supposedly defused under a "covenant not to sue" (but not really).
- JPEG XT builds on JPEG 2000 with all its money-grubbing problems.
- JPEG XS is a pretty particular beast regarding its use cases, but nevermind, there's a patent pool. As such it won't become popular before 2040.
Only with JPEG XL (2017) did they _finally_ acknowledge that they're working on standards that everybody avoids to the best of their abilities due to the licensing situations JPEG optimized for. 20 years for naught.
At that point WebP (whose ancestry makes it explicitly a part of the "avoid the patent mess" movement) was already out for 7 years.
- JPEG 2000 is popular in the medical imaging space but everywhere else shunned like the patented abomination it is until the patents fizzled out.
- JPEG XR is covered by Microsoft's patents that are supposedly defused under a "covenant not to sue" (but not really).
- JPEG XT builds on JPEG 2000 with all its money-grubbing problems.
- JPEG XS is a pretty particular beast regarding its use cases, but nevermind, there's a patent pool. As such it won't become popular before 2040.
Only with JPEG XL (2017) did they _finally_ acknowledge that they're working on standards that everybody avoids to the best of their abilities due to the licensing situations JPEG optimized for. 20 years for naught.
At that point WebP (whose ancestry makes it explicitly a part of the "avoid the patent mess" movement) was already out for 7 years.
The above claims are not very accurate.
JPEG and JPEG 2000 were based on the principle that the core codec was royalty-free but there might be patent-encumbered optional things (such as arithmetic coding, in the case of JPEG) that could be just left out if you want a royalty-free codec. Eventually it became clear that basically a de facto standard would always emerge that just skipped the patent encumbered things; JPEG XL doesn't have any (known) patent-encumbered ingredients for that reason: it's a bit pointless to add things to the spec that nobody will want to use anyway.
I don't think patents played a big role in the (lack of) adoption of JPEG 2000 and JPEG XR; more likely, in my opinion, the main problem was that good FOSS implementations were not readily available at the right time. The core codec of J2K has been royalty-free from the start, but it took quite a while before good FOSS software (like OpenJPEG) was available. Computational complexity was also an issue in its early days. For JPEG XR, even today there is no well-maintained FOSS implementation available; this is probably a bigger reason for its lack of popularity than potential patent issues. Compare for example with h264 (and x264), which had more substantial patent issues but nevertheless became very popular.
JPEG XT builds on JPEG, not JPEG 2000.
JPEG XS has a very specific niche use case (ultra-low latency, as a mezzanine codec for video production workflows), it doesn't have the goal of 'becoming popular' as a general-purpose codec.
JPEG is not MPEG. While both are working groups of ISO, which does have a policy that is not exactly "avoid the patent mess" but rather "don't talk about IP", there is quite a big difference in membership composition and attitudes between those two groups. Having a royalty-free baseline codec (and more recently, having just a completely royalty-free codec) has been something JPEG has been pursuing since the beginning (1980s), while in MPEG they're only recently coming to that conclusion (with EVC, no doubt due to pressure from initiatives like AOM).
JPEG and JPEG 2000 were based on the principle that the core codec was royalty-free but there might be patent-encumbered optional things (such as arithmetic coding, in the case of JPEG) that could be just left out if you want a royalty-free codec. Eventually it became clear that basically a de facto standard would always emerge that just skipped the patent encumbered things; JPEG XL doesn't have any (known) patent-encumbered ingredients for that reason: it's a bit pointless to add things to the spec that nobody will want to use anyway.
I don't think patents played a big role in the (lack of) adoption of JPEG 2000 and JPEG XR; more likely, in my opinion, the main problem was that good FOSS implementations were not readily available at the right time. The core codec of J2K has been royalty-free from the start, but it took quite a while before good FOSS software (like OpenJPEG) was available. Computational complexity was also an issue in its early days. For JPEG XR, even today there is no well-maintained FOSS implementation available; this is probably a bigger reason for its lack of popularity than potential patent issues. Compare for example with h264 (and x264), which had more substantial patent issues but nevertheless became very popular.
JPEG XT builds on JPEG, not JPEG 2000.
JPEG XS has a very specific niche use case (ultra-low latency, as a mezzanine codec for video production workflows), it doesn't have the goal of 'becoming popular' as a general-purpose codec.
JPEG is not MPEG. While both are working groups of ISO, which does have a policy that is not exactly "avoid the patent mess" but rather "don't talk about IP", there is quite a big difference in membership composition and attitudes between those two groups. Having a royalty-free baseline codec (and more recently, having just a completely royalty-free codec) has been something JPEG has been pursuing since the beginning (1980s), while in MPEG they're only recently coming to that conclusion (with EVC, no doubt due to pressure from initiatives like AOM).
Why does this page require WebGL to show anything?
On Safari it fails with a blank page and the title ""Application error: a client-side exception has occurred" = $1"
On Safari it fails with a blank page and the title ""Application error: a client-side exception has occurred" = $1"
I suspect it has to do with the animated geometric background on other non-blog pages of the site, like the homepage, and because the site appears to be a custom Next.js/Tailwind app coded by a college student and not a professional web developer who is used to supporting years-old browsers. (Safari has supported WebGL 2 since 2021.)
The websites uses a 3D library called three.js https://threejs.org/
If you go the main page of the blog, it is the background
https://www.mark-pekala.dev/
If you go the main page of the blog, it is the background
https://www.mark-pekala.dev/
Why do you require using the IE of MacOS? Safari has terrible webgl support, and always has.
Chair of the JPEG XL adhoc group of JPEG here.
I wasn't around when the name for this project was chosen (I only got involved after the call for proposals, at which point the codec already had a name even if it didn't exist yet). I haven't been able to track down the actual etymology or rationale for the name, though "Long-term" has been suggested to be the main interpretation.
I think the name was to some extent chosen as a tongue-in-cheek pun because obviously compression is about making large things smaller. The name must have been chosen around the time that there was a lot of activity around JPEG XS. That codec is all about speed and low complexity, which is where the S comes from: it is very fast (so S for speed) and also it has a relatively simple and small implementation (in terms of circuit complexity), since it is designed for hardware.
So in contrast to JPEG XS, JPEG XL is actually "extra large" in the sense that it does have more complexity, more coding tools, more functionality. All those things are of course there with the goal of making smaller files, but the codec itself is "extra large" compared to JPEG since it has all the coding tools of JPEG plus a bunch more. So in that sense, JPEG XS is indeed "extra small" and JPEG XL is "extra large", as a codec, but in terms of the sizes of the compressed images, it's exactly the other way around: JPEG XS will produce larger files (it sacrifices compression for simplicity/speed/latency), JPEG XL will produce smaller files.
I agree that all this is quite confusing. If it helps, you can always just call it by its filename extension / media type instead of its full name: "jxl".
I wasn't around when the name for this project was chosen (I only got involved after the call for proposals, at which point the codec already had a name even if it didn't exist yet). I haven't been able to track down the actual etymology or rationale for the name, though "Long-term" has been suggested to be the main interpretation.
I think the name was to some extent chosen as a tongue-in-cheek pun because obviously compression is about making large things smaller. The name must have been chosen around the time that there was a lot of activity around JPEG XS. That codec is all about speed and low complexity, which is where the S comes from: it is very fast (so S for speed) and also it has a relatively simple and small implementation (in terms of circuit complexity), since it is designed for hardware.
So in contrast to JPEG XS, JPEG XL is actually "extra large" in the sense that it does have more complexity, more coding tools, more functionality. All those things are of course there with the goal of making smaller files, but the codec itself is "extra large" compared to JPEG since it has all the coding tools of JPEG plus a bunch more. So in that sense, JPEG XS is indeed "extra small" and JPEG XL is "extra large", as a codec, but in terms of the sizes of the compressed images, it's exactly the other way around: JPEG XS will produce larger files (it sacrifices compression for simplicity/speed/latency), JPEG XL will produce smaller files.
I agree that all this is quite confusing. If it helps, you can always just call it by its filename extension / media type instead of its full name: "jxl".
It's no worse than the other JPEG names: JNG, JPEG LS, JPEG 2000, JPEG XR, JPEG XS, JPEG XT
JPEG-HDR is probably the only one of them that gives away what it might be for.
JPEG-HDR is probably the only one of them that gives away what it might be for.
JXL is a pretty good extension. I'd pronounce it "jixel" to rhyme with pixel.
JPEG-Eon, or JPEG-Era might have given the impression of "long-term"? Jeon is a Korean fritter, which I like the sound of. I don't think you could have Jera without causing a clash with Jira for some vowel pronunciations??
JPEG-NX, JPEG-Next, would have been good, .jnx, "jinx", ...
Or, how about just JPEN, for JPEG-New?
Honestly, if it's also for non-photographic images then a break from even using "JPEG" would be useful in not weighing the format down with that baggage.
I too thought it was likely optimised for very large [photographic] images.
JPEG-Eon, or JPEG-Era might have given the impression of "long-term"? Jeon is a Korean fritter, which I like the sound of. I don't think you could have Jera without causing a clash with Jira for some vowel pronunciations??
JPEG-NX, JPEG-Next, would have been good, .jnx, "jinx", ...
Or, how about just JPEN, for JPEG-New?
Honestly, if it's also for non-photographic images then a break from even using "JPEG" would be useful in not weighing the format down with that baggage.
I too thought it was likely optimised for very large [photographic] images.
People will probably call it JXL after the file extension anyway.
This website requires WebGL to show any content at all, for some bizarre reason, so I'll be replying to the title alone.
"JPEG XL" allows you to store extra large images in a fraction of the space. It makes sense in my head.
"JPEG XL" allows you to store extra large images in a fraction of the space. It makes sense in my head.
Whereas I wondered what a Roman numeral 40 had to do with image files.
The original names of the related tech was pik and huif. Also Guetzli, Brotli, Butteraugli, XYB, Brunsli, SSIMULACRA, FLIF, FUIF are related names.
To be fair, it does support eXtra Large dimensions.
JPEG is a terrible name. We got used to it.
I've made this exact point on here several times. Absolutely terrible name.
Not once have I thought that JPEG XL would result in larger images.
My first instinct was that JPEG XL would produce bigger images, probably for better quality.
Why is this downvoted. If anything, this is ~infinitely more useful than the blog post, which is n=1 data. Now we have n=2 data points, ~infinite update.
For n=3: it haven't even ever once occurred to me that jpg xl results in larger images, or is for larger images. I've first seen it presented as a new, better jpg file format, and I haven't questioned this based on its name.
For n=3: it haven't even ever once occurred to me that jpg xl results in larger images, or is for larger images. I've first seen it presented as a new, better jpg file format, and I haven't questioned this based on its name.
Yeah, avif is better.
Seriously, can we just settle on that? It's objectively the best and the fact that there are so many of competing alternatives is the reason why we're still stuck with that 8bit artifact ridden ancient JPEG.
Seriously, can we just settle on that? It's objectively the best and the fact that there are so many of competing alternatives is the reason why we're still stuck with that 8bit artifact ridden ancient JPEG.
From what i've seen JPEG XL always wins against AVIF in every category. What makes you say AVIF would be "objectively the best" while JPEG XL boasts better compression, more funtionality(32bit support e.g.) and faster encoding?
AVIF does better at low-bitrate scenarios ( low bits per pixel, quality is going to be poor anyway, avif can make it less poor) while JpegXL does great at higher bpp and lossless scenarios
Probably AVIF is better at GIFs.
> It's objectively the best
Sources?
Sources?
[deleted]
[deleted]
I do admit, though, that if I saw a folder full of .jpeg and .jpegxl files before reading this, I'd expect the .jpegxl ones to be larger on average. Or if someone said "should I send you the .jpeg or the .jpegxl" and I was low on disk space, I'd find it plausible to say "hmm, no reason to send the large version, the jpeg should be fine".