JPEG XL

I'll do some testing later today

anyway lossless hasn't changed much even compared to 0.7, except streaming and e11 (which is also not for practical use) but otherwise the density on slow efforts is even slightly worse overall, a bit better on some content, better on some fast efforts (because palette mode works), a bit worse on other content

webp2 is not even close ``` wintime -- cwp2 -q 100 -effort 8 w.ppm -o w.wp2 -mt output size: 288182 (6.40 bpp) PeakWorkingSetSize: 788 MiB PeakPagefileUsage: 936.1 MiB Creation time 2024/10/27 12:53:42.100 Exit time 2024/10/27 12:53:59.405 Wall time: 0 days, 00:00:17.304 (17.30 seconds) User time: 0 days, 00:00:00.968 (0.97 seconds) Kernel time: 0 days, 00:01:07.343 (67.34 seconds) wintime -- cjxl w.ppm w.jxl -d 0 -e 8 JPEG XL encoder v0.11.0 4df1e9e [AVX2,SSE2] Encoding [Modular, lossless, effort: 8] Compressed to 280.3 kB (6.228 bpp). 600 x 600, 0.289 MP/s [0.29, 0.29], , 1 reps, 12 threads. PeakWorkingSetSize: 39.06 MiB PeakPagefileUsage: 39.58 MiB Creation time 2024/10/27 12:55:51.020 Exit time 2024/10/27 12:55:52.274 Wall time: 0 days, 00:00:01.253 (1.25 seconds) User time: 0 days, 00:00:00.031 (0.03 seconds) Kernel time: 0 days, 00:00:01.500 (1.50 seconds)```

Blurhash? So not even a preview at all?

Maybe they mean it's improved because it isn't limited to 8 bit anymore...?

Lossy hasn't actually changed much either. Tuning has been done but it hasn't really gotten anywhere with several steps forward and backwards

yeah, just some changes for some cases

It would be really nice if libjxl had a lossless encoder as good as Jyrki's webp-lossless encoder

It will be once the algorithms are ported over

Although who knows how long that'll take

Some things don't map directly from webp to jxl, e.g. webp is hardcoded for 8-bit RGBA and uses an interleaved representation, while jxl's modular mode can do arbitrary bit depth and number of components and uses a planar representation. WebP like PNG encodes the whole image at once, full rows at a time, while jxl uses groups to allow parallel/cropped decoding.

something like the color hash thing webp uses to get some kind of free local palette is a coding tool jxl doesn't have as it's something that makes sense if you hardcode for 8-bit RGBA (so you can treat a whole pixel at a time as a uint32 number), but not so much if you're doing planar encoding of an arbitrary number of components of an arbitrary bit depth

Planar is when all the Red data is seperate to Green data, etc.. ?

Yep

A Gentoo Linux user tried JXL https://forums.gentoo.org/viewtopic-p-8844199.html

Sounds like a case for lossless, or patches at least, but who knows how large the image is so that might not be a good idea...

rather, the jxl encode should target lower quality to achieve "impressive" size established by other format encodes

Skanpage does not offer a quality slider, all of those results are lossy

Alert 😄 https://www.reddit.com/r/jpegxl/s/CKojgXBqGu

recompressions from jpg originals will never be as efficient as jxl's special mode that also losslessly *guarantees* 20% smaller filesize for barely 30 milliseconds of encoding time (effort 7)

even with psy, avif either gets smaller filezizes through sacrificing quality until it reaches target size (smaller fileize is *not* guaranteed and you cant target a specific final filesize), or bloats into a x8 larger lossless avif thats also inefficiently encoded compared to lossless webp

whats positive is that ssimulacra/butteraugli are gaining acceptance as truly superior modern metrics than dssim and psnr

https://www.youtube.com/watch?v=0eganQYMpVg

erik andre from meta/facebook the company is supposed to do a speech today at an AOM workshop (sponsored by google and meta) about how they evaluate their imaging pipeline, priorities and challenges in minimizing latency with modern codecs and notably mention jpegxl and jpegli

interesting, is this recorded? or is there info available somewhere about this?

https://2024.ieeeicip.org/aomedia-industry-workshop/

Seems a bit misguided, saying Lossless JPEG has no HDR and less colors, but hey he says to use JXL so :P

>>> 10:30 – 12:00: Industry Talks Talk-07 Title: Adopting Modern Image Codecs at Scale Speaker: Ms. Zuzanna Mroczek (Meta), Mr. Erik Andre (Meta) Abstract: Optimizing the image experience across Meta’s apps comes with challenges that are hard to find anywhere else. Every day, we handle billions of image uploads and trillions of image download requests on our CDN. This means that image compression is more important to us than ever in the world where visual quality matters but also where every millisecond of latency counts. In this talk we’re going to share findings from years of our work on adopting modern image codecs in our Image Infrastructure (AVIF, JPEG-XL and JPEGLI), pinpoint performance aspects of image compression that matter in different parts of our image pipelines and present challenges we encounter with image quality understanding between the formats.

Still worthwhile to try to clarify confusions. Lossless JPEG and lossless JPEG XL should in principle be exactly the same data...

Thankfully someone corrected him in the comments, but he just replied "You should've read the title" and "You're absolutely right!"

Uh... isn't Eric Andre that guy who does the Eric Andre show on Adult Swim?

I hope they make a point to emphasize the inadequacy of avif and the need for browsers like Chrome and Firefox to turn on support by default like Safari... and for the avif team to stop trying to gatekeep jxl from competing with their own format!

It's so immature and ludicrous what they're doing with their unsupervised power over the chromium source tree

i expect part of their findings are stuff we already got confirmed in earlier articles and details whose existence people forgot

like how jpegli and jxl images are always progressive to some extent and start displaying meaningful content as soon as just 20% of the file was downloaded, whereas avif requires the entire file downloaded before anything starts displaying

a shame theyre not already leveraging lossless jpg->jxl transcoding to send more lightweight images to their own apps. thatd be a huge advantage over the website/browser version since itd load so much faster they could cram more ads into the bandwidth saved

I'm pretty sure it's a different Eric Andre

Nevermind 20%, we've seen 0.14% progressive views

I got a 32k x 32k to load in 4500 bytes with JXL Oxide

I'm actually working on a project where this could be very useful. Namely what we're doing right now is sending the thumbnail and full image as separate images over network, but are thinking if its possible to first send 20% of the full image as thumbnail, and then the rest 80% later for full image. But I'm not sure how to approach this in a reliable/deterministic way. I.e how to determine the % where a valid "thumbnail" could be parsed.

Is progressive dc supported by the decoder yet? Without it it can't act as a thumbnail, even 1:8 downscaled image gonna be too big if the original file is taken by modern camera.

Currently libjxl doesn't render `lqip`, which means <#1065165415598272582> might work a lot better. Like I mentioned before, we've gotten 'images' at only 0.15% with it https://discord.com/channels/794206087879852103/794206170445119489/1285250134875176992, so even just a few percent would probably be enough, assuming they're encoded with `--progressive_dc=1` (can't recall the earliest without). The decoded output will also be at full resolution, upsampled from 1:8 (or less) since there's no API for it yet, but it was discussed before

Currently libjxl doesn't render `lqip`,

it would be nice if meta supported avif and jxl on their apps/platforms

afaik you can just upload jxl to facebook and it'll re-encode as needed for messenger, it doesn't recognize it as a picture so it just sends as a file iirc avif i've never tested yet

Interesing. I use this for editing most of my HDR photos: https://9to5mac.com/2024/11/01/apple-reaches-deal-to-acquire-pixelmator/

I wonder what applications will "work" when linux finally gets proper HDR. I guess if any vulkan apps exist they would work now, but I doubt any do

I have a good feeling about the future of jxl. Would be nice if more iOS apps started using it as a delivery format.

It's certainly has a more future proof design than avif. Now it just needs an encoder that can compete with lossless webp and lossy avif (and to a lesser extent gifsicle)

https://arxiv.org/html/2410.17814v1

Looks like jxl is performing quite well for these volumetric medical datasets. Even doing intra-only, on 3 of the 4 datasets here, it compresses better than any of the other classical codecs (JPEG LS, J2K, HEVC, VVC) even when allowing them to use inter ("3D") coding tools like the 3D wavelet Transform or HEVC/VVC's extensive inter prediction tools.

What is BPV?

If lower is better, yeah JXL is doing really nicely

It's basically bits per pixel, except here they call it voxels since the frames are slices of volumetric data.

How do you store 3d data in a 2d image format? Animation?

I think they just store the slices independently, but that's basically what libjxl would do too when doing it as animation

They mention subtracting one frame from the next for their own AI codec, a shame they didn't do the same for JXL

is 3d image codec in this case just a stack of "frames"? and in that case do we know how may slices are in said image?

what do you mean "AI codec"? JPEG AI again?

Click on the link, the entire thing is about their own AI compression method

Could you count JXL’s MA trees as being a “learned” codec?

They never specify the encoding parameters, which is slightly concerning, but they do say this > our encoding time is recorded at 0.649 seconds, which is on the same order of magnitude as JPEG-XL

So very small images, I'd bet JPEG XL scales far better than the AI ones to an extent

Ah, just had to scroll up a bit

I don't know whether there's an agreed upon definition of the difference between learning-based and classic codecs, but I would consider anything where the decoder requires some neural net or other kind of model with many weights (millions of them) to be learning-based. Encoder side you can in principle always apply learning-based methods to improve results, at least if the bitstream offers some flexibility so encoders can make choices.

Technically, all compression is learning based, learning what the next pixels will be and assigning the least amount of bits needed :P

JXL-AI version soon? 😄

imagine all the venture capital funding 😮

Soon, I doubt. But I do think that jxl makes a compelling target syntax for AI based encoders. If an AI encoder can figure out how to use splines, patches or large block sizes in an effective way, it might work better than manually handcrafted encoder heuristics. Though I will always find it a bit scary to give control to a black box thing...

Also by developer learning during tuning psychovisual compression

There's a bit of a gray area between tuning and learning. If it's only a dozen or so parameters, it's definitely "tuning" and not "learning", and if it's millions of parameters, it's definitely not just "tuning" but "learning", but where exactly the threshold is, is a bit hard to tell.

If you can still explain what the meaning/interpretation of each parameter is, then it's probably tuning

Might be able to look at the MA tree after to get ideas on what to try in the conventual encoding too

Yeah, or just encode with e9/10 and make some kind of set of predefined trees based on that, which could be good for e4/5 (basically make those effort settings like e2/3 but with a set of trees to try rather than just one fixed tree)

Actually, has that fixed tree been improved at all since it was first chosen?

Hasn't been touched in a long time, I think.

not sure we can do that 😛

At least the parameters still have variable names and probably some general idea of what it's doing, even if the emergent behavior in the overall system can be a bit hard to predict

But yeah there's no super clear distinction. You could interpret things like DCT coefficients or MA trees as a 'latent space', in a way, and tuning of encoder heuristics as a form of learning.

I would say things are more 'controlled' in something like libjxl than in a typical learning-based codec though. Most sources of error when doing lossy are local and linear, which is usually not the case in learning-based codecs. For images wildly outside the 'comfort zone' of the codec (very different than the image content used for tuning/training), both classic and AI codecs will probably not be great, but I would trust the classic one more to not do stuff like making an alien planet look more like Earth...

https://www.mdpi.com/2313-433X/10/5/113

Strange how it doesn't mention ssimulacra2 in the Objective IQMs section

> JPEG XL mostly introduces softening and ringing artifacts

Ringing? It's mostly softening imo.

Seems to be a relatively superficial review, maybe based on something a LLM produced after reading some documents

https://beebom.com/what-is-jpeg-xl/

Not sure if I’m going insane and have sent this before

> Lossless files could be a bit large still Well what can you expect?

> The encoding times are a different story, though, with WebP sometimes achieving much faster encoding times consistently. Both JXL and AVIF encoding times are almost similar, but on average, AVIF does seem to be leading a bit. … are we reading the same graph? webp is consistently near the top (higher encode times)

Sometimes consistently?

AVIF leading a bit in encoding time?

https://discord.com/channels/794206087879852103/822105409312653333/1283837462652911689

Why do people feel the need to write about image formats while not even understanding some basic things like the difference between a codec and an encoder (setting).

Yeah AVIF is so much faster than JPEG XL!

(When you use -e 11)

lot of info is scattered around and forgotten or walled behind discord. doesnt help some concepts obsolete old common practices and workflow norms

theres also confusion between the capabilities of jxl standard, libjxl (upstream's builds that preserve quality and tuned 3rdparty builds) and other implementations as if theyre all actually the same thing

Idea: I’m going to read every message ever sent on the discord and compile it into one super knowledge base

Is every message ever sent still here or has some of it been deleted?

Or is that too much JXL for one person to handle

iirc the consistency of encoding times was brought up with numbers in an article before. pareto front iinm

and “higher encode ms means slower”, apparently

unless they just mislabelled the graph

I was planning on making a Reddit FAQ post for Google to index at some point

someone should make a google doc to put everything to ever know about JPEG XL into

that graph just looks weird, webp and jpeg at the opposite ends seems ... hard to believe

and then it can be published on some website

Not really related to that 'article', but yesterday I found 19 MB PNG that compresses to 28 MB JXL even with -e 10. Did not try special options like -E and -I though

was it paletted?

No, 29k colors

But it is 'terribly' synthetic

Some images really benefit a lot from doing full rows and using lz77. In that case it can help to do something like `cjxl -g 3 -I 0 -e 9` which should at least give you some lz77 (though you still won't get full rows).

Why -I 0? To disable prediction?

To disable MA tree learning

Why don’t you want MA tree learning ?

currently libjxl either does MA tree learning or good lz77 search but not both

we don't have an encoder yet that can do both at the same time, since the MA tree changes what the residuals will be for lz77 to search in, while lz77 matches also have an impact on what would be a good MA tree. So it's a pretty hard thing to optimize together, and we decided to just not even try, basically.

Is it one of those “we’ll optimise it once the format is popular enough for these kind of optimisations to be worth it”

Dropped from 28.2 MB to 27. Resaving source png with "smallest size" option in PS reduced it's size from 19 to 18.2 MB. So the gap between png and jxl is still 9 MB

Doesn't that PS option create a png8?

I'm not sure what png8 is

iirc it's a paletted PNG. And PS does have a indiscreet checkbox when saving PNGs that reduces the colors to make paletted image (people often select it thinking the image will still be lossless but it's not)

that "smallest size" option might be it

No, it is still 24 bit png. Also as far as I can see - there is no such checkbox. You have to convert image to indexed from Image menu to get paletted png.

I don't have PS installed but this is where the option me and wb where thinking about is https://cdn.discordapp.com/attachments/332185591770775563/1246123844838756442/image.png

🤔 IDK how to get this window in PS

that's what you get in the Export as... dialog in current Photoshop

What Photoshop version are you using?

Ah, I see. Never have been there

Latest one

haven't seen that dialog, how do you get it?

This one?

yes. anyway, if you're sure that the resulting PNG still has all 29k colors then it's not the issue

Save as... PNG

I guess the image is too large to upload here

https://we.tl/t-U2WsQh5eGH

Image is a bit smaller than I told, because I removed some confidential info

Like exif data, or actual pixel in the image?

Pixels

I can see why PNG works well on this one — that wood pattern is tiling, making it have horizontal repeats that result in good lz77 matches

to beat PNG here, we would need a better patch detection to de-duplicate that tiling pattern

It was created from pdf, idk who and how created this document, but it takes 3 min 30 sec to just open it by pdf reader on 7950X 🤦‍♂️

ideally separating out those black lines and text that are overlaid on the tiling pattern, so you can store the patch once, repeat it as many times as needed, and have the black lines coded separately (which should compress well)

just bumping up the group size does seem to help a bit: ``` $ cjxl -d 0 1e.png 1e.png.jxl -g 3 JPEG XL encoder v0.11.0 0.11.0 [NEON] Encoding [Modular, lossless, effort: 7] Compressed to 22317.8 kB including container (0.641 bpp). 19843 x 14032, 21.347 MP/s [21.35, 21.35], , 1 reps, 12 threads. ```

Try g 3 I 0

Strange. -g3 -I 0 produced 26.5 MB file

Maybe ma trees help more than the lz77 marching?

If only pdf viewers were smart enough to convert vector and textures to spline and patches.. This pdf is exported from some 3D app, and it renders literally triangle by triangle

it is quite hard to separate a merged image again in an encoder, for images like this it would be useful to have a jxl encoder integrated with the authoring tool or PDF renderer that would actually know when it is tiling a pattern or adding a line overlay, so it could manually create patches and layers and compose an image that way — that would probably beat PNG by a big margin

So basically using JXL as a PDF?

alternatively you could keep using PDF (or SVG) and just store the raster parts with jxl instead of whatever format is currently being used

JXL-in-SVG is something that I am experimenting with personally

jxl cannot do everything that PDF can, it cannot do text as text, it cannot do filled shapes, etc etc.

This pdf is mentally broken anyway, opening or changing the scale relaunches 3 and a half minutes render cycle. So having it as image was the task my friend came to me with

If only Monad's custom patch detection survived 😔

What happened to it?

I would be willing to help out, I want to dip my toes into reddit again

I’ll make a Google doc to draft on

this is going to take a while (file 1 of 277)

distant future

Maybe train AI on all the messages so we can just ask it everything? 🙂

Honestly, its sad Discord is not really publicly searchable like original PHP forums. So much information locked away from public eyes.

Send instructions on how to do that and I probably could

I could write some kind of public proxy bot that lets you access the discord through HTTP

Or maybe that already exists..?

I think the problem is person can only see content of discord server if they join it. Because of that there cant be really public indexer like google. On the other hand you could see content of php forums even without registration.

not unless it's a forum/subforum that requires login/perms

Those are different & annoying

all the forums I frequented were like that

Posting being behind an account makes sense, but viewing…?

yeah?

How is it helpful if viewing the forum requires a login

Unless it’s like paid

That’s different

it's not

But requiring to sign up for an account to view the forum, what benefits does it have

The point is that it being a forum doesn't immediately make it what you want it to be

…?

it's just like discord isn't it

I thought we were all in agreement that this being locked within discord was bad

also discord you can make it so you don't need an account to view a server

Google still probably refuses to index that

yeah that's the only problem

But not really

Discord is a chat app not a bulletin board

Telegram isn't indexed

Irc isn't indexed

Maybe there should be a JXL wiki or something

Real modern one would be a jxl Facebook page

So everyone can edit it and search engines can index it

Myspace *

MySpace you can't view

Facebook is indexed on google

Fine, twitter

X*

and can view as a guest

x can't view without account

how tf you view Facebook as guest

you just do

It forces me to make an account

JPEG XL FAQ on a user talk page on Wikipedia

the Wikipedia page already exists

But it's worse than a locked forum

Wait Facebook has an onionsite?

Problem is that discord basically replaced bulletin boards. Before communities posted mainly on forums and these daily I see mainly discord servers. Btw, I don't think discord is bad. This is just my nitpick with it and I think it could be improved.

But I will stop with the offtopic 😄

maybe https://wiki.x266.mov/docs/images/JXL

> wiki.x266 > AV1 Logo > JPEG XL content

webp images

The whole compression community coming together to build that site

I feel like we should have something just for Jpeg XL though

If only we had a <#1256302117379903498>...

both feels light on info... theyre only informative and gives no visibility to other types of useful insights meant to foster adoption like articles, specific situations/benchmarks or ways to enable/modify workflows for efficiency

another issue is people's coverage or official articles referncing the horrible jpeg.org site instead since 'the official one'. almost all also lack any mention of the discord or prompts to some official email or site for anyone interested in contacting devs or asking for comments on anything

Those were planned, but it was a lot of ideas all at once with the Apple launch nearing ever closer

benchmarks change so that's not a realistically useful metric and is more marketing, and IMO does not belong on a "wiki" unless you use some kind of automated testing.

samples representatives of expected performance in common scenarios would suffice. take lossless recompression, it isnt discussed using any hard numbers for its importance to be realized

I would still argue that a reddit FAQ would be important to have, there's a lot of questions that could be answered very easily and prevent the spread of misinformation.

Maybe I can write something out during my 4 hour flight tomorrow

Fake. You still need to create a "temporary" account, which requires a cellphone number in 100% of cases.

what? I have never heard of Discord requiring a cellphone for the creation/usage of an account. although I will say that I agree that Discord is a locked information hole

Did not use VPN, still got phonewalled

https://youtube.com/shorts/MoaVS1gp8MQ?si=IAHs6R7Go-AExT9n not jpeg xl, Jpegli but still

JPEG XL: exists Google (Chrome): nobody likes our own formats Google (Chrome): let's just use JPEG with some tech from JPEG XL, but not actually use JPEG XL JPEG XL: 🤦‍♂️

The comment section hurts to read

https://nvd.nist.gov/vuln/detail/CVE-2024-11498

not the kind of coverage jxl wants

Dear god, a carefully crafted JXL file using (possibly) 512MB!?!? But how will I survive when the normal decoding process already uses that much at 4K

Not on the stack hopefully.

(You can tell I don't know much about the subsets of memory types)

is *that* the one that worried you? 😛 I think https://nvd.nist.gov/vuln/detail/CVE-2024-11403 is more dangerous, this one at worst will make some programs crash on most environments

CVE all the things lol

On Windows default stack size is 1 MB, on Linux 8MB (they can be increased)

so yeah it's a serious issue

can't do more than get you a DoS, so not *too* serious

<@274048677851430913> I could be wrong, but I *think* Waterfox updating the libjxl version means your banding comparison at the bottom is now already dithered on decode. I can't see any differences and zooming in revels a low level crosshatching pattern https://saklistudio.com/miniblog/krita-jpegxl-tips/

I did want to suggest on the repo to not dither when the file is already 8bit, but the results tend to be better regardless, unless you specifically want the dithering/flat areas of color. So I compromised and made an issue for less distracting blue noise instead :P

https://github.com/libjxl/libjxl/pull/3090

oh it is dithered now, sweet~ those comparison images are indeed in 16bpc though

Ah, then I guess photon noise isn't needed anymore

The default stack size on Linux varies and if you need a particular stack size it's good to explicitly set a larger stack size

On musl the default stack size is 128k

https://www.youtube.com/watch?v=vFDu68tjS7A

Some misguided comments and overall confusion from not paying attention to the video, but not bad

Yet RAW is an ambiguous term. How raw is RAW?

this is one of the things i was worried about, JPEG has such negative connotations

maybe the format should be officially called "JXL" and JPEG XL is just its full name

why is the first RAW full of JPEG artifacts 🤨

First was using the preview images instead of the actual files, later comparisons *should* be correct

Technically, it's still the same DCT was 30 years ago <:SadCheems:890866831047417898> but float and xyb and more blocks size

Also modular

But also by that logic you could call H.266 VVC “MPEG1 XL”

like jpeg 2000 like jpeg XR

yo dawg, I heard you like RAW.

Raw. It's f*cking RAW

Lamb sauce based encoder

https://github.com/web-platform-tests/interop/issues/700#issuecomment-2551623493 Awesome news 😄

Wow ChatGPT can't be fooled easily https://chatgpt.com/share/676ae95b-b710-8009-ac4b-db50a66159d7

Nope unfortunately > Adoption: Increasing support in web browsers (e.g., Chrome and Firefox) and image editing tools.

I remember it was telling me alternatives to JPEG while maintaining quality, but didn't mention JXL. When I mentioned it, it tried to cop out and say I was talking about exclusively other formats than ones designed by JPEG

ChatGPT still insists that JXL is better even if I told it that "Jon loves JXR the most"

Jon definitely said that JPEG Triple X Private Reserve is the best

LOL: > JPEG XR (Extended Range) and JPEG XL (Extra Large) are both image compression formats (Llama 3.3 70B Instruct)

It was convinced that JPEG XL is better, but simultaneously said to use JPEG XR for HDR and wide-gamut, despite listing both formats being able to do that in previous paragraphs.

JXR finally got some love from Microsoft after over a decade https://pureinfotech.com/set-hdr-jxr-wallpapers-windows-11/

When macOS supports setting JXL wallpapers

Yeah, we saw the mislabelled patch note for Windows at the start of the year saying they allowed JXL wallpapers instead of JXR

This is bait from Microsoft

https://x.com/thiojoe/status/1841268514406928891

Oh, October... Could've sworn it was longer ago

Not many guides telling how to have an HDR .jxr

Damn I was thinking of JXL when attempting typing in JXR

Included JXL in the MIME types even when the jxl extension isn't installed?

https://discuss.privacyguides.net/t/warn-users-about-cromite-adding-and-enabling-jpeg-xl/23718

Pretty sure it's disabled in cromite https://github.com/uazo/cromite/issues/1365

I don't wanna make an account there and my matrix homeserver exploded or something (average synapse) so this is an epic weird fixation on libjxl instead of the several other things cromite jams in there like AdBlock plus (or whatever) instead of ublock origin

People fail to realise the 100K lines of code includes the entirety of jpegli and the *encoder* too, which is far more complex

Who started the fear mongering around libjxl? I forgot who pushed the incorrect statement that *"it has 100k LoC and it's C++, therefore It's SUPER unsafe!!!!"*

granted, if im going to go into auditing libjxl blind, cloned the source, I woulda been in a bad mood lol

I think that's just a general sentiment about large C++ codebases, not specifically libjxl. but maybe others then interpreted mozilla's concerns as a concern about libjxl specifically

<https://github.com/mozilla/standards-positions/pull/1064#issue-2503684693> > Our primary concern has long been the increased attack surface of the reference decoder (currently behind a pref in Firefox Nightly), which weighs in at more than 100,000 lines of multithreaded C++. <https://www.reddit.com/r/jpegxl/comments/1f8aj5w/comment/lldm3tj/> > True: there are over 103k LoC of C++ in libjxl-0.10.3's source code distribution, which is the reference implementation for jxl. However, 14k of that is in the `tools` subdirectory, there's another few thousand in plugins and examples.The library source code is 80k LoC of C++. > > Of that, 15k is in jpegli, and 64k in jxl. > > If I exclude the sources named `enc_*` on the assumption that they wouldn't be part of a decoder, we're down to 42k LoC in jxl. > > I acknowledge it's not really that simple: I don't see a build configuration for a decode-only library, so an audit couldn't truly discount all those `enc_*.cc` sources, etc. And 42k LoC is still a lot of multithreaded code. But maybe not quite as bad as "more than 100k lines" made it sound. > > libjpeg-turbo is 56k LoC of C, and 30k LoC of assembly. That's including encoding, decoding, and its command-line tools.

If anyone knows: how "large" are the JPEG and PNG decoders built into firefox? How do they compare to libjxl

They're using libjpeg-turbo, so the quoted Reddit comment is accurate. Can't find the PNG decoder, but did find out they have public metrics of image decode speed https://glam.telemetry.mozilla.org/firefox/probe/image_decode_speed_avif/explore?

Also, this doesn't seem right... They must be using a crawler that doesn't support JXL, or isn't checking the mime type properly https://w3techs.com/technologies/overview/image_format

well I mean the percentage relative to AVIF seems right'ish

like it's saying AVIF is almost non-existent and that JXL is an even lower almost non-existent

They are actually using the entirety of libjpeg-turbo including encoder? That feels quite unnecessary

If there was the choice of format with their internal screenshot tool but there is not, it is always PNG

I'm finding it impossible to search their repo or trackers but it seems like it https://bugzilla.mozilla.org/show_bug.cgi?id=1787515

Checking out the firefox repo, firefox comes with encoders for bmp, ico, jpeg, png and webp. there is libjpeg in a different directory, which is made up of files with around 45.000 loc

https://searchfox.org/mozilla-central/source/media/libjpeg

> This concern was a major factor in Google’s decision to drop support for JPEG XL in Chrome.

That's the reason?

I'm pretty sure it wasn't

I think they said something along the lines of, "avif has higher quality images and is faster to decode".

I forgot where that flawed study was but that's basically what the avif team said.

That "Cromite" is for Chrome so it's unsprising for being pro-AVIF

Still wondering if they would change their mind when jxl-rs is released

i thought cromite still had jxl decode but its not built in the release builds since a few major versions until they evaluate the impact of a change in upstream chromium

there shouldve long ago been some ambassadorship program that fosters adoption and sets records straight without needing the core devs stepping out of the zone to clear twitter misunderstandings

https://cloudinary.com/blog/contemplating-codec-comparisons

Is this true? I asked almost identically with the jpegxl.info table https://chatgpt.com/share/677cb847-71c4-8009-bac5-c84ac47d72f8

I know the number of channels for JXL is wrong there

and the dimension is 1,073,741,823 × 1,073,741,823 not 1,073,741,824 × 1,073,741,824

A simplified table as well https://chatgpt.com/share/677cbde9-0c70-8009-85ef-a79e5c6ca633

It's a maximum of 4099 channels

I hope people aren't getting their information from LLMs

ChatGPT once said the maximum is 15

As far as I can tell most of it is wrong. It's just guessing based on the fact JXL is newer and generally more efficient than old formats

Web browsers need to implement jpeg and png _encoding_ too since there is a javascript API for that.

Seems a bit bloated, but understandable in that case

strictly speaking they don't have to support those. but it's a common enough use case to encode a blob to png that it's prudent to do so

however PNG is an exceptionally simple format (unlike JPEG) so there's minimal overhead in that regard

PNG encoding is obligatory: https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL

JPEG is not, but clearly the API was designed for lossy encoding so it is kind of expected that jpeg encoding will be there

The reason was, Google formed the Chrome Codec Team after acquiring On2 technologies, and the tech lead, Jim Bankowski, abused his position and leverage to fast-track his own half-baked projects, webp and avif, into the browser despite zero demand and zero ecosystem interest. Then this same person turned around and tried to gaslight everyone on the Chromium bugtracker by saying there's no ecosystem interest in jxl.

It's literally just a case of a single person and his ego ruining it for literally everyone.

Jim Bankoski also the former CTO of On2 Technologies

Yeah, that's why I called him the tech lead

After Google acquired them he was put in charge of the chrome codec team where he used/abused his position to force his half baked formats onto everyone despite ecosystem apathy and pushback

And he is the key (likely the only) decision maker in removing jxl from Chromium.

because, as he helpfully tells everyone, there's just "not enough interest"

Two comments on that: - I don't think it's particularly healthy to explicitly blame a specific person - the situation *is* more nuanced than that (not that I agree with the decision), there's more factors at play than the personal interests/opinions of a single person... But I probably said too much already 😂

even without any insider information, one can probably already notice that if Google acquired them, it means that someone else, already at Google before Jim Bankowski, made the decision of acquiring them

(in fact, that’s about the full extent of what I know about this – I don’t have any insider information I would be trying to hint at)

whenever I complain about the state of things in relation to JXL in Chrome to friends (or anywhere else for that matter) I never pin the blame to any specific names because 1. I'm pretty sure it's the actions of more then one person (a team effort you could say) and 2. It's kinda impossible to know the *exact* chain of events so throwing around all the blame to one specific person without evidence isn't a good thing.

Personally, I believe people in leadership positions like him should take responsibility for their own leadership, and should avoid using weasel words when justifying their decisions. It's clear that whoever made the choice to acquire On2 trusts the former CTO's leadership and executive decision-making authority as a subject-matter expert in his field, and it appears like that trust is being abused to selfish/egotistical ends And if it all ultimately falls upon a single person having the power and untrammeled authority to put their own ego before literally everyone else's interests, then isn't that the main problem? I personally am not aware of any evidence that it involves anything larger at play beyond him and his team...

Honestly I wish I understood why leaders shouldn't take credit for their own decisions that affect everyone else. Or what's a better/healthier thing to focus on

I always thought leaders who use really super vague language to pretend like it wasn’t their decision, are bad leaders. Also when they engage in obvious gaslighting by claiming to be speaking/acting "for the people" or "wider community" or whatever, without even naming anything specific. Like the "wider community" asked for avif/webp instead 😂

Idk who appointed him as "god of the internet" but if that's apparently his position then I don't see how it's not healthy to hold him accountable like any other bad leader.

"Oh absolute god of web codecs" at least

Holding individuals in power accountable for their own decisions, seems very healthy actually the more I think about it...

And questioning why they have that power...

accountability suits only those whose arguments resist scrutiny very strongly even from agressive critics

citing mysterious superiority numbers for aivif they allegedly based decision on and not immediately producing them was already suspect, but then 2 months later dropping a compare that was 2 years old featuring the very first jxl snapshot ever integrated in chrome that doesnt represent the massive improvements since ?

at least falsify compareasons less incompetently...

Please don't falsify comparisons more competently 🙂 Just try to do fair comparisons...

Their own ssimu2/butteraugli comparison charts showed AVIF getting clowned on too

But metric scores are kind of a joke to begin with

It's funny that they made all these graphs showing avif eating dirt compared to jxl tho

While telling everyone that the comparison shows the opposite of what it actually shows

Most people aren't going to actually click through the links and pages and see what it shows though

And the decode speed data was pretty bogus of course too

But all that's just getting lost in the details

The big picture is the absolute hubris of this guy, a leader with a huge amount of power and trust, using it to push his own half baked projects and shut down better planned alternatives

With all the classic weasel words and gaslighting of a corrupt politician

Oh that 0 becomes -1 now

what a strange exchange

well, maybe not that unusual on reddit

The topic isn't about Jpegli however

Another example why separating jpegli from the rest of libjxl just doesn't help anything...

The TWAIN Working Group issues a White Paper entitled "The Benefits of Adding JPEG-XL to the ISO PDF Standard and PDF/Raster": https://www.linkedin.com/feed/update/urn:li:activity:7287837787855224832

from previous teases and meetings its apparently a much more serious effort than implied and meant to cover the entire spectrum of imaging pipelineS (software, devices, cloud, authoring, interchange, digital signing from scanner to cloud...)

the twain connection is this isnt only about jxl futureproofing pdf, but the nextgen replacement for tiff itself (based on a upcoming revision of the pdf spec)

What does the current standard use?

Wasn't there a thing about the PDF Association doing something to make the spec available for free? If so, would they extend that to include the JPEG XL spec if it became part of the PDF standard? 👀

TIFF is appealing from a document scanning perspective because of CCIT compression but it's not good for security and metadata. PDF if much better. Nowadays people want to use PDF metadata as a data source but the file sizes often required capturing the images as TIFF and then run a conversion process on images to PDF. So if they could have the benefit of TIFF-like compression and still all the benefits of PDF then there is no reason to use TIFF any longer. Here is a promotional video on TIFF versus PDF/R: https://vimeo.com/414778270

From stackoverflow, "PDFs in general use internal compression for the objects they contain. But this compression is by no means compulsory according to the file format specifications. All (or some) objects may appear completely uncompressed, and they would still make a valid PDF." Sounds like the objects themselves are not compressed in PDF. In this case an image is an object within PDF.

I think this is a great idea with get PDF Association and JPEG XL working together and somehow make the specification(s) available.

It would be awesome if JXL became an option for PDF, if it meant the spec became free that would make it even better

I think JXL could be particularly great for PDF, especially with patches and splines. Splines for pen drawings, table borders, trend lines, etc, would work out very well I think. Patches are an obvious one for text (in a way which avoids something like JBIG2's character substitution problem)

pdf spec is already free afaik, starting from the final non-draft 2.0 (ISO 32000-2:2020) - problem is that many implementations have not updated from 1.7 and older

This is correct in that PDF 2.0 has been out from a while but people don't upgrade because older versions "just work". There has to be a compelling and financially convincing reason to invest in upgrading. Here is a link to download the PDF 2.0 specification courtesy of the PDF Association: https://pdfa.org/resource/iso-32000-2/

What is the conversion rate between Terajoules and metric tons of CO2? 🤔

I think it's extremely weird to measure energy consumption in terms of amount of co2

Or "power an average us home for an hour"

That seems like such a bizarre and crappy unit of measurement!

Why do people do this?!

It's like they're deliberately trying to obscure what they're saying

Just standard SI metrics please. That includes for data, too. None of this kiB/miB 1024x nonsense either

And Americans too need to stop using their ridiculous quarts and pounds and gallons and miles and ounces

it's not obscuring, it's pointing out what using energy causes

A lot of companies list CO2 savings next to prices now, people have a direct idea that "10KG is heavy" but not "10KW = 47% Coal = 6.8KG" or something

it's literally woke

it's helpful for putting things in perspective

apple reported the marketshare for ios18 (76% of all devices released in the last 4 years, 68% of ALL ios devices in active use that could interact with/reach the app store) and ios17 (19% of devices released in last 4 years, ). slightly lower numbers for ipados since tablets remain usable longer even without updates

not quite jxl-related but that mean a really high % of recent and all ios devices decode jxl out of the box between gallery and safari

And Android just sits there with no support whatsoever, sad

Android support is a weird thing

basically you have three levels at which one could support it, the android toolkit level, android OS level for java apps and the app level. Im not really sure how the first two would wind up working but with A15+ apps can choose to support it if they pull jxl libs themselves

Alas, no real effort is undertaken to support JXL in Android, that I know of at least

At least we have some apps that support it

apps are supposed to handle their own support to bypass os limitations. decoding jxl adds less than 2 megabytes compared to the massive benefits it adds

consider that a web service can serve png/jpg to browsers and jxl to its own apps, displaying higher quality images with smaller filesizes that load earlier and leave lot of room to add ads if desired

People need to start taking advantage of the benefits of <:JXL:805850130203934781> today. Just use the braindead simple js polyfill. It works right now and the more people start using the format now the more pressure there will be for platforms to add support. https://github.com/niutech/jxl.js

People don't have to wait. The more people use it right now the more pressure and justification and momentum for adoption there will be.

The more people use it right now the more battle tested it will be by the time the big boys decide to flip the switch

People need to stop hesitating and waiting around and just use it already

I feel like WASM would be a great for that

Oh, it does use Wasm. Neat

Yeah. It's ready to go. People should be using jxl to save storage and bandwidth right now, today, instead of waiting around.

Maybe that will incentivize Microsoft into adding oob support for it in Windows sooner.

Or even Android

Apple is already all-in

wasm is sloooooow

use the jxl-oxide extension , at least it doesn't bring browsers to its knees

What extension?

Of course it will be faster once a native decoder is included but in the meantime jxl.js is perfectly ready to use right now.

Just because it could potentially be faster and better optimized, doesn't mean you shouldn't start using it right now. There's no excuse when the polyfill is so easy to use

zamfofex's extension

unfortunately he deleted the repo with the jxl-oxide update, tho I have an archived build here https://cdn.discordapp.com/attachments/673202643916816384/1331819433487765526/jxl-oxide-mv3.7z?ex=6798efc0&is=67979e40&hm=23549a6550579eeaafc3597b37ae758bdf1ff648c191251fa718e0f24193f6d5&

you can find the libjxl version archived here https://github.com/FOSS-Archives/jxl-crx

any issues with it? wondering if anything motivated shelfing the code and if republishing as a new extension would be fine

uh, I can't find the code any more and zamfofex's github entirely was nuked

couldnt he be contacted for a copy of the latest snapshot of that branch? i think hes active on sourcehut with an email address i assume is reachable

no idea, maybe, but I have a compiled extension which is as much as I need [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

is above zip the latest snapshot thats based on oxide or have there been newer commits without builds ?

I found a newer fork https://github.com/Alex313031/jxl-crx

jxl-oxide was a branch that was never merged

but it has the best perf

Why would the speed be any different

jxl oxide vs libjxl? dunno, can think of a few reasons, but the main thing is that it doesn't cripple the browser when you load a lot of pictures

better wasm optimisation?

Likely just using a thread limit or lazy loading

LLVM is also much better at autovectorizing Rust than C because of all the static guarantees, which might have something to do with it

But I don't know if it outputs Wasm with SIMD extensions, from what I remember it wasn't stable in some browsers but idk where it's at now

the png handling from image-rs started outperforming libpng by removing manual SIMD, and replacing it with serial code with some 'hints' (like iterating over `.chunks(N)` of elements in an array instead of individual elements) on top of the static guarantees that already help a lot

can I #doubt this statement? 🙂

(well, ok, maybe it is _better_, but is it _good_? eh)

I think its more likely that jxl-oxide is less greedy, and rust wasm in general is really optimized in my experience when comparing to other languages

Absolutely. Here's some more reading on it. This post itself contains some links to resources and a quote from an LLVM developer, if you're interested. https://redlib.nl/r/rust/comments/1ha7uyi/memorysafe_png_decoders_now_vastly_outperform_c/

PNG doesn't really have a lot of meaningful code to vectorize

Wouldn't it be good for its row by row filters?

yeah but those are the equivalent of hello world for autovec

anything slightly more complicated, and you're out of luck, usually

Hmm

Well, if you do end up reading the post I'd be very interested in your take on it (but you don't have to!)

I think it's just well written code

IIRC fdeflate is pretty well optimized

and in general rust-png manages to put together a bunch of tricks from a bunch of different png/deflate impls

(but also, for some reason it's meaningfully slower when integrated in Chrome on Windows, and I'm not sure they got to the bottom of it)

Oh I see

When jxl-rs is working I might fork it and replace some manual SIMD code with serial code that might autovectorize well, and compare the results. It'd be interesting to see how well it's able to do

If anyone can optimize the hell out of image compression it's veluca

He could give Yann a run for his money

https://news.ycombinator.com/item?id=42868394

https://giannirosato.com/blog/post/88x31/

> I don't care about lossy compression.

that's the most hackernews comment they could have posted

I miss exclusively lossless formats. How many times have you stumbled upon webp file on the internet and it was actually lossless? For me it's 0.

I've submitted some lossless WebP images to Wikimedia Commons

I have posted some on discord

Probably libjxl is making some bad decisions for such small images. It isn't really taking signaling costs of palette or MA trees into account properly for deciding what transforms to do, and for small images that can make a big difference.

libjxl still has a huge potential of improvement

I'd say 5 or 6 that surprised me, but I've only checked maybe a dozen times total

The paper is now available at the bottom of their website <https://twain.org/#/user/home>

I hadn't seen this one yet: https://digitalcommons.lib.uconn.edu/libr_pubs/73/

> It should be remarked that this speed may be partially attributed to JPEG XL’s more concerted use of available memory resources during encoding > > Still, it should be remembered that JPEG XL’s novel predictors, adaptive, image-specific context modelers, and its use of rANS have yet to be fully exploited as the standard is new, and more mature encoders await development around the specification. > Among the lossless bitstreams examined, it is uniquely expressive and poised for future refinement through the adoption of techniques like AI heuristics. > Notably, JPEG XL’s adjustable effort feature, if pareto optimized for given image content, holds the promise of a highly efficient, best-in-class lossless compression scheme that can effectively leverage available hardware resources to work fast and at scale within production environments.

A shame it was 0.7, otherwise their only complaint about memory usage would be null and likely a higher effort setting used

I have drafted a ~60-page 'definitive' paper with an extensive overview of the JPEG XL codec, describing its features and coding tools, the design rationale behind it, as well as its performance, history and potential future. Does anyone here want to proofread it before it goes public?

Could just upload it here similar to spec drafts. Give it a few days and then move ahead if no problems are brought up

I guess. Well it's too large for discord but I could share a Google drive link.

Currently still waiting a bit for feedback from the co-authors, will share it here after that, maybe in one or two weeks

Of course, we would love to help proofread it

How technical is it written? Designed for the average person to understand, or assumes pre-existing knowledge about digital compression?

Like how your modular mode blog was written in a way such that it was easy for anyone to understand

Maybe a bit more technical than that, but I try to keep it accessible for a relatively broad audience. In general I don't like to obfuscate stuff and prefer simpler, more intuitive explanations...

There's no such thing as the average person

My favorite line from George Carlin: Think of how stupid the average person is, and now realize that half of them are even dumber than that!

I would say with technical things it’s less “stupid” and more they just haven’t / don’t want to learn about it

It's good to respectfully explain things and give people the tools they need to understand but I believe one should never try to cater to "the average person"

Otherwise you'll spend way too much time and energy on a lost cause

I get what you mean, like don’t be overly technical for the sake of it but also don’t dumb it down? Like if they are serious about learning about something they will find beginner resources or ask ChatGPT or something

Yeah, there's definitely a balance...

Like everything in life...

Show them the answer but don't patronize your audience 😂

When things are explained too much it seems condescending and patronizing, but when things are explained too little and abbreviated too much it's equally annoying,

Like when you read a wikipedia article about mathematics for example, it looks like the editors are just wanking themselves rather than actually trying to explain anything. Using as many abbreviations as possible and giving circular explanations/definitions

Like one big lexical circlejerk

As horrible as the American education system is, it's actually still better to read a math textbook than wikipedia

Gotcha even worse than JXR! https://cloudinary.com/documentation/image_optimization#automatic_format_selection_f_auto

> ```Format Size > AVIF 14.6 KB > GIF 98.0 KB > JPEG 33.5 KB > JPEG XL 21.4 KB > JPEG XR 17.3 KB > PNG 190.0 KB > WebP 16.1 KB```

Probably quality target difference? Compare butteraugli scores

Using `shoes.jpg` as the example, I'm comupting image density using butteraugli x BBP (lower is better)``` Webp - 1.487 Avif - 1.683 Jxr - 1.992 Jxl - 2.263 Jpeg - 2.899 Gif - 28.545 ```

WebP reigns supreme once again!!! <:WebP:1279637593868210368>

``` shoes.png Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ----------------------------------------------------------------------------------------------------------------------------------------- jxl:d1.55 176 16433 0.7469545 4.205 86.111 2.17507445 80.38877953 42.45 0.86283314 0.644497133453 1.625 0 webp:q88 176 17896 0.8134545 5.431 122.474 2.05666547 81.04900746 44.09 0.89323529 0.726606304308 1.673 0 avif:q76:s6 176 16445 0.7475000 3.116 50.399 1.95412452 85.17212171 45.83 0.83176362 0.621743302693 1.461 0 Aggregate: 176 16911 0.7686811 4.144 81.004 2.05998159 82.20330290 44.10 0.86224537 0.662791742696 1.583 0 ```

looks to me like avif is doing best on that particular image

(taking this as the original: https://res.cloudinary.com/demo/image/upload/c_scale,w_500/f_png,q_100/docs/shoes.jpg)

Secretly promoting AVIF 🤔

Huh, I would've expected VarDCT to do quite well on fabics/mesh. Wonder why AVIF is scoring so much higher than the others

it's probably because the downscaling loses most of the details

``` shoes Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ----------------------------------------------------------------------------------------------------------------------------------------- jxl:d1.2:6 3154 296535 0.7519217 20.278 268.454 1.91911983 81.45397105 44.55 0.68715054 0.516683429136 1.443 0 webp:q88 3154 303580 0.7697857 10.990 182.851 2.11728089 78.71800776 45.24 0.94099905 0.724367605276 1.630 0 avif:q79:s6 3154 303550 0.7697096 19.156 164.667 2.15847058 81.14123619 47.47 0.93719407 0.721367294283 1.661 0 Aggregate: 3154 301203 0.7637592 16.222 200.689 2.06225438 80.43773833 45.73 0.84623348 0.646318618881 1.575 0 ``` on the full res original (https://res.cloudinary.com/demo/image/upload/docs/shoes) I get results much more in favor of jxl

depending on which metric you want to believe

e.g. aligned by pnorm, it looks like avif is only marginally better than webp, and jxl beats both by 20% or so: ``` shoes.jpg Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ----------------------------------------------------------------------------------------------------------------------------------------- jxl:d2:6 3154 177947 0.4512190 20.195 275.522 3.11908120 73.10846165 41.10 1.07242683 0.483899330224 1.407 0 webp:q83 3154 223950 0.5678685 12.619 226.072 2.42254913 74.12132886 43.29 1.08416923 0.615665511782 1.376 0 avif:q68:s6 3154 218230 0.5533643 21.115 160.492 2.92978614 76.55863516 45.03 1.07835185 0.596721412362 1.621 0 Aggregate: 3154 205645 0.5214533 17.523 215.420 2.80787906 74.59614189 43.11 1.07830532 0.562285852336 1.464 0 ```

so even for the same image scaled to different resolutions, results can be quite different. And also of course every metric will say something different...

The OG report to the resident Discord Dev https://discord.com/channels/794206087879852103/805176455658733570/1331809146156220416

For some reason clicking on it takes a very long time to request the higher res preview. Guess the AVIF or the tonemapping is taking ages

That sucks. We used to have a convenient way for sharing HDR images using AVIF.

Why punish everyone?

It's an update to the WebP thumbnails, the original AVIF is still the same if you download it

`yuv444p12le(pc, bt2020nc/bt2020/smpte2084), 3840x2160`