Every time a new image format comes out, I think about the compatibility crisis between apps.
E.g. Telegram still doesn't have sane support for .webp, it treats them as stickers. MacOS can take a long time to update with support for new formats. Image viewer apps even longer, many never updating to support new formats.
JPEG-XL is not particularly patent-laden and its license is correct for the use-case.
Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it.
It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc.
And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)
iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max).
That doesn’t seem related to the codec itself but rather how you fetch said image.
Worst case scenario you should be able to add some smarts to the server and a query string such that the client can request 5% of the file or whatever simply by fiddling with the url.
Yes, but figuring out the "5% of the file or whatever" is the hard part!
Let's say JXL does progressive decoding by encoding the image as a checkerboard (it doesn't but for the sake of argument): First you send the average of each 8x8 block, then you send the adjustments needed for the 4x4 blocks within that, then you send the adjustments needed for 2x2, and then 1x1.
If the client knows that it is going to display the image at a low resolution, anything beyond 8x8 might be completely useless, so it would be valuable to know where the 8x8 section starts and the 4x4 section begins. Under-guess and you don't have all the data needed to display it, over-guess and you're fetching data you are going to throw away.
This makes it very useful if it is trivial to analyze the image to determine that, say, the first 5kB are needed for 500x500px display, the first 150kB are needed for 1000x1000px display, and the full 500kB for 2000x2000px and above - either to dynamically generate a <picture> srcset server-side, or to have the browser determine when to abort the fetch after parsing its header.
I’ll be honest, I don’t know the ins and outs of the protocol, maybe the breakpoints are annotated in a way that would be trivial for the server to generate a proper srcset, but that is still a worst case implementation IMO: since the browser would likely redownload the initial bytes during viewport changes and when expanding a image from a thumbnail because all it can see is a different URL so “it is a different file”.
I believe it would be useful to have some browser API so that in the end users could even dial how much resolution they want from images (just because one has a retina display doesn’t mean one wants to pay the bandwidth price).
Knowing where to truncate before you get there is related to the codec itself. Can I figure out where the quarter resolution data ends from the header alone?
> Apple refused to support it because they wanted to patent-laden alternative to thrive.
Where do people get this stuff?
Apple finally supported WebP in 2020, 10 years after it was released by Google. Firefox added WebP support in 2019, a year before Safari. Was Mozilla also part of conspiracy to undermine WebP? Come on now.
Seems to me neither Apple or Mozilla wanted to be forced to support a format they had no say in developing. Usually there's a process for coming to consensus on standards.
WebP is ubiquitous now, not the case in 2010 when it was released.
It had advantages compared to JPEG, but not enough at the time to justify changing workflows, etc. WebP initially had better compression than JPEG, but as encoders/decoders improved (MozJPEG, Jpegli, turbo-libjpeg, Guetzli) the lead WebP had mostly went away regarding compression and visual fidelity.
Going forward, WebP is becoming less relevant by the day; it doesn't support wide gamut color; it only supports RGB. It's max pixel count is quite limited compared to AVIF and JPEG XL. Newer formats have use cases beyond the web; WebP doesn't.
That's wrong, you declare this with an ICC profile, done.
Lossy WebP has an important limitation in being YUV 4:2:0. And it's strictly 8-bit. That is the actual reason it doesn't replace JPEG, which is rarely even implemented to a greater extent.
Lossless WebP replaces GIF. Despite much better compression, it doesn't replace PNG, which supports 16 bits, and has stronger metadata support.
For serious, general purpose programs when thumbnails are shown people expect them to correspond to the full images, and not something else. Windows explorer, android gallery, gnome file picker etc can't show made-up thumbnails, or people would send or delete the wrong images, or would have no idea what images do they actually have.
png/webp (just as jxl) can store thumbnail in their meta, but no operating system, gallery, browser etc uses that because it has no usage that is safe.
I am not sure how easy it is to create a jxl image that starts differently from how it ends. If it is super easy then I expect programs not relying on it for thumbnailing (especially that they already have a way to generate and store thumbnails). Maybe browsers will support progressive loading, but it has no use for local images.
I believe the image would need to be present in the full size image, so I think that would limit to some extent the attack vector, but I don't know how far you could push it.
True, but in my opinion JPEG XL has the right balance of features to become a true replacement of almost every relevant image format we use today, on the web and elsewhere.
Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats.
Depends on who you listen to, or what you test it on. It goes either way, and avif is typically significantly better at small files sizes where loading speed (or saving data) is the priority.
In my experience, it's competitive on output size but not on compression speed. If you're not compressing online then that's fine, but we're running a service that resizes and recompresses on the fly. We serve JXL if the client indicates support for it, JPEG using JXL's jpegli, WebP, or PNG, depending on various factors.
> MacOS can take a long time to update with support for new formats.
Apple added JPEG XL support for macOS, iOS, iPadOS, and watchOS in September 2023 [1]; iPhone 17 Pro/Pro Max added support for JPEG XL Lossy and Lossless compression for ProRAW pictures last year [2].
When Apple adopts jxl-rs, Safari, Chrome and Firefox will use the same JPEG XL decoder.
I didn't intend to give the impression that Apple was definitely going to use jxl-rs. You're correct; there's been total radio silence from the Safari/WebKit team regarding anything related to Rust.
But it makes so much sense for Apple, Mozilla, and Google to support jxl-rs. Of course, that doesn't mean it's going to happen.
Keeping quiet and then adding jxl-rs to a dot release like Safari 27.4 or something is also a very Apple thing to do.
It's too bad that the concept of having a system-wide plugin architecture for importing/exporting formats never caught on outside a few niche platforms. AmigaOS had DataTypes back in the '80s, and BeOS had Translators back in the '90s.
The Linux/FOSS world kind of approximates this just because applications are often built against the same underlying libraries and utilities, e.g ImageMagick or FFMpeg, rather than implementing their own import/export filters, but it'd be nice to be able to install a single system-wide datatype library for a specific format, and have all of my existing software instantly be able to read and write it.
WIC is reasonably widely used since it's used by WPF to load images. The problem is that a plugin codec structure exposes you to bad codecs. We had a tool at work break because someone installed a fast image viewer that overrode the default WIC JPEG decoder with a faster one that crashed loading our tool's splash screen image.
Codecs have been a thing on both major OSes, Windows Media Player could open DivX and QuickTime could open MKV. I think they were only limited to videos however.
That's true, Windows has had an OS-managed codec system since 3.x. Only applies to video and audio formats, though, not a general system for any data type.
I think QuickTime 7 had that capability (I remember installing a codec to make it play wmv video) but Apple removed the plugin architecture in QuickTime X.
> Telegram still doesn't have sane support for .webp, it treats them as stickers.
TBH, this one is just a terrible technical decision that Telegram made ages ago ("we use WEBP to represent stickers, therefore all WEBPs are stickers"). It's not the only weird file-format decision they made; see also "all short MP4 videos with no audio are actually GIFs". :)
What kind of image viewer are you even talking about? I've never had this problem when updating Irfanview, they're usually first in line to introduce some plugin.
I have used DuckDuckGo for many years, and sadly over 75% of the time I find myself adding !g to the search to get the much better Google result. I'm not sure why I still bother with DuckDuckGo.
How do you afford to do this if you want something resembling the best that's out there right now? The hardware needed to run beefy open source models is like $15,000 to $50,000+ for a robust local multi-GPU rig, and even its performance might lag behind.
I don't do that. I use my 2020 top end gaming PC with its 3090. I just ordered 128GB RAM for it. I'll use a single-chat/slot runtime like Strata or Freetoken. And then I'll be able to run either a blazing fast 8-bit Qwen 3.8 27b or a 4 or 5 bit Qwen 3.8 Flash Next. That's good enough for me for development.
And then I'll have my current gaming rig with less RAM but better CPU and GPU run a reasonable smart tool agent for handling Home Assistant Voice Assist. Downside there: when I'm gaming, no voice assist. That may piss the wife off. We'll see.
At least, this way, I don't have to worry about god damn usage limits. I can knock myself out.
All this outsourcing of human interaction to agents is going to get locked down. Customer service relies on people not overabusing it, and that trust is getting abused by agents. Great point here: https://x.com/TheMindScourge/status/2102735345582256504?s=20
Unspoken in that series of tweets, at least until well down the page, is the fact that it was the corporations that started it. When I need support, I can't reach a human at most companies I work with now. If I manage to do so, it's only after extensive effort and negotiation with support bots.
So why in the world wouldn't I respond to this by automating away the hassle?
The solution for both sides is for the companies to implement support bots that have more power to address my problem than the humans they replaced were ever given. I have a feeling it's not going to work out that way, though. Maybe with a few unusually-enlightened organizations, but I'm not holding my breath.
This has been a solved problem for at least two decades. Use ASN.1 and choose your encoding rules accordingly: JER when you need JSON, XER when you need XML, and switch to BER/DER when you need to reduce transfer costs.
I used to work in politics, where sadly, the goal is to change people's opinions. At this level I did succeed in changing many opinions.
The most effective way to change an individual's opinion is to calmly provide facts to them without commentary or judgement. No insults, no judgement, no snark. Just calmly engage with their points and empathise with them. Most opinions are formed without knowing all the facts. Presenting facts without attacking their ego is the best path for changing an opinion.
This works best on unfamiliar topics people don't yet have strong feelings about. With opinion formation, the side to set the first emotional frame has the advantage. This is why in a referendum campaign it's so critical your message reaches voters before the other side can define the ballot question.
Other things I learned
- Good marketers in politics understand psychology. Repeat exposure better encodes a message into memory. For political ads this means repeating the same key phrases/words over and over again, to a degree you and I would find weird, to ensure you encode them into the viewer's memory. With enough repeat exposure, people feel like the ideas are their own.
- Never repeat your opponent's framing of a lie. To debunk a lie: use a "truth" sandwich. State your truth first -- first frame gets the advantage. Next describe the lie in less incendiary words, debunk it, then repeat your frame on the issue repeatedly.
- Politicians start every day with coordinated key talking points for media interviews because message repetition = encoding.
- Referendum ads are particularly crazy because they have no candidate reputation to protect. They do not need to be reasonable or respectable. A referendum ad's sole purpose is to persuade with the most emotionally resonant messages it can to encode key messages/frames of thinking. Being controversial just helps to create more exposure and people seeing your message. If everybody in the media is "debating" the merits of your message frame you are winning. People vote on the issue, not on the campaign team. E.g. If an ad says X will lead to extremist neo-nazi soldiers goose-stepping the streets, people will scoff at the hyperbole while it still subconsciously encodes into them that maybe I don't want something that risks instability.
- Politics is tribal and people follow the support signals sent by elites on their favoured side. Powerful elites speaking out in favour or against something/someone greatly changes its support among coalitions.
I "argue" constantly with my coworkers: they are savage in PR reviews identifying mistakes/improvements, and I give it back the same.
It's collegial, not hostile or insulting. Yet it's arguing nonetheless. We are exchanging ideas to create better software. Using steelmans and devil's advocate to evaluate new ideas / approaches.
Ego-less arguing is easier with engineering work because people are not emotionally invested in code the way they are on a political issue.
When you say you "give it back the same," are you saying you also are savage in reviewing their PRs, or that you are savage when replying negatively to their feedback?
If just the former, I strongly disagree that the two of you are arguing.
Mostly the former, but occasionally it goes back and forth for awhile as alignment need ironing out. That's the other thing about engineering arguments: both people are aligned in seeing an end result. People in online arguments don't have mutual alignment for a good outcome so they go nowhere.
Because solar and wind are renewable, cheaper and cleaner than nuclear. They don't require destructive mining for enriched uranium or create the security implications of dealing with fissile material. Solar/wind do not create long term hazardous waste that's complicated to dispose or create the risk of widespread radioactive fallout. They also help to decentralise the energy grid making it less dependent on a single point of failure.
Nuclear power has its advantages, and may be worth it short term because climate change is a threat to humanity, but nuclear is not a renewable resource. Solar/wind with proper recycling could in theory sustain itself into perpetuity. Humanity needs to find sustainable ways for powering itself in the long term.
Decentralization is not a feature but a bug- it needs massive grid investments which drives up prices in a era where you want prices to be low for electrification. France has the best of both - decentralized grid but centralized groups of power. This way grid costs less
Nuclear can be recycled. It's not done because it's cheaper not to.
Most electricity generation is handled by the government already, particularly in Canada. Worldwide approximately 88% of global electricity generation capacity is owned or controlled by national and local governments.
Some Canadian provinces have IPPs -- Independent Private-Power companies but they are often operating under the patronage of government. Many owe their existence to privatisation, lobbying and sweetheart contracts. (E.g. in British Columbia, private run-of-river hydro companies scandalously secured a 60 year guaranteed non-market rate on electricity. https://thetyee.ca/Opinion/2016/09/12/BC-Hydro-Public-Intere... )
88% seems impossibly high. “Or controlled by” must be doing some heavy lifting. Government owned power is 9% of the US, 25% of Australia, 1% of the UK.
If “or controlled by” means privately owned plants that are subject to local regulations, then that is not particularly interesting or relevant to the discussion
E.g. Telegram still doesn't have sane support for .webp, it treats them as stickers. MacOS can take a long time to update with support for new formats. Image viewer apps even longer, many never updating to support new formats.
reply