JPEG XL

The problem is, the Chrome Codec team refuse to agknowledge that JPEG XL is competitive with AVIF. They've published benchmarks and comparisons stating that AVIF is superior, while simultaneously disproving that fact if you look at the charts. They ignore all criticism and pleads for reversal. The patch to reintroduce JPEG XL support is kept alive on the backburner by the developers here, being used to reinstate custom forks of Chromium with the functionality. Apple said yes. Adobe said yes. Samsung said yes. DICOM said yes. Intel, Nvidia and Disney published [this](<https://jcgt.org/published/0014/01/04/>) paper the other day. Mozilla said they would consider adding support once JXL-RS is complete, on track for the next few months. Microsoft have 'unofficially' (No announcement and the OS isn't yet updated to recognise it as an image format) released native support via WIC plugin on the Microsoft Store the other day. The world is slowly being saved by JPEG XL, but the Google Chrome team seemingly close their eyes and try to ignore it. Also remember Google is in control of SEO. Their page on 'responsive images' doesn't even mention progressive once, only resizing them to fit displays...

Chrome users don't switch no matter how disgusting the browser is now

lol don't worry. AVIF and WebP tech lead Jim Bankowski is hard at work pushing AVIF support that nobody asked for. You should just use AVIF and forget about all the inadequacies and missing features. According to Jim there just isn't enough wide ecosystem interest in anything else but AVIF anyways

There's just no interest

Apple and Microsoft and Adobe and Meta and Intel and Disney are just nobodies

It's not enough for Jim. There's WAAAAY more interest in webp and avif

Remember how excited everyone got with those formats?

Good thing he's in charge of deciding what codecs are allowed to stay in Chromium.

Right, so we take it above his pay grade of sorts and get overwhelming support from 2 main key players: SEOs and WordPress. I have a pretty extensive SEO network and I'm getting together a one-pager right now and get the ball rolling there in community support. I also have quite a few big names as close connections, so I'm guessing support would be easy here. But to add on to that I'm brainstorming ways to get the issue directly in front of the Search Team. While Jim might have his head in the sand, the SEO and business benefits are undeniable. Hell, chances are possible that this isn't even on Gary or John's radar. I knew about JPEG-XL, but I had no clue that it got denied at Interop 2 times (now 3)! Images aren't something we worry about on a day to day basis, even thought its a pain in our ass almost daily. Maybe we just need the *right* person at Google to say YO WTF. I can also do something similar with the WordPress community and I'll even reach out to Matt and the performance team to see if we can get a specific initiative or cohort started for JPEG-XL - which WP doesn't currently support, but I'm bullish on their dedication to not only making the web more performant, but a better place. Then we go after business owners. Tell them how it would benefit their business and how it saves them money - the only two things they want to hear. And if they still want to play hard ball I'll start running ads and create a We The People petition with the White House. 100,00 signatures needed in 30 days needed for the White House to officially look into and require a response to Google's borderline anti-trust behavior in not supporting JPEG-XL. Uh oh. Aren't they currently having issues with Chrome right now in this regard? We either force them to concede or make them die on the hill.

If anything at that point they can't insult our intelligence with some bullshit like "it doesn't have support" 😂

I created a open Word Doc for brainstorming. Feel free to add corrections or anything else I'm missing: https://docs.google.com/document/d/1A7uuIsxstGbceDBJyNhSv9LBiGx-Kb517R30TZNLBoM/edit?usp=sharing

"JPEG XL"

If you shorten it to JXL, nobody outside of this conversation is going to know what we're talking about lol

yeah but it's without a dash

OH

(though Apple gets this wrong too and it's not like the JPEG committee has historically always been that consistent in its typography either)

Fair. I still don't know if there is a difference between JPG and JPEG 😂

Also, who can I reach out to in order to ask about getting on the team for the website? SEO needs some work haha

it's JPEG, but historically due to MS-DOS 8.3 filename conventions, `.JPG` has become the most commonly used filename extension

the jpegxl.info website is a community website, you can make pull requests here: https://github.com/jxl-community/jxl-community.github.io

CLUTCH

the jpeg.org website is the official committee website, if you have suggestions for that one I can pass them to the right people within the JPEG committee

<@594623456415449088> has been doing most of the work on the current version of jpegxl.info so you may want to sync with him

> Maybe we just need the *right* person at Google to say YO WTF. I have been hoping for this to happen ever since that Halloween 2022 announcement by the Chrome devs. Now with even Microsoft adding jxl support, it is looking more and more like a "YO WTF" situation.

I used to have installed an app that can search all .jpeg files on macOS and convert them to .jpg

I agree! And when I saw the interop post I did what most users probably do - I went to wikipedia for the comparison. When you look at this (assuming these facts are correct), JPEG XL is the only one that is has everything. Definitely YO WTF

Did anyone test on Win11 if trying to open *.jxl file without plugin installed would prompt you to install it?

i *think* that didn't work, but not entirely sure if i actually tried that the support for the file extension seems to be just missing in general though, as i couldn't even convince Photos to open a .jxl file without changing the file extension to that of another supported image format

AFAIK Photos app generally uses it's own decoders, not system's

the vm i tested this on is on the insider branch, but it keeps failing to install some update, so maybe something changed on the latest build

pretty sure it just uses the WIC ones? it did decode images with the extension installed + images renamed to convince it to open them

hopefully it also renders hdr images properly, can't really test that in a vm i think

Photos only uses first party WIC plugins, for whatever reason it refuses to use third party ones

I mean, it DOES save money to be able to transition away from JPEG, without sacrificing any features.

Yeah, I'm really bewildered at how literally CAPTAIN WEBP is lecturing the rest of the internet how there "isn't enough interest" to keep jxl in chromium

It really is insulting and bizarre and I'm amazed that nobody else seems to be more bewildered like I am.

Actually, most normies will only see the file extension in the file manager or url bar and won't ever see "jpegxl" spelled out like that

So most normies are more likely to see a "jxl file" and not have a clue what "jpeg xl" is

They might just think you're talking about an extra large jpeg :)

Something weird is wrong with it I think. I downloaded one, and when I opened it, it opened it in the windows 10 (?) media player. But I also used the .dll method

Man, not even a DOS thing apparently... it's old as Jesus, far back as when Moses wrote the Bible on his CP/M computer

Even DOS supports long filenames

its also shorter to type!!

aiff tiff flac djvu docx html... filename suffixes (suffices?) do not need to be 3 letters anymore

at some point we wanted to extend the "minimalistic header" philosophy of JPEG XL also to the media type and filename extension, making it `image/j` and `.j` — but that idea was shot down quite quickly by the rest of the JPEG committee

anyway it doesn't need to be 3 letters but `image/jxl` and `.jxl` do make sense to me, making it `image/jpegxl` and `.jpegxl` (or `jpgxl` or `jpxl`) does not look better to me

Ha. Yeah, jxl looks good.

I personally think JXL is a better name just because it makes it less likely that you get asked the awkward question of why the image *compressor* is called extra-large

Increase the weight and girth of your images with our new codec JPEG Extra Lard

Does the XL stand for anything?

Yeah

Xylophone Loong

I know that Microsoft had JPEG XR/JXR, but I am not sure that anyone else used it.

Well they said XR stood for "extended range" so I guess XL stands for "extended... loong"

JPEG Excellent Looking?

🐉 looong

looooooooong

It seems like they developed JPEG XR for WIC, as it supports every WIC format in existence.

I think that's a Chinese noodle dragon

Despite the name, don’t try to eat the dragon! It’s not that kind of noodle 🍜

We have been blessed by its noodley power

Blessed with the ability to compress images for a long time

Ah so *that’s* why the libjxl source code is so messy! It’s not spaghetti code, it’s noodle code!

That's the idea anyways. That this format will be around for a very long time squeezing out extra performance and untapped potential for decades into the future

It's noodle code yes

Still no clue what the X is for

But that's not where you want there to be noodles unfortunately

JPEG extremely long term?

I told you, it stands for **extremely extended xylophone**

awww 🍜 😞

JPEG Extremely Long ||compression time because you decided to use -e 11 like an idiot despite being warned by the community about how slow it is||

From day 1 it looked like the most absurd form of gaslighting coming from the most absurd person to attempt it.

imagine how many bytes we could have saved

Hope one day "X" will support "J"

what about web users

they'd need to add js libs to decode them?

Just support JXL file uploading for media attachments. Images are always reencoded anyway, even normal JPEGs.

ah yes let me make your picture bigger and of worse quality

"Cant be clear on our own positions without breaking confidentiality" Thoughts?

I think they mean that being totally open about their position might reveal things that they aren't supposed to reveal with a confidentiality clause

like employers and the like

"we do this X thing at $dayjob and it works really well" kinda stuff

I just understand it as “can’t be clear about interop members’ positions without breaking member confidentiality (i.e. what is being proposed)”

that person’s previous two comments seem to give context

actually, previous three

the talk about transparency is distracting from a disturbing fact: that there's secretly granted veto powers that **override** the entire point of interop discussion and voting

we know apple is wholly supportive, mozilla is about to be onboard, microsoft is... who is this shadowy "mister X" who goes against the web and gets his antics covered up by the interop group despite the harm he causes their entire credibility ? is it someone actively blocking this himself (whatever the reason) or an outsider that *orders* the interop representative for his company to vote dishonestly and non-representatively (against their conscience and company's interest ) ?

Must be Mosaic

what camera apps out there use jpegli/xl?

None currently, but I'm trying to get jpegli integrated into the Photon Camera app personally.

issue/pr link?

No, a discussion on Telegram 🙂 I just realized I can open up a feature request on the repo 😂

since no one seemed to give the genuine answer: 'X' is used in the current series of JPEG formats, and the 'L' is for 'long-term' because it's designed to be future proof

its the 10th?

The meaning we came to here was `JPEG eXtended Life`, since you can transcode original JPEG files and it's made to be futureproof

tbh I still don't know where it really comes from, nobody in the committee seems to remember or feels like telling me, and the name was already chosen before the call for proposals was launched and I got involved

My best guess for what it really means is that it's just a tongue-in-cheek reference to the t-shirt size that contrasts with XS, which was one of the main active projects JPEG was working on when the CfP for XL was being prepared. JPEG XS has the S mostly for Speed (it's ultra-fast/low-latency) but it can also be seen as "small" in the sense of circuit complexity and amount of codec features (it's a lightweight mezzanine codec). So in that sense, JPEG XL is kind of the opposite since it has all the functionality, lots of coding tools, etc.

But 'long-term' makes more sense and we have been explaining it like that for years now.

Given the previous format was `JPEG eXtended Range`, I think `eXtended Life` isn't a far fetch

I don't know where this obsession with the letter X comes from, maybe Touradj has something in common with Elon there

one of J2K's file formats is JPX, so it started already there

Then besides JPEG XR there are also JPEG XT and JPEG XS

None of the names make much sense, XR has less range than J2K, and I have no clue what the T in XT is supposed to mean.

Oh and now they're working on JPEG XE, where the E is for Event-based vision (basically sparse images, not full-frame, typically with way finer temporal resolution than what can be done with full-frame video)

JPEG LS somehow avoided the X. It's not a great name either though: to abbreviate lossless I would use LL, not LS which could just as well mean lossy

lets be honest all the normies are thinking of extra large

It kind of is extra large too, in terms of functionality / coding tools, compared to the old JPEG

Well, at least they didn't go for JPEG 2020

We didn't make that deadline 🙂

what deadlline?

<@352830597778898944> Yeah I was about to ask whether Musk was in the committee

I thought ur standard for Lossless & Scaleable

he might consider supporting it because of it

could be the gate of entry to mainstream for jxl

Jpeg XL was standardized in 2021, they missed it by one year.

the source for that claim on wikipedia is a post on the gnome gitlab that quotes you saying it's long-term

the wikipedia article is how i got to know it as "long term", it's funny how often you're the source for anything JXL related haha

Extended Life is a backronym that I personally like

but it isn't what it came from

I personally prefer eXtra Large.

"Extra Lovely" 😄 from: https://youtu.be/VJaa1Le4W7c

its to describe jxl users :)))

lollolololol this is great

That's very... Odd... IrfanView seems to be using a different way of decoding when using the image comparison tool. Left is opening normally, right is in the tool

i don't see a difference?

You don't?

they look identical to me

first is dithered, second apparently smoothed (closer to real appearance?)

It's not resampling, and applies even when comparing the same JXL against itself

djxl outputs the image on the left

I should add, this is a transcoded JPEG

what is the output of jxlinfo

```box: type: "JXL " size: 12, contents size: 4 JPEG XL file format container (ISO/IEC 18181-2) box: type: "ftyp" size: 20, contents size: 12 box: type: "jxlp" size: 18, contents size: 10 JPEG XL image, 3840x2160, (possibly) lossless, 8-bit RGB num_color_channels: 3 num_extra_channels: 0 have_preview: 0 have_animation: 0 Intrinsic dimensions: 3840x2160 Orientation: 1 (Normal) box: type: "jbrd" size: 483, contents size: 475 JPEG bitstream reconstruction data available box: type: "brob" size: 485, contents size: 477 Brotli-compressed Exif metadata: 485 compressed bytes box: type: "jxlp" size: 4030837, contents size: 4030829 Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative```

I have to zoom in to notice on my phone

But I notice that it's worse than you say

Right image *is* still dithered, just found the bayer pattern where the smoothing hadn't covered it up

It's not just dithered, it looks like it actually has less dynamic range

More quantized

As if it was decoded to the wrong bit depth or wrong transfer function

Not enough different shades of black

Left image is also near-identical to the JPEG source, but that makes it even stranger where the extra quality is coming from. Decoding with djxl to 16bit didn't change anything

The one on the right looks like it's being decoded at a higher precision or bit depth

Try decoding to linear float?

Well it's far brighter, but decoding to PFM and then to EXR for viewing... I *think* it worked

Considering one of the selling points of transcoding is increased decode quality, is libjxl quantizing early or not using the right buffers?

I suspect the comparison tool is decoding to a float buffer?

??

Default djxl and Irfanview are identical to the original JPEG like I said, but obviously decoding to float and then dithering/quantizing is the way to go... Which is what libjxl was meant to do since 0.11

But, the comparison tool has dithering too, which is only output when 8bit int is requested... https://github.com/libjxl/libjxl/pull/3090

Apologies for the low res, but whatever it's doing, it's causing far less noticeable dithering from libjxl

It's happening to JPEG input too, but not PNG

Opened the comparison tool, loaded the image inside the tool, closed the tool, then right clicked....

So it's only loading the right buffer once the image is already loaded? Maybe there's a line of code in the wrong spot :P

Waterfox decodes with the smoother image for both the original JPEG and the JXL

But FFMPEG decodes with the quantization

Which is the standard defined compression method?

Hmm?

It would seem, my IrfanView install is broken... Opening the same png in Microsoft Photos has the 'smoothing' and doesn't look like.... This

I figured it out... The gamma correction setting for resampling was also applying to chroma upsampling

Well that was a good waste of 2 hours, thanks IrfanView!

Almost a decade old issue https://irfanview-forum.de/forum/program/bugreports/11102- https://irfanview-forum.de/forum/program/bugreports/12482-

At least now I know never to enable it again :P

The best quality dithering algorithm I found is written in go

It includes ordered dithering with custom/arbitrary dither matrices

If any devs would like me to link it

Sadly it's written in Go and I don't think it's freely licensed either (unless you consider gpl to be freely licensed)

I'm wondering what the pattern looks like

also `.docx`, `.xlsx`, `.pptx`

damn, xlsx is surpassing RTX 4090

ElonMuskOffice

It's because of XML

being a package of the XML files with resources

OpenDocument, also XML-based, avoided that

although its predecessor (OpenOffice.org XML) apparently didn’t

(it used `.sxw` for text, `.sxc` for spreadsheets, `.sxi` for presentations)

Seems microsoft's WIC extension for windows apparently received updates since initially becoming public (from 1.2.21.0 to currently 1.2.24.70)

Windows 11' insider branches got updated since too so might be worth checking if anyone's got both installed

Seems the store page's description added some clarification i dont recall in the initial one *"You can set JPEG XL images as a desktop background and open JPEG XL images in Windows Media Player Legacy. Support for JPEG XL is coming to additional apps."*

mine is at 1.2.24.0 and the store doesn’t detect an update for it

there might be a non-userfacing distinction between .0 and .70 or essentially same build

afaik .70 is just what's put at the end of ¿encrypted? versions or something weird like that

basically just ignore the last decimal number because it's some internal Microsoft store versioning nonsense

given that Windows Updates shows me automatically translated update identifiers (KB<a bunch of digits> becomes Ko<a bunch of digits>…), I would be only about 80% surprised if they somehow translated version numbers and messed up update detection in that way

(still quite surprised, but not as much as I arguably should be)

That lines up with the description another language had, so maybe just consolidating? https://discord.com/channels/794206087879852103/822105409312653333/1347420328984444928

I want to write a section about OS support for jxl. What's the situation in the various Linux distros? Which ones support jxl out of the box and since when?

besides direct availability (preinstalled or as a required dependency for important software) there's *snaps* and *flathub* versions of apps that work everywhere and are autoupdated to easily include the support without breakage risk (like zen browser, which flathub shows with 280.000 installs)

mx linux and endeavous (manjaro but done right basically) supported libjxl but their recipes for repology were never updated

the COSMIC desktop environment supports JPEG XL wallpapers

distrowatch can list packages and versions for all known distros but can lag behind

On any Linux distro there is of course one way or another to install libjxl, if needed by manually compiling and installing, but I am wondering on what distros it is there out of the box on a default install, as in, if you view a folder in the default GUI file explorer thing, you can click on a jxl file and it shows the image somehow.

linuxmint 22.1 (native debs, preinstalled, mint's 'X apps' that are forked from gnome apps are crossplatform with few dependencies)

I think distros which offer KDE Plasma 6 as an option does it? at least NixOS did it

the recent versions of the Eye of GNOME image viewer support it, which I imagine is the default on many GNOME based distros I imagine?

in distrowatch, go to any distro's page. in the spreadsheet, there's a link to the full list of packages in the distro's releases (for mx linux the list for 23.5 shows libjxl 0.7)

also things aren't always as black and white, for example in COSMIC you can set JPEG XL files as wallpapers because `cosmic-bg` supports it, but COSMIC Files does not (yet) show image previews when selecting JPEG XL files. that's contingent on `image-rs`, which is used in their GUI toolkit (`libcosmic`/`iced`), adding JXL support which they don't want to, though the COSMIC people did say that if someone wanted to patch COSMIC Files to manually add one of the Rust-based decoders to work around the image-rs limitation, that'd be accepted

Well, we did have Ubuntu wanting some fixes to try and get JXL support in main, but who knows how long that'll take https://github.com/libjxl/libjxl/pull/4111

bicha suggested here they may want to make it part of preinstalled packages by 25.04 or 25.10

If it's the image-rs limitation I think you mean, that was resolved with jxl-oxide

yeah exactly, but last i checked that wasn't done by default in libcosmic, so if you write libcosmic applications and want them to support jxl you can't use the gui toolkit's default image features and you'll have to hook into jxl-oxide (or others) yourself

cant select them via gui tho

also iced doesnt support jxl so you cant view them either

right, that's what I said

ah i hadntread that far yet

I have a fork... somewhere with support

oh sorry i assumed you replied to my later message

gdk-pixbuf and kimageformats is in a good place rn

I had an [idea](<https://projects.blender.org/blender/blender/issues/135735>) for Blender set as a 5.0 milestone, which reminded me. Dependancy updates can only happen with major revisions, so maybe we should push for JXL support again given the recent developments. It should be *relatively* simple to make a PR even, it's been done already but the owner vanished so it was left as a draft

....I really wish I knew enough to tell if this was complete or not. I can't see anything obviously wrong, but I can't see any mention of depth channels either https://projects.blender.org/blender/blender/pulls/119257/files

it seems to rely on OpenImageIO to actually do the work

https://github.com/AcademySoftwareFoundation/OpenImageIO/tree/main/src/jpegxl.imageio

(“oiio” in the blender code you linked to)

depth seems to be on lines 304-305 of your link

Repology works better for that, it's what creates those badges on the libjxl github readme: https://repology.org/project/libjxl/versions

in all major linux distros libjxl is available as a package, and most of them seem to be up to date too (at least in their current distro versions)

I guess I'll just write something like that instead of trying to figure out which of them support jxl out of the box (i.e. in a default install, without needing to install a package)

Repology underreports, mx linux, endeavouros and others preinstalled or packaged current libjxl since long

Or immutable linux distros or editions that dont work with repositories but favour or require use of flatpaks

whats the markdown syntax to align the image to the right?

no idea, why align it to the right?

Unfortunately that's just bitdepth, not a depth channel. So I suppose the implementation was never finished

updated adoption. Paint.NET 5.1.5 now handles jxl out of the box, bundling null54's plugin https://forums.getpaint.net/topic/133399-paintnet-515-is-now-available/

seems gimp tagged 3.0.0 for stable

Apparently FFMEG doesn't have effort 1 lossless, it's the same output as effort 2

Effort 1 requires passing the image as uint8/16, if it is passed as float32 it falls back to e2

Nope, neither Ubuntu nor Debian support jxl thumbnails by default. The claimed so-called "support" is just manually installable libjxl package.

I was talking about the Eye of GNOME, the image viewer. so you'd be able to open them and view them

I would guess they either don't use EoG, or manually removed support from it.

I had 0 free(time_t now - 1 year) to finish that. Also, I intend to improve stereo and multiview support. But that would represent more effort than 1 man show.

Ahh, so you made the PR? I was hoping it could be ready for Blender 5.0

Maybe.

it also handles thumbnails in explorer. although sometimes explorer gets spazzy and still uses their WIC codec (if you have it installed from the Store) which has problems with alpha

Does it fully decode images for thumbnails, or does it use 1/8th size partial decode for faster decode when image is big? Also, does it use multithreading?

Full decode

libjxl does not have a thumbnail api

Unlike libjpeg

It's possible but just not implemented in libjxl

Just like cropped decoding

It's probably single threaded too? It wouldn't make sense for a thumbnailer to be multi threaded. First of all it's more boilerplate to set up and second of all it's much less efficient when generating thumbnails for an entire folder full of images.

<@1028567873007927297> this is interesting, do you know what they use it for? do they even use it?

I have a Deck, it's a really great device well worth the money. I can tell you that it was pulled in as a dependency by the packaging system.

And distributed by Valve as part of their Arch based distro

In the immutable filesystem

It's preinstalled in other words

:)

I can tell you exactly what it's used for if you're interested...

I recall gdk-pixbuf was one of the packages that pulled it in

Even though SteamOS uses KDE

Strangely, djxl does have a 1:8 option

Yep, the API does allow you to get a preview frame and progressive steps. At least there are decoder events for those things. I've never tried using them, but apparently djxl does.

Maybe I'm behind the times then.

As far as I'm aware, libjxl only allows requesting full progressive passes, while jxl-oxide allows arbitrary requests. At least that's how I interpret the LQIP decoding

Well that's still good for thumbnails. I haven't looked at the decoder api recently so I guess I am behind the times. I remember a time when you cannot ask libjxl for a smaller thumbnail image. Only progressive decoding.

Only me using the .bat approach on Windows?

sticking to xl converter myself. collection conversions should just make extra sure to preserve metadata (xl converter defaults to wiping metadata, which could ruin a library and require redoing the conversion *if* you didnt delete the jpg originals)

The interface (among all 3 themes) looks uncomfortable

Tried opening it just now and omg it almost made my eyes bleed

Is it true XL converter does not support Apple HEIC input?

vips does at least :)

vips works great

heic/heif was removed in december's 1.1.0 but there's alternatives anyway

one could readd it in their own builds. idk how thourough removal was but since imagick handles conversion and heic was only removed as input, perhaps its just deemphasized rather than fully gone

Maybe tomorrow on Caturday, maybe NeXT week...

It was 2 early... YMMV

This supports JXL https://blyt.net/phxslides/

Phoenix Slides

And someone submitted a related bug https://github.com/gobbledegook/creevey/issues/69

gimp 3.0 released, now with jxl open/save/export

binaries at gimp.org for linux users, its most straightforward to consider the flathub and snap builds since they work everywhere and autoupdate especially if your distro isnt rolling release

already available on Arch 💯

some medias like xda and omgubuntu didnt mention jxl support even though its a big highlight. is there even anyone handling coverage (like corrections, responding to contact requests etc) ?

I'm not sure where contact requests even go

I know Jon replies to emails, and that paper said they 'contacted devs' without anyone here knowing about it... Hmm

i don't think that's new? i can open and export jxl in gimp 2.10.36

and **QOI** > Newer formats like QOI and JPEG XL are also now supported https://www.gimp.org/release-notes/gimp-3.0.html

This proves that JPEG XL is also quite OK

Hmmmm as an outsider it makes me wonder if the "no support" from the Chrome team might be alluding to a bigger...disconnect. Questions like these and the few orgs or entities pushing for it may make it seem like theres no concerted effort or unified push. Why does the JPEG ORG not take a harder front facing role? Is there a reason such as lack of leadership, holes to fill, etc? Not trying to call anyone out just brainstorming possible obstacles and solutions

JPEG is just some weird international bureaucrat committee. Jon from Cloudinary is probably the most vocal evangelist when it comes advertising the benefits of <:JXL:805850130203934781> to the wider world...

The committee just sits in the background, collecting membership fees, and feeling self-important. Not really doing any aggressive promotionals, or anything useful at all really.

The main disconnect is that the key decision-maker who decided there "isn’t enough interest" happens to coincidentally be the man in charge of the avif and webp projects.

After his team was bought by Google, Google promoted him to "Chrome codec team leader" and right afterward he quickly (ab)used his position to fast track unpopular and half-baked image formats into Chromium

Then he unexpectedly declared that jxl has "not enough interest" on the bug tracker that was filled with representatives from a bunch different Big Tech who had previously already expressed their support. Like some kind of gaslighter.

So that's the main disconnect. Even though there isn't a unified, organized JXL industry support lobby, the technical merit alone is enough for a lot of Big Tech to be interested in it by themselves, separately. Like with Apple just deciding to pull the switch all of a sudden without even telling anyone beforehand.

And Microsoft too

Chrome Codec Team is the only stubborn hold-out

And only because the Team Lead is literally Captain WebP

I don't think anyone here knows what to do about that since he is actually the God of the Interwebs. Chromium is the most important browser engine project so whatever he says is Divine Law

<@1028567873007927297> I know that's where the disconnect comes from (or from an outsiders perspective supposedly where it comes from), but I'm not really interested IMO in repeating that as an argument moving forward as one that will bring change. So we strengthen our position and weaken theirs. Feel free to take a look at an edit a rough draft of what I'm thinking of: https://docs.google.com/document/d/1A7uuIsxstGbceDBJyNhSv9LBiGx-Kb517R30TZNLBoM/edit

is this section talking about CICP? because yes WebP doesn't support CICP however it does support embedding ICC profiles which means you can do color management just fine with WebP

I'm back logged revamping my own personal sites ( finally lol) as I'm starting my own SEO agency. I hired a VA and should have things setup on my end. And under two of my main digital properties, I'm going tk have a "causes" section. Where I will state the case, as well as call out Google for them being shady on this issue. Then I will pay for PR campaigns to blast the links. $200 gets sent out to 300+ news and publisher publications for pick up. Every time they release a blog about speed or images, I will release a counter publication and do it again. Next interop I'll repeat. So on and so forth as just one of the many tricks we can use to use the system to beat the system 🚀

I'd clarify that lossy JPEG XL actually outputs whatever color profile you request. So you can get SDR and HDR from the same image on any device (Theoretically, the application could just request sRGB and it's all redundant). It was done so that different color management in different devices don't cause different images to be displayed. By making it part of the format, you always get the same output

At least that's how I interpret it, <@794205442175402004> may have input

I don't even know. Lol the stats are from Wikipedia. But chances are if I don't know, the average user doesn't - and more importantly doesn't care. My angle is garnering support from the unlikely or untargeted group such as SEOS and business owners. I'm not sure how either would use those color profiles, so would this be something worth clarifying? Or can we just leave this as a "JXL wins this box" for the layman terms users haga

Isn't cicp actually better than icc profiles? Afaik icc profiles don't even support hdr transfer curves like hlg and pq?

Plus icc profiles are way more complex

JPEG is indeed not really an organization, but it's a longstanding committee where people come and go and they all have different motivations: academics often go there to find people to write papers with, industry goes there for whatever underlying reasons (it may because they desire interoperability, it may be because they need new reasons to sell their hardware, it may be to get their patented stuff into standards), some are there for just a short time, others are there for decades. JPEG is not an organization with a clear agenda, more a loose collaboration between people with diverse agendas, but the committee as such works by consensus so it rarely makes strong statements or anything like that.

Recent ICC profiles do allow embedding a cicp tag in them so they do support it now 🙂

so in principle you can make an HDR webp, it even works in Chrome, if you don't mind the banding

now I’m curious to try

to see just how much banding it causes

Didn't Discord do this a few weeks ago that someone was talking about here?

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

I wrote a similar article a while back with a similar goal but decided not to release it. Its general thesis: *"How can one asshole at Google cost the world a city’s worth of electricity each and every day from a personal grudge?"* (Definitely written in anger, then edited to be not quite so dickish.) A PR push is a good idea—it was discussed earlier, but I think I was the only one excited about it. We can also keep adding elements to the community site that support our case. I had big plans to do a lot more, but work has gotten really busy, so it’s been tough. I like your WordPress angle, especially if you have pull there. I’ve been harassing the “modern” browser builders like Webflow and Framer to support JXL. I figure with their tight development loops, they’d have a better chance of getting it worked in. Both added AVIF in the past year. With major CDNs supporting JXL, you’d think they’d be on board.

jxl has another issue that implementers and cdns generally distribute webp/avifs of smaller filesizes (more agressively compressed). To counter that, jxls should consistently be generated at a smaller filesize that those formats, as well as served as the highest priority format to clients recognized as capable of decoding jxl

integrating decode capability is only part of adoption, jxl serving should also be maximized and only cdns and large image hosts/lockers can achieve that most efficiently

I think this might be what is working against us, but also at the same time a saving grace. JPEG is old. Older than me FFS (I'm 35 so assuming here lol). What im hearing here is that we have a silent army waiting to go to bat for us that's untouched. How many years, howmany people? Maybe all we need is a solid, unified front.

Capital is power, but true power resides in the side with numbers.

Feel free to send it over to david@daviddennison.com. I will credit with source and dofollow backlink or anon. I am not scared bahaha

Dude I didnt even read past the first sentence. Thats a POWERFUL headline. Thats what Im talking about!

I dont have much pull in the Wordpress Community, as Im only an SEO and they favors devs, naturally. But the Wordpress debacle MIGHT help me because I've been an outspoken, probably one of the only however small corners of the web world in defense of Matt and his work that he's done for the internet (regardless of how you might feel about that isssue, which is neither here nor there in this context.). Maybe he will actually notice me when I call to arms and ask for his support, probably not LOL BUT if there is one thing he needs now, is more show of community and maybe a little press off his ass. So I'm willing to press that angle lol

I am the only SEO ive seen even mention or fired about up about this, which is wild. I've been converting images and optimizing images for 16 years. I. AM. SICK. OF. IT. I refuse to believe that that every other SEO wouldn't see this as a ease to their lives. I absolutely think we can press this issue to get the changes we not only want, but we deserve. I'm not saying im the savior, but Im gonna fucking try.

If you need help with anything I'll see what I can do, I think you have the right idea 👀 I'm a <:JXL:805850130203934781> fanatic too

The other thing that was tossed around was doing a full website for Google, like Google did for Apple: https://www.android.com/get-the-message/

And if you really want to go for it, I'm pretty sure you could sue them in Europe since they penalize sites for not using 'modern' image format. They're impacting the money you make from your site by forcing you to use their lesser image formats… although I'm not a lawyer.

Rcs 🤮

No e2ee requirement in 2025

I freshly re-tried win11 insider after updating the store apps - seems jxl can be opened in Photos (directly opening, Photo app can now be selectable from the list of app for files with this extension)

I changed nothing but jxl is by now by default associated to Photos btw

Didnt check what happens if you dont have the jxl extension installed yet (ie does it automatically download it or prompt to)

Photos is version 2025.11030.20006.0 if that matters

bump

it should be in system32

``` 26b985bbf95d3676d92f32859306ef17cb69e86011c10b8a9fb599dbdf7240f0 *x86/msjpegxl_store.dll 1b23d6619b07abb1737bbc96e49456a61c87505c1eb85b36bb8b9f2a074b934a *x64/msjpegxl_store.dll ```

version is 10.0.27808.1000 and it was signed on march 6, if that helps

sounds as good as preinstalled then. I wonder when they change the jxl extension from a utility app to system app

Have they fixed the alpha channel bug yet?

I have no idea how they managed to mess that up in the first place, libjxl's API makes it easy to read and write transparency data.

why isnt that done automagically instead of making the user click open msstore and install

You mean why it isn't installed as a part of OS during Windows Update?

To reduce the size of the OS image

Other image formats work a similar way

Really? How big is it?

Imagine if you needed to install JPEG decoding as a module lol

the actual files your system will use are about 12mb unpacked, but store reports the total size for all architectures (32 and 64bit, x86, x64 and arm)

when a jxl image is opened

whats the difference between 64 bit and x64

User consent is important, installing executables on opening media files is a quick way to piss off your userbase.

x86 seems to have the extension files only for x86, at around 3 megabytes (odd since win11 is 64bit-only). x64 has them for both x86 and x64

Not big but there is precedent for them to distribute codec packs separately on the windows store

another potential issue is security

there have been cases in the past where windows has been attacked via its built in codecs

Do we know if animation, layered, ect files decode properly yet?

decoder itself didnt change. alpha works, no animation, no idea about hdr, giganormous images (80mp+) can crash after partial progressive decoding

Oh, it does progressive decoding? I was aware of the crashing but hadn't heard anything past 'it opens JXLs'

idk what it does in particular. when opening giant images, the full view very quickly shows image as expected but it doesnt feel fully loaded

Oh, probably using the thumbnail cache

doubt, if it didnt crash itd look fully loaded. thumbnails have very small sizes

I got the same on a (slightly insane) 1 Gigapixel PNG. It would load a 'fit to screen' preview quickly, but if I zoomed in it would freeze for around 3 minutes

For anyone curious about adoption on Windows, here's a Discord where you will find the latest information / hacks / Feature IDs for enablement (not affiliated in any way): https://discord.gg/3caCtrscPj

do you know about something like this but for apple stuff?

Only real option is to sign up for a developer account (free) and look at the documentation. Apple keeps things pretty hush and even for devs to find new stuff its a pain in the ass. Apple's successful war on deprecation to force purchases make it where even if you wanted to build for some new stuff like JXL, you need to have a certain OS version, X-code version, etc which I believe is why you wont find a discord that goes in as deep to Apple as the one above. It also makes it hard to incorporate stuff into their products that they dont want. Only other option I can offer is install the beta versions of their OS for iOS and Mac, and then Google "reddit testflight betas" and you can sign up for beta apps that might include functionality added in beta builds, and they have a Discord as well. I'll keep an eye out for one and post it here if I find another which I'm sure I have but since moving away from Apple for the above mentioned reason, I dont have those discords anymore.

Like imagine if they could support JXL like Windows did with just registering a DLL. Nope not Apple. EASY? ABSOLUTELY NOT IN OUR COMPANY 😂

I also wouldn't even focus on Apple as a driver in this space. They may support or whatever, but they are always behind in tech because they have historically not been a "to market" company. Seen biggest by their decision to move on AI at the pace of a sloth. They got Sid from Ice Age running their R&D lmaooo

https://tenor.com/view/salty-side-eye-funny-as-gif-22465498

yeah maybe something like mpv can view jxl files

but it'll take a while to have thumbnails in Finder

<@352830597778898944> Check out Setapp (https://setapp.com/) but more specifically Path Finder (https://setapp.com/apps/path-finder). Youre more likely able to find support for Mac in this app, or if you want to go one step further. The developer is very active and responds to feedback. I had a crash when I first installed that kepy happening. I emailed him and it was maybe 4-5 back and forth, then released an update a week later that fixed it. So if you want to make the case to him, I'm sure if it's possible he'd be open to it! 🚀

My Mac is is old so only have Monterey available so most stuff isn't support / doesn't work for me or I'd try it for you.

macOS already supports JXL

you caught me speaking straight out of my ass 👍

Apple has actually been leading the industry (sort of) with JXL

They even added it for DNG compression in the iPhone 16 Pros

But Apple's operating systems decode JXL slowly

Unfortunately it's not very common, even on Linux, for images decoders to be sandboxed out-of-process when decoding untrusted input.

In an ideal world it should be as simple as possible on all OS platforms to write least-privilege, multiprocess software, and image codec libs would be designed with this assumption in mind.

Linking everything into one process and one namespace is the dumbest possible design and yet it's the default assumption on all common platforms

And worst of all, devs are disincentivized from developing secure and well designed software because it's a lot of extra work and tedious boilerplate

Hi everyone! Making moves! A buddy of mine in SEO recently made an image optimization tool for our industry. I just sent him a message asking him to build in support and that having his tool as a support could help our main strategy in a HUGE way - Direct access to the SEO community in the image space! I told him that I'm not sure of the technical debt this might incur, but I said I might be able to get someone from the community to help out for the cause so that we can move on this quicker. Any takers by any chance? Here's the website: https://catalystmediaservices.com/

For transparency, this is the message I sent him lol: Yo brotha! For your image tool, I think I might have a project we can team up on, and I may actually need your help on! Any chance your image tool would be interested in supporting JPEG XL? And even better if I could have a strong ally in the space to push for JXL. JXL just failed interop for the THIRD time and the reason is because of Google dumbass hold on webp. I'm planning on playing hard ball with Google if need be and my main strategy for the movement, if you will haha, is support for the SEO community. Not sure how much technical debt this would involve, but I can almost guarantee I can find you a dev that is willing to possibly help for free to get it done. If you check out the discord link I'll include below, you'll see what I'm talking about. There's a fired up community for JXL, and Google is up to some nefarious shit. Would love to have your support and talk further brotha! Here's a link to a Google docs and other resources to get your thoughts!

He has a team and is pretty damn good at what he does, so I doubt he will need it, but wanted to throw this out there just in case haha

In order to add JXL input/output functionality, one would need access to the relevant module source code, for the image input and output handling.

I was thinking about how to push Apple along, and one of the obvious places would be within Apps, as everyone is still using PNGs mostly. You can drop JXLs into Xcode, but many (important) things don't work, like JXLs in the Asset Catalog. So I wrote this article on the weekend: https://www.fractionalxperience.com/ux-ui-graphic-design-blog/jpeg-xl-storage-solution-apple-your-drive-waiting-for Let me know if I messed anything up (like I had to ask 🤷‍♂️ ).

Alright finally launched the rough draft of my own case for JPEG XL if you want to check it out: https://searchriot.com/causes/jpeg-xl/

I had my VA do this and have not had to time to review and make changes yet such as the dash. Go easy on me haha

Suggestion: "no lossless support" is one of the biggest sore spots for avif. Or just the lack of flexibility in general: designed for video, it has fundamental deficiencies when it comes to lossless, arbitrary bit depth, arbitrary image sizes, stitches and seams between tiles, parallel decoding limitations, progressive loading (you have to wait for the full image to be available before you can even START the decoder, THEN wait for the decoder to COMPLETELY finish before anything can even be shown on screen, so HUGE latency problems compared to any other format)

Basically, an extreme lack of flexibility is the theme with avif, since it starts from a severely limited codec. Those limits make sense within the strict constraints of motion video use but not for something that can replace JPEG and PNG.

I also just stumbled across these guys are are rebuilding an open source version of Webflow: https://github.com/webstudio-is/webstudio Would be great if someone could help them out adding JXL

Funny you should mention it! I have this article I wrote way back that I was updating this weekend with references to <@794205442175402004> 's new document.: https://docs.google.com/document/d/1hzpgwdZPtMSVxWegbRg3qofQMYN4ZnK2oW9UXnclufk/edit?usp=sharing

I originally wrote all those almost a year ago, so need to go back and more closely review, as I had some stuff messed up.

And was supposed to go on the site itself, we just don't really have a section for it yet. Need to add to the list.

The real achilles heel of avif is the inability to meet the same standard of expectations people have with JPEG and PNG.

People don't expect a newer format to be less capable.

People expect it to work as a PNG or a JPEG

Not "oh that doesn't work" or "oh sorry you have to wait first, you can't begin decoding yet."

You can't convert a JPEG or even a PNG without some kind of damage.

That's good. I'll work it in.

Agree! I actually think the biggest sore spot foro AVIF is how does everyone support it but NO ONE uses it? Google Search included support about a year ago still have YET to see AVIF in the wild

AVIF, WebP's failed little baby, might be a strong point as well showing that Google is indeed being nefarious. Why can we we move so fast one one image format, and not another?

It's almost like there's "not enough interest from the wider community." Oh wait, no, that's what the avif webp lead said about jxl.

That's why I'm going to get so much interest, I'm gonna make the WebP guy go into retirement

Like what is even the monetary purpose? Or is it just control? I dont see where the bottom line benefit is here

Of them controlling the image format that is

A nonbreaking space would be good between the JPEG and XL

No one. It's just the webp/avif team lead protecting his weird ego apparently. He just happens to be the ultimate guy in charge of "Chrome codec team" as well. Leveraged his position to promote and fast track his own half-baked image format ideas regardless of the broader sentiment or appeal, and to remove the existing mature jxl code from chromium codebase while citing alleged "lack of ecosystem interest." ...Meanwhile Apple and Microsoft added support to their OS products regardless, and the rest of the ecosystem continues marching on to adoption despite Jim and his "lack of interest"

I'm wondering if this is the reason why Apple went with "JPEG-XL"

does Unicode have native non-breaking spaces?

https://jkorpela.fi/chars/spaces.html

U+00A0 NO-BREAK SPACE (`&nbsp;`, `&NonBreakingSpace;`)

What about just shortening it to <:JXL:805850130203934781>? That's not so bad either...

I guess a non breaking space is slightly better, maybe.

To emphasize the compatibility with existing jpeg

sweet, it does work at least on macOS

the character they gave as an example on the site didn't work interestingly

Most people don’t want another image format to complicate their lives. But this is just "improved jpeg" in a way. Since it's back-compatible... and hopefully will come with a complete replacement for libjpeg someday (with support for high bit depth jpeg12_ api soon hopefully and maybe even installable headers for developers?)

Yeah I need to edit a lot of stuff. I just told me VA yo I cant keep talking about this and not have a link lol

0

ad industry would massively benefit even if they only used jxl for the apple ecosystem (ios, ipados, macos, etc) and their own apps (everywhere since they can add any libraries in their own)

itd also greatly boost the appeal of apps and superapps. 'our web service loads quicker, consumes less bandwidth and despite including more ads/analytics still displays everything quicker than when visited in a browser, especially the ads'. CDNs would also benefit from adapting their final delivery formats to apple/apps instead of using one same format for *all* recipients across *all* platforms and *all* content (migrations dont have to cover all content, starting with frontpages and top visited media already would make a difference to iterate from further).

E.g. the most popular phrase about WebP for search results is "how to convert WebP to JPEG"

For most of people JPEG, PNG and GIF are the only "natural" formats they accept

You're talking to an SEO who WILL dive into this. Have you actually done this research (I have not YET)?

Not really. That's how I usually saw on Google and YouTube

As in used Semrush?

Okay give me Idk two days. I'll do the keyword research and see what it says. FML I can't believe I didn't think of this. We can use Google data literally against them lololololololol let's gooooo

HAHAHA HAHA can you imagine Google trying to argue with their own search data. Holy shit that would be comedy

In privacy mode of Firefox

Lmfaoooo I've had a few whiskeys (Mondays) and this is great. What a petty point to make. Will add to doc

The top keywords for AVIF are similar

I haven't looked but I had a hunch. As many have said and I will echo - some nefarious, anti-web, shit is happening.

For JPEG XL or JXL there is no this trend (yet)

More results are related to how to open/view

or JPEG XL vs ___

Hmmm # of search volume comparison, if in favor of JXL could also work in our favor - probably won't tho due to lack of inclusion, which is what Google wants. Add to doc. BTW add to doc is not only a note for myself but my team who I told to join 🤣

Also, I know that we said the jpegxl.info site is open source with pull requests, I am still very noob on the dev side so I cant propose changes in a streamlined way since Im not sure really how that process works on the GH side in terms of websites. Is there anyone that can get me in contact with or tell the actual person thats in charge I would like to have a monthly meeting for changes, improvements, etc. Or does someone have a VA that specializes in GH pull / pushes? I'm a two man team here lol

Here's my GH, so you can see, I use it a...little differently than others. Help would be appreciated haha: https://github.com/davidldennison

ai generated profile

Any Rails people wanna add jxl support to all those image boards that store tons of JPEG and PNG files of anime waifu?

Terabytes of waifu data just waiting to be compressed

I'm surprised no one talks about it. Probably because it's waifu data.

Their goal is to preserve the original status of images

If that's a bloated JPEG or PNG, it should remain bloated based on that principle

maybe we need a PNG reconstruction box

Unfortunately, it's true. I argued for optimized PNG after finding 50MB files that went down to 2MB, but they said it's an archival site not just an image board so they want only artist-verified files

For the general case of arbitrary deflate streams, I would assume that the reconstruction data would be significantly more substantial than that for JPEG. But in practice, nearly all PNGs are produced by a small number of deflate encoders, so perhaps it suffices to just be able to mimick libpng/zlib and whatever else is produced in the wild, and then the reconstruction data could be very small, at the cost of somewhat slow reconstruction (since the lz77 search would be left implicit to be done during reconstruction). Of course if file-exact reconstruction is not needed, you could just stuff all the non-IDAT chunks in a brotli-compressed box and call it a day, then it's basically the same as a png optimizer.

I would probably think when people want "PNG reconstruction" They probably just mean they want a png with the same box structure. most people don't really care about the specific structure of the LZ77 codestream

like the assurance that *all* metadata gets copied one-for-one

it depends, if you expect file sizes and hashes to match then you need the full thing, but I agree that that's not actually needed in most cases

i guess hashes could be an issue

https://blogs.windows.com/windows-insider/2025/03/24/march-2025-microsoft-photos-update-now-rolling-out-to-windows-insiders/ "Due to popular requests, the Photos app now supports JXL files."

The sites me and Meow spoke of would want exact reproduction, and even then might only accept the original files anyway without transcoding. Though personally I'd like a method of chunk reconstruction, even if only libjxl specific, since I've got a few applications that store metadata in custom iTXt and tEXt chunks, that currently get wiped with cjxl.

A lot of metadata cannot be transfered to JXL because metadata support is currently a bit limited, preventing me from transcoding large portions of my images to JXL sadly. At least for TIFFs there was a discussion in the libvips issue tracker to keep TIFF metadata by just using a JXL payload. But, for PNG there seems to be no/limited support for nonstandard tags, as you've said

Text chunks only would be relatively simple. Store them as XMP entries that djxl then adds back <https://github.com/libjxl/libjxl/issues/2641#issuecomment-2268101325>

wouldn't that mean libjxl then needs to be able to parse metadata instead of treating it like a blob? or does it already modify xmp data

cjxl handles XMP and EXIF data, including inside PNG tEXt chunks, already

The hash should be post-undeflate

It's dumb to hash lossless compression unless you are hashing the uncompressed data

It's pretty easy to keep all metadata intact while losslessly compressing a PNG...

Oddly enough artists don't usually know anything at all about compression. Occasionally, they at the very least know that png > jpeg if you are lucky, and that's where their knowledge ends.

Rarely do they know what dithering is, never have they heard of oxipng

depends on where metadata gets stored. big libraries for images might actually work like audio streamers and store is separately from the media files themselves (so the metadata is always preserved but can be reedited over time)

Isn't it simply `djxl`?

Yup. That makes it even easier then!

This isn't about the artist, this is about the sites hosting them

hydrus already supports all that, no ?

Some artists' bad compression ruins their entire artwork

keeping the original files i can respect, makes sense

storage and bandwidth even for max quality originals costs nowhere near what the scaremongerers regularly imply

I got one to start uploading to Itaku in Lossless WebP, and in retaliation they only post JPEG to other platforms now until they add support for something modern

This is a separate issue. Not allowing uploaders to "optimize" files on their own makes sense because people are morons.

But if the site backend optimizes them on its own behind the scenes?

Then it's consistent and more trustworthy.

big integrators would benefit from some help. A lot of the croticisms jxl gets result from flawed implementations for whats good libraries, or bad encoding workflows perpetuating old mistakes

Again, that was 3 separate staff members telling me they only want the original files from the artist. Not changed in any way unless forced to for compatibility

They told you they don't want to allow uploaders to change or "optimize" the files FOR THEM. That's different.

And not for arbritrary text chunks... ExifTool refuses to write them, cjxl ignores them completely

> If we wanted optimized files we would optimize them on upload, we want as close to what the artist created as we can get

What about oxipng?

Oxipng optimizes the PNG, it doesn't help with making a JXL at all

But it doesn't touch any other chunks at least?

If it's a compressed text chunk, it optimizes it, if it's uncompressed it's left

Optimize on upload is a good idea though. I wonder what it would take for them to consider that. For archival it doesn't make sense not to use lossless compression

Yet again, that was 3 seperate staff members. I'm pretty sure they've considered it...

Can't exiftool just convert those arbitrary text chunks to an xmp tag and embed it into jxl?

That's what I said at the start

Well they weren't arguing why it's a bad idea to optimize on upload. They were arguing why it's a bad idea to allow uploaders to upload optimized versions.

That's a good one...

You can, but it is manual work, since the replacement tags have to be specified in an args file that is passend to exiftool. So not viable with a large corpus, because the tags have to be known beforehand so the args file can be created. At that point it is easier to just keep the original data

Doesn't codepoems xl convert use exiftool to copy metadata? I wonder how thorough it is

https://xl-docs.codepoems.eu/metadata#encoder-vs-exiftool-modes

<https://github.com/JacobDev1/xl-converter/blob/16dc9691515fc560aa19a00e67534551cb427738/ui/settings_tab.py#L495> ``` self.exiftool_wipe_te.setText("-all= -tagsFromFile @ -icc_profile:all -ColorSpace:all -Orientation $dst -overwrite_original") self.exiftool_preserve_te.setText("-tagsFromFile $src $dst -overwrite_original") self.exiftool_unsafe_wipe_te.setText("-all= $dst -overwrite_original") self.exiftool_custom_te.setText("")``` That won't include PNG tEXt chunks.

That's too bad... I think you need to explicitly translate them to XMP in exiftool.

Well, if it's important to you, leave an emoji on the issue tracker I would suggest. So it's easier to find the bug report. https://github.com/libjxl/libjxl/issues/2641

This is a very good bug report

Again, I already linked and replied to that exact issue

Yup, you’re the one that showed it to me. I'm relinking it because it's a good point

mostly down to program/website support, go to any famous website where you can submit media and see what is supported

I wonder what the best way to tell digital doodlers about how to use JXL or at least oxipng

Maybe the key is getting artists to save/upload their work in that format. And convincing the websites they use to upload their art to accept jxl uploads.

maybe more niche websites like deviantart and Tumblr have a chance, not Instagram or Twix

instagram can already ingest jxl iirc

unless you were talking about the willingness of their users

for some sites like flickr and photbucket, the trojan horse would be DNG 1.7

you cant realistically fail to upload and display even a proxied recompressed upload from iphones and galaxy phones

the easiest form of adoption would be to *provide* a link to downloadable jxl if it exists (display only a shrunk/recompressed version of that original in whatever the browser supports or preferred final delivery format)

What are you talking about? I'm pretty sure instagram either already supports jxl upload, or will be one of the first major sites to.