JPEG XL

Doesn't it seem like a form of "stalling for time" or something, that they're just sitting on those bugfix patches without merging them, and waiting for a new codec and new glue code to be rewritten from scratch so they can delete all the existing jxl support code just like chromium did?

Whether you agree or disagree with their decision, they outlined their reasoning quite clearly.

I'd also like for it to be adopted/included faster

jxl-oxide is in really good condition and honestly seems like it's more stable and reliable than libjxl is. I know jxl-rs will probably be even better when it's finished. But in the meantime, why stall until jxl-rs is finished? Why not just use oxide in the meantime? oxide is really, really good!

If they really care about rust so much, and that's really the main issue here, like they claim it is, then they could start with fitting in oxide first while they wait for jxl-rs to be complete.

Although their rust argument is really weak. do they have a rust webp decoder too?

It's frustrating because libjxl integration is already there in firefox and waiting to be enabled by them. But they are refusing to merge basic bug fixes in or enable it in non-nightly builds

It just feels like stalling for time somehow...

Meanwhile Apple is using libjxl in literally all of their products right now...

I could see why they wouldn't spend time integrating jxl-oxide only to replace it with jxl-rs a few months later

And the whole world is basically just waiting for these weird browserlords to flip the switch already so everyone can start using it

Yeah, jxl-rs might have a different API, for all I know.

But still, all this waiting around is laaaame...

Technically it would be an easy flip of a switch to get the original implementation 'working' again in nightly, but the whole point of nightly is that you get to test things before you ship them to everyone, and given that that specific implementation will never be shipped because it's going to be replaced with jxl-rs, that wouldn't make sense from their point of view

Especially when libjxl integration is already there and waiting to be flipped on

They'd also have to fix transparency and animation, or people are going to see corrupted images

They like to do staggered rollouts, don't they? So they could enable it at compile time and have it disabled by default in `about:config` like they usually do, and then enable it in stages like they usually do using their shady telemetry and experiments mumbo jumbo that mozilla likes so much these days.

is that regarding rolling out the libjxl impl to stable?

Yeah...

Something they already decided against...

their reasoning, regardless of whether it's valid, is that they don't want multithreaded C++ in there because of safety concerns, so it makes sense why they wouldn't do that among the other reasons

I mean, libwebp is c++ also, and I doubt they have a rust version of that... I think I heard someone say their image decoders are sandboxed in a separate process.

don't know if that's true though, but it would make sense.

They're not able to replace all C++ with Rust all at once, instead they use various sandboxing techniques, they gradually rewrite components in Rust, and crucially they refrain from introducing *more* C++

especially after that ACE vulnerability in libwebp

rewriting software in rust is not a replacement for sandboxing and other sensible security protocols

logic errors can still lead to serious security flaws

That's true

logic errors in safe rust code won't lead to RCE though

I assume they said that because with how I phrased that I made it sound like sandboxing was an alternative to writing code in Rust

And browsers should definitely sandbox things regardless

why? sandboxing slows things down. Maybe if chips had CHERI for cheap sandboxing, it'd be reasonable to do light sandboxing for everything.

Actually, hmm. Now that I think about it sandboxing tabs for example is to prevent them from accessing or overwriting each others memory if something goes wrong, but Rust should make something like that impossible if every tab is its own instance of some datatype

And stuff like a site performing system I/O when it shouldn't be able to without permission, isn't something a sandbox is going to solve either

I'm sure the term is broad enough to include things it would cover that Rust wouldn't, I just can't think of anything atm

Firefox does something interesting for risky components that are too small to be worth a slow sandbox. Iirc they do something like: compile the C++ to Wasm, then compile the Wasm back to machine code during the build process, and that final compile process ensures the code can only interact with a set of special endpoints

font parsing is or was one thing that's done like that iirc

the big reason for doing this is Spectre. Attacker-controlled code (like javascript) can exploit CPU bugs to read data from the same process. but media libraries and such only need sandboxing if they might have bugs that cause them to do bad stuff explicitly, like reading arbitrary pointers or w/e.

I thought W^X bit is supposed to solve that

that isn't very widely used unfortunately

**hydrus** now fully supports jxl images as of v607 https://github.com/hydrusnetwork/hydrus/releases/tag/v607a

There were no recent developments that lead up to me sharing this, I'm just putting it here to potentially plant a seed ;) [[stalled] Add support for JPEG XL: allow JXL uploads in MediaWiki](<https://phabricator.wikimedia.org/T270855>)

(specifically, jxl is *not* supported and this issue has been stagnant for a while)

aw man, that's so cringe

MediaWiki can't support Alpha in WebP thumbnails

They use Debian? Maybe in 12 or 24 years

pledge and unveil really need to become standard... a multiprocess model where each process simply asks the kernel to restrict its privileges and view of the filesystem and revokes its own powers ahead of time is a trivially easy way for programmers to contain and limit damage from malfunctioning software

With no performance overhead

But most importantly, no mental complexity overhead for the programmer.

Vite <https://vite.dev> v6.1.0 supports Jpeg-xl!

The script for macOS Quick Action updated for preserving Birth Time > `on run {input, parameters} > set filePaths to "" > repeat with thisFile in input > set filePaths to filePaths & " " & quoted form of POSIX path of thisFile > end repeat > > tell application "Terminal" > activate > do script "for f in" & filePaths & "; do cjxl \"$f\" \"${f%.*}.jxl\" -d 0 -v && touch -t $(date -r $(stat -f %B \"$f\") +%Y%m%d%H%M.%S) \"${f%.*}.jxl\" && touch -t $(date -r $(stat -f %m \"$f\") +%Y%m%d%H%M.%S) -m \"${f%.*}.jxl\"; done" > end tell > end run` > > (AppleScript)

The "touch" command is the standard, posix way to change timestamps

I originally used `touch` but it didn't work as my expectation

How so?

The modification time is also affected

You only want ctime to be changed?

Why not? If the alternative can realise that why can't I use?

No you can, but what is the reason for not wanting to change mtime?

mtime is more commonly used after all

I want to preserve when the input file was created

This is for macOS as Windows does for it differently

Alright

If you copy one file on Windows, the new file will be appended with a new creation time

Make it get created after it's got edited

Damn I missed "time"

Now both the birth time and modification time will be appended correctly

And it seems the initial part can't be removed or reading multiple files would fail

ctime is file metadata change, mtine is file contents change. birthtime is creation time

Idk if touch allows you to change the birthtime

I read a bit into it and birthtime seems to be filesystem specific and outside of POSIX, apparently

At least I saw the output using identical ones

Yep, birthtime is nonstandard unfortunately. ctime is not the same thing

Nearly all filesystems have it though

Even FAT

https://www.gnu.org/software/coreutils/manual/html_node/File-timestamps.html

> Standard POSIX files have three timestamps: the access timestamp (atime) of the last read, the modification timestamp (mtime) of the last write, and the status change timestamp (ctime) of the last change to the file’s meta-information. Some file systems support a fourth time: the birth timestamp (birthtime) of when the file was created; by definition, birthtime never changes.

Non-standard but recognised

Why isn't it called btime I wonder

**OpenComic** added support through jxl-oxide-wasm. Releasing in 1.5.0 but for now dev posted a testable nightly for windows https://github.com/ollm/OpenComic/issues/165

neat

But no thumbnails for JXL on OneDrive for iOS

they aren't taking orientation into account

Looks like a JXL art

yeah

by jon somewhere in <#824000991891554375>

how many bytes is it? that might make it easier to find

183 bytes

ah, is it this one? https://discord.com/channels/794206087879852103/824000991891554375/1267787251815809034

no, but almost. Jon must've posted a non-HDR version somewhere else, because I have both that one and and an SDR version. Both are 183 bytes.

I found a file in <#824000991891554375> called sunset.jxl, but it looks like it doesn't have that sun reflection, though is otherwise similar.

Well you made me stumble across this 'animated' JXL art https://discord.com/channels/794206087879852103/824000991891554375/846709763324248075 Interestingly, Irfanview locks up for quite a while before displaying it, while waterfox loads instantly. Probably due to Irfanview not doing any progressive loading

And yeah, I looked around but the only sunsets here have no actual sun setting. Maybe it was a non-HDR version Jon posted to Twitter in the past

oh yeah, and he probably had a download link to get the jxl file from his website

https://sneyers.info/sunset/

Samsung Gallery interprets the sunset AVIF in a quite interesting manner

https://tenor.com/view/aurora-borealis-steamed-hams-the-simpsons-simpsons-super-intendent-chalmers-gif-26950836

"artistic liberties"

i spent a good part of today practicing voice acting chalmers and seymour in the steamed hams bit, and for a little bit my brain didn't know how to process seeing it in a different context after watching it like 20 times earlier

Nice spline sig

Some jxl files working on onedrive android

Hmm I may try browsing smaller JXL images

Maybe the decoder is just too weak for huge images

I described the image dimension not the contents

Microsoft momentum confirmed?

Would be cool if they make their own jxl codec...

Jxrlib seems pretty well made

I hope so, but based on their poor WebP and AVIF implementations I am not optimistic. Both of those codecs were released in a beta state then abandoned.

Ironically, Microsoft's AVIF codec can't even correctly load all the test images they submitted to the AVIF conformance repository.

libwebp is extremely complicated last I checked. Even more complicated than libjxl

Even though the codebase is better organized than libjxl the code itself is much more complicated seeming

But third party codecs jxlatte and jxloxide already exist and are very simple and beautiful by comparison

LibWebP does have a complex API. They split the image API into basic and advanced versions, with the latter being required for animations and metadata IIRC.

Could also be more complex looking due to it being more optimised

It's almost incomprehensibly complex. I thought libjxl was complex but libwebp is somehow better organized and cleaner yet even more complex at the same time

But at least libwebp got the error handling correct for a library. AFAIK libavif still calls `abort()` for some error conditions, which is unacceptable for use in many types of software (e.g. an image editor).

Also I thought Microsoft just uses dav1d because that's the obvious asm/C decoder everyone uses

I had to write my own AVIF container handling to avoid that issue with my Paint.NET AVIF plugin. I maintain the AVIF and WebP plugins for Paint.NET.

Wow. I didn't know you made all of those plugins, plus the jxl plugin. It's almost scary how knowledgeable you are of different codec APIs

Plus the C/C# cross-compatibility interface is probably a huge pain in the ass only the most masochistic techpriests can hope to master

A lot of the AVIF code was derived from the few public ISO specs and libavif, because using expensive ISO specifications as references for your file format is a great way to ensure your new FOSS codec is widely adopted. 🙄

That part usually isn't that difficult, you just need to wrap whatever API you are using in a C-style interface.

Hmm... jxl is pretty expensive and ISO-ized...

But at least it's got multiple separate and complete codec implementations

In multiple languages

Another advantage of writing my own AVIF container support is that I could add features that libavif didn't have. My AVIF 'grid image' encoder ended up [being used as a comparison](<https://github.com/AOMediaCodec/libavif/issues/331>) to find optimization issues with the libavif version after it added that feature. I think my next project with the Paint.NET AVIF plugin is improving the color management and HDR handling. My Photoshop AVIF plugin has basic HDR support, I plan to reuse some of the code. But it also has the problem of users leaving one or two star reviews on Adobe's site due to the plugin being 'too basic' or because they failed to read the description stating that Mac isn't supported.

I find it funny that Adobe is a member of the AOM group, and yet they don't have native AVIF support in Photoshop after 4+ years of user requests.

You mean like automatic fixed size tiles?

This is what he's talking about

That's what I thought...

Personally I'm glad that Adobe seemed to immediately rush to adopt jxl while completely ignoring avif like it doesn't even want to bother with such a half baked and low effort attempt at webp 2.0

The on2 team back at it again. Especially after they were put in charge of Chrome and tried to say there's "not enough interest" in jxl and it should be removed from the browser on that ridiculous basis, I decided avif deserves all the shade and failure it gets from then on.

On that basis alone avif deserves to be utterly spurned

I had no idea that jxl and avif were competitors in some kind of "format war" until that happened

I always thought they would coexist in their own appropriate niches, with avif replacing animated gif and webp

Lossy video

But apparently on2 doesn't want that. They only want 1 format. So I say, okay, let's give them 1 format! ;)

May the best one win

As AVIF is very good for lossy animations as it is just AV1

Hmm not showing on the iOS/iPadOS app

https://ddisoftware.com/tech/qimage-ultimate-wish-list/support-of-jpeg-xl-file-format-is-that-a-realistic-wish/ > Right now the format is too obscure to be of any use in Qimage. There is too little support for the format and in the few samples I was able to find, there is no sign of an ICC profile in the image. Without an embedded profile, the image is useless. Could someone explain that the libjxl decoder can always give you an ICC profile and that the reason that he cannot find it is that jxl has compressed color space signaling?

This is from their second comment > Color profiles are supported - this was one of my first tests before I converted my biggest TIFF space hogs to JXL.

https://github.com/web-platform-tests/interop/issues/700#issuecomment-2657324694 > Thank you for proposing JPEG XL image format for inclusion in Interop 2025. > > We wanted to let you know that this proposal was not selected to be part of Interop this year. > > On behalf of the entire Interop team, thank you for submitting this proposal for consideration. We got many more proposals than we could include in this year's project, necessitating some difficult choices. Please note this should not be taken as a comment on the technology as a whole, or our willingness to consider it for Interop in the future. We appreciate the work you put into your proposal, and would welcome your participation in future rounds of Interop. > > For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2025. > > Posted on behalf of the Interop team.

process was designed to be gamed behind the scenes from the beginning. secrecy breeds scheming to sink proposals and avoid real discussions on merits and opinions, it doesnt result in honest wholesome voting

for tech talks on adoptions, voting should always be informed and for the highest impact proposals actually have argumentations mandatory and public so that any failures to understand their impact can be understood, corrected or adressed

interop is about interop, and with only one major browser supporting jxl, it still makes perfect sense that jxl isn't in interop.

chromium and firefox still have perfectly working patches that could be deployed anytime. not currently part of a browser's stable/other official releases doesnt mean the support doesnt already exist

How is that relevant?

You think Interop is a magic charm that would force Chrome and Firefox to merge those JXL patches tomorrow?

Since Firefox will add support using jxl-rs later this year, JXL would make sense in Interop 2026, since at that point there'd actually be potential differences between two major browsers that need to be worked out and harmonized.

I find it sad. Such expensive software and they did not allocate few days of developer time to implement the feature.

Maybe they intentionally decided not to support avif since jxl is better suited for their needs and they already have great support for jxl?

It looks like they intentionally decided to spend all their time fully integrating jxl support and utterly ignore avif as if it's a total waste of everyone's time :)

Inconsistent codec support is an interop issue that ought to be discussed openly though rather than behind closed doors. Lots of major commercial interests are waiting to flip the jxl switch and the only thing holding them back is non-Apple platforms dragging their feet. Plus maybe devs can discuss prospective APIs for partial image retrieval

Except they didn't. You need to use CameraRAW to import or export JXL files

I thought they have builtin jxl export?

Not complete support

To load it straight onto photoshop you still need a plugin

Not sure if this was old or only just became available, but along with the other recommendation by TWAIN, it seems near-guaranteed that JPEG XL will be added to PDF https://pdfa.org/wp-content/uploads/2021/06/pdf-heic-1.pdf

ngl seeing "Philippines" in one of the slides surprised me 😅

The JXL in that slide looks like lossy modular rather than vardct to me

Also legacy jpeg seems to handle the barcodes better

Just found this, may be worth casting our votes https://www.surveymonkey.com/r/QW595Y8?

where is jpeg xl?

lol

I would like to know the forward compatibility of JPEG XL

the renpy issue for jxl seems to be picking up again quite a bit https://github.com/renpy/renpy/issues/3865#issuecomment-2661911280

Avif speed 0 and jxl effort 10? Seems a bit excessive. For lossy jxl, I am not even convinced that e9 actually produces better results than e7.

Avif speed 1 often produces better results than speed 0 while being way faster.

https://apps.kde.org/glaxnimate/ Windows nightly build of Glaxnimate (open-source vector animation and motion design desktop application) can open JXL pictures. The installer is available at https://cdn.kde.org/ci-builds/graphics/glaxnimate/master/windows/

Interop is about intent to do something, not about what's already done.

jxl is being discussed behind closed doors. The reasons everyone is forced to wait for contrived delays, are shielded from scrutiny and discussion. The webp/avif team captain is leveraging his position to force through his own formats and prevent better designed alternatives from competing with them. I think the arguments pro and contra really should be aired out in public

More importantly I think people should start thinking about the best way to support a partial download request API for thumbnails and progressive loading

A new and more efficient spec to replace thumbnail URLs

A way for the client to know how much partial data to request

People who think jxl fails to meet the same bar as webp and avif (lol) should air their concerns and maybe they can even be addressed with a revision like what happened with webp

But keeping all this behind closed doors is really bad

It's an interop issue with lots of very big commercial interests involved and it's already being used successfully on the Apple platform

The strategy of JXL for ProRAW creates a good reputation among Apple premium users

Even though it's not the standalone JXL

Hopefully they fix the flaws with proraw or replace it with true jxl

Since there are flaws with proraw that true jxl doesn't have

It already exists for video use, should work fine for images but I don't have a way to test it https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206

maybe something like `X-Image-Size` with options `lqip, thumbnail, preview, maxres` ?

only thing is how to signify what you already have?

like maybe first request would be ``` X-Image-Size: thumbnail ``` response with `206 Partial Content` then something like ``` X-Image-Size: maxres; have=thumbnail ``` will send the rest of the image?

or maybe it could be integrated with the preexisting `Range` header

Ahh, `Range` supports defining different units https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range#unit

so, maybe `Range: image=0-thumbnail` to get just the thumbnail `Range: image=thumbnail-` to get the rest ?

nevermind, the spec says `<range-start>` and `<range-end>` have to be integers

That's only a small piece of the puzzle. Clients need to know how to make smart informed choices on how much to request at first

The client part is probably easier, as browsers are updating constantly, opposed to http servers, and once eg. a custom attribute on img tag is agreed on and implemented then the support for it will be avaiable globally - especially if it will have application to currently supported image formats (and it can be applied to progressive jpegs and interlaced PNGs) Meanwhile in http servers world where even getting image/jxl MIME-type served for .jxl extension by default may not happen, thumbnail-range is unlikely to be implemented in general-purpose servers, and even when it is the time which would take to upgrade to major release which would support it will be long. Such server feature probably would be only available in specialized CDNs.

Maybe just some attribute on img tag, that would point the browser to the full-size image, and contain the byte range for getting thumbnail from full-size would be better

If a browser recognizes it, it'll download part of full size img, otherwise it'd just download the regular thumbnail from img src

Sleep is for the weak, I watch PDF instead

What's the theoretical evidence here? I mean what can be the reason?

Perceptual optimizations being "optimized" away by less well tuned components. The higher levels of pruning at speed 1 can prevent such excessive optimization in the wrong direction.

Isn't this a sign of faulty implementation in the first place?

No, don't forget that aom devs target psnr first, ssim second, and sometimes vmaf.

Oh, okay. That's the reason.

Yeah, cpu-used 0 will always be more efficient than cpu-used 1 when only looking at psnr scores.

Suddenly forgot that it's a video based image format after all

What about svt-av1-psy though? I am wondering if that has a similar output for this example

As a rule of thumb, optimizing "too much" for any metric has this tendency of not improving quality but only improving metric scores, kind of revealing flaws in the metric.

it's like ML model overfitting

And it should always be checked visually in the end *cough cough* <#1278292301038227489>

there are some rare cases where cpu-used 6 beats slower settings 💀

Both perceptually and on metrics?

just perceptually

cpu-used 6 limits transforms to a max of 32x32px, which most of the time it's not the right call for max metric scores, but for images with a ton of noise or film grain, the result can end up looking too blurry (kind of like what happens with <@207980494892040194>'s examples)

for svt-av1-psy, I've seen cases where preset -1 beats -2 perceptually

in a way that you can tell it'll help psnr scores, but most likely not anything else

also, using ssim with effort 10 is just outright crippling jxl's perception, as 🧈 iterations lowers ssim scores most of the time in my experience

while libaom is using tune ssim, so duh of course it'll perform better on ssim

Seems like the next version of [Paint.NET](https://getpaint.net/) is going to have JXL support by default!

holy crap this website looks like it is from 2003

Yeah. Paint.NET has only one main developer, and I don't think updating the website has been high priority. But the app itself has received numerous updates.

soul

I cannot really see the website between all those ads

It's called nostalgia

it always surprises me when i hear things like this. i can't imagine not using an adblocker

that's not entirely true, sometimes i disable it just for fun, to see what i'm missing, and to me the web becomes literally unusable

*oh it's bad*

i can't believe google is still doing those borderline scam ads that trick you into thinking the buttons on the ads are a part of the website

you know it's funny the reason I started using a blocker years ago in the first place wasn't because I found ADs annoying, no it was because ADs would literally make both my computer and internet cry so I had to use one to make browsing the web not unbearably slow

even now my internet still sucks so I still use a blocker because without it websites take noticeably longer to load still

Still better than the No Man's Sky website... I should really message them about fixing it

their website loads everything all at once right? (i forgot)

With unoptimised 8K PNGs and full HD videos all autoplaying at once

My GPU decode hits 100%, then falls back to CPU at 50% with my network maxed out and RAM usage increasing by around 2GB 💀

I generally just avoid pages with ads, especially excessive ads. Seeing them is a useful indicator to me of the expected reliability of the information.

I’ll check but I think it might go against their policies, in which case you might be able to report it

https://support.google.com/adspolicy/answer/6020955 > The following is not allowed: > > Ads that make it difficult for the user to understand they are interacting with an ad > > Examples (non-exhaustive): Ads that resemble system or site warnings/error messages; ads that simulate messages, dialog boxes, menus, or request notifications; hosted ads that are indistinguishable from other content; ads depicting features that do not work, such as close buttons, text input boxes, multiple choice options; download/install buttons or icons in image ads; ads with a transparent background; images that are segmented; an image that contains multiple copies of itself within the ad; images that appear to be more than one ad; moving and clicking arrows; ads that use surreptitious techniques to disguise their nature; standalone buttons in image ads that lack clear context explaining their function, or whose prominence relative to the surrounding ad content is disproportionate.

it's been a common occurrence every time i tried disabling my adblocker. they're especially common on download pages. i kind of doubt reporting them makes a difference, especially since the whole 'google ads division' has been fairly shady as reported by media, but honestly it's been a long time since i read about it

of course if i saw them again i would still report them

yeah i got the same ads again, let me do that

also this one which says "continue" in dutch

I get normal ads on cnn.com to test, i guess they were just hijacking a software download page with fake button ads

I get similar ones on that page, ironically for anti-ad/malware software

they became the very thing they swore to destroy

adblocker ads are always funny

I used Bullguard antivirus for many years, mostly out of naivety, then eventually stopped paying them when I realised I'm smart enough not to click the big flashing button saying "Free Robux"

"too much belly fat in your 50's? put this in your shoes" glad to see ads are still as deranged as I remember

I wonder if the old Kaspersky alert sound has ever caused someone to die of a heart attack

i don't know what i did in these 10 minutes that made google think i'm a lonely 50 year old man with belly fat, a bad heart and broken legs looking for a partner

afaik the ads are based off the current network or something as whenever I would go into different people's houses or join people's mobile hotspots I noticed the ads I would get would be vaguely related to whoever lives in the house or uses the same network frequently

I tend to get a lot about recent topics I was discussing on Discord

I don't think ads can be based off your discord messages. maybe you do things related to your interests on other websites which you then both discuss on discord and start seeing ads for

I suppose it's possible your mobile keyboard app uses the things you type for target ads. afaik discord doesn't sell anything to advertisers

yet

Sounds like a 5 minute crafts video

keyboards (supposedly) don't track you, it's just that google doesn't need much to get a pretty good idea of what you're into

you're also more likely to realise "oh this ad i saw relates to this conversation i had" than to say "oh this ad i saw doesn't have anything to do with this conversation i had"

-# off topic sorry

It's generally in voice channels and about completely unrelated topics. Like I started getting ads for hydraulic actuators and concrete vibrators after talking to a friend about their engineering studies

that sounds like confirmation bias like jabster said. in general the phenomenon that ads appear personalized based on information they shouldn't have access to is a combination of cognitive biases and the fact that ads are just really good at being relevant to your situation based on the information they *do* have access to. specifically, the idea that your phone is always listening to you and basing ads off of what you say is a commonly believed variant of this and has been refuted plenty

I have started getting defence force (specifically air force) ads lately

of course there are many intrusive data collection practices that google and other advertising companies do employ, but at least for google, listening to an always-on microphone on android phones isn't one of them

also always-on microphone spying would be easily noticed as it would probably kill your battery (and data cap)

Either the audio is being sent over to the server which would use a ton of data, or its being processed on device which would use lots of energy

yeah, they do do some variant of this for the 'hotword detection' which is always listening and waiting for you to say "hey google" but I believe that's even hardware accelerated, at least on some phones

pixel phones also have (or had?) that shazam-like feature where the mic is always listening for songs around you and it'll use on-device processing to show you which song is playing

Not necessarily, the data wouldn't need to be sent continuously and some codecs, like OPUS, are still quite usable even under 10kbit/s. So if 128Kbit/s are 1MB/minute, then 10Kbit/s are 12 minutes/MB. Not, that I believe in constant aural supervision, but it is technically feasible

but to be very clear, if you don't tune your android settings, android collects an *insane* amount of data on you - I don't want to downplay surveillance capitalism because it's actually *really bad*, i'm just saying that the methods by which people think data is collected aren't always accurate

its probably because: people know their phone is spying -> they talk about something and then get an ad about it (for whatever reason; location; chat app; microphone spying; whatever) -> they try to think how the phone would know

always on mic is cheap technically speaking and would have no effect on your data cap

I can gurantee you if they wanted to track you, ISPs would be all for it and give exemptions

ISPs often give services exemptions for data all the time

Isp in this case being the data broker

It's important to keep in mind that Android devices are already constantly listening to you to detect keywords you talk and that still requires processing power. So it really would be pretty much nothing to detect when someone's talking. Transcode it into an opus with a very light preset. Keep in mind that computers aren't done either and that's what your phone is. You can easily set up a background and code that takes extremely little processes and just sits and waits until you get connection to Wi-Fi again.

Last time isps wanted to give an exemption and give people free data for making facetime calls and stuff, people threw a shitfit and the fcc banned it

Over getting free data

Because it was an exemption that unfairly benefit some services (facetime) and not others

Even though at the end of the day you're getting something for free that's strictly a benefit, people hated that

Because it was theoretically unfair and maybe theoretically a gateway to even more unfair hypothetical scenarios

That might have theoretically happened in a theoretical future

Like being charged per-website, and other hypothetical and increasingly less plausible business models

this is an interesting discussion but maybe move it to <#806898911091753051> ?

Microsoft apparently made the jpegxl wic codec *public* on the windows store. Publisher looks to be real microsoft corporation with the apps, codecs, office and gamepass apps. Powered by libjxl, for xbox, mobile, win, hololense, surface hub, lets win view and save jxl https://apps.microsoft.com/detail/9mzprth5c0tb?hl=en-US&gl=US

From cursory look this appears to be the wic encoder+decoder hinted at before in registry. requires win11 (for now?)

anyone installed to check ? store interface errored for me but i got it using winget (type in terminal *winget install 9MZPRTH5C0TB* )

just got out of bed to test it, sec

right click -> set as background works, not sure what else does... can't seem to open images in photos

okay i renamed a jxl to png and that works

no jxl support in edge

jxl thumbnails display in explorer for singe images and folders showing mini previews of their content, desktop, file open, setting wallpapers/slideshows. huge resolutions take a long time thumbnailing. imgs can be rotated left/right from explorer (jxl apparently not mimed in win as an image format so its not yet associable with or selectable in some apps/file picker like Photos)

I doubt that Microsoft will be backporting that to Win10, as it goes out of support on October 14, 2025. But Paint.NET 5.1.5 (currently in [beta](<https://forums.getpaint.net/topic/133371-paintnet-515-beta-build-9191/>)) can provide JXL thumbnails in Windows Explorer independently of the Microsoft codec, Paint.NET 5.1.5 works on Win10 21H2 or newer.

apps and codecs are supposed to be updatable separately from os and out of cycle. hopefully this reaches win10 as it doesnt seem to require any special win10-specific sauce

Are there any script that accept a directory as input, and recursively encode jpeg files to jxl?

```bash find "$directory" '(' -iname '*.jpg' -o -iname '*.jpeg' ')' -print0 | parallel -0 --dry-run cjxl '{}' '{.}.jxl' ```

is `{.}` shorthand for filename without extension?

yes

in `parallel`

ah, wait, missing parentheses

without them, `print0` would bind to the second `-iname` and the first would effectively do nothing

you can optionally pass `--progress --bar` to `parallel` if you’d like, well, a progress bar

I tested the Microsoft JXL codec before upgrading to Paint.NET 5.1.5 and rebooting, it worked with the few Images I tried. Hopefully the fact that Microsoft used libjxl means that they support CMYK, images with transparency, etc. I have no idea if they support Gray + Alpha, but they could just convert it to RGBA. Windows Imaging Component does not have a Gray + Alpha pixel format.

Microsoft's AVIF codec is/was very limited. It couldn't even load the AVIF images with transparency that they provided to the official AVIF test suite.

```ps1 Get-ChildItem -Recurse | Where-Object Extension -in ".jpeg", ".jpg" | ForEach-Object -Parralel {cjxl $_.FullName [io.path]::ChangeExtension($_.FullName, "jxl"} ```

thats probably the powershell equivalent

havent tested it

wait that wic codec makes paint.net outright support it??

No, Paint.NET uses its own plugin for JXL and also uses the plugin to provide Windows Explorer thumbnails. So you don't need the Microsoft JXL and AVIF codecs for that feature. As I mentioned above, Microsoft's AVIF codec is broken in various ways.

what makes the wic codec unsupported on windows 10

[this](<https://github.com/0xC0000054/pdn-jpegxl>) ?

Note that Paint.NET providing the Windows Explorer thumbnails is not the same as the WIC codecs, it won't work in other apps that use WIC.

Yes. As for why the WIC codec doesn't support Win10, you would have to ask Microsoft that.

Also you need to be using Paint.NET 5.1.5 or later to get the Windows Explorer thumbnail support, it bundles the Jpeg XL plugin as part of the standard install.

where can you get 5.1.5

https://forums.getpaint.net/topic/133371-paintnet-515-beta-build-9191/

It is also available through the built-in updater if you opt-in to beta releases.

thanks

about *win10* support for the jxl wic codec just made public by ms, it seems to be locked behind activedomain/entra id ? not sure what to make of this but this suggests the support actually exists and store limitation is currently arbitrary

what is that

https://store.rg-adguard.net/

AppBundleManifest.xml has ```xml <b4:TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.26100.0" MaxVersionTested="10.0.26100.0"/> ```

```xml <uap4:MediaCodec DisplayName="JpegXLImageExtension" Description="JPEG XL Image Extension" Category="videoDecoder" wincap3:ActivatableClassId="JXLDecoder.CJPEGXLWICDecoder" wincap3:Path="x64\msjpegxl_store.dll" wincap3:ProcessorArchitecture="x64"> ``` videoDecoder???

From [MSDN](<https://learn.microsoft.com/en-us/windows/release-health/windows11-release-information>), 10.0.26100.0 is Windows 11 24H2.

you can find `msjpegxl_store.dll` in `\Microsoft.JpegXLImageExtension_8wekyb3d8bbwe.x64.appx\x64\`

i suppose you can put that dll in System32 and register it with `regsvr32`

So it's a manual install? I hoped for it to be bundled with OS, like 7zip support.

OC?

typo

well its easily installable on windows 11

you might need to go through sone hoops for 10 though

This was a very good way to wake up after apparently falling asleep in the VC

Now if only I could run Windows 11

what os are you running?

Usually Windows 10, but I use ImageToolbox on my Android phone pretty often

yooo that's really cool

when/if this comes I wonder how complete it will be? https://discord.com/channels/794206087879852103/822105409312653333/1290990472289976371

it's still kinda weird'ish that Chromium Edge is setup to use system codecs for stuff imo

with Legacy Edge it made more sense

updated adoption. zen browser had only basic jxl support (inherited from firefox nightly but enabled by default), now includes animation/transparency/color profile/progressive. for upcoming version based on *ff136* - for linux users, the flathub listing simplifies adoption https://github.com/zen-browser/desktop/pull/5634

Made a Reddit post so people are aware outside of this server, quoting your messages about what works and Windows 10 support

Have there been any public announcements about this? It seems strange to just drop it out of nowhere.

https://github.com/deckerst/aves/issues/730

keeping an eye on this 👁️

Apple did the same, and IIRC it's always been the case for Windows codecs. At most I'd expect a footnote in the next Windows update

Apple included it in the iOS 18 keynote in the graphic showing the list of new Safari features. Here, Microsoft just dumped it. There was no event or post or anything where you could see that this was coming, *that I have seen*.

I'll look out for the next update notes, ty.

I mean, there *was* what we thought to be a typo saying they allowed JXL files to be set as the background in Windows 11 months ago. But it was only in the file picker, no actual support

what SHA-256 checksum are you guys getting for `msjpegxl_store.dll` for x86-64

"Lol who cares about the tiny market share of ... Windows!"

This is real, JXL thumbnail

But it appends the black background on the preview panel

This is downvoted on Reddit🤔 Still some people don't know about the Google Chrome team

Does it need to be upcase? Looks the same as the URL

With this plugin some images fail to decode, while they were decoded correctly by jxl-winthumb.

Seems like it might be based on image dimensions

Unfortunately that isn't surprising to me, Microsoft's WIC plugins for AVIF and WEBP also fail to decode many images correctly.

Doing a quick by hand binary search on some particular image, 3673x2066 is the highest in can be to generate a thumbnail, 3674x2067+ fails.

For me the decoder only works for thumbnails on File Explorer

Content/what made it matters, I made a new image that is 3674x2067 and it works....

The plugin makes "Set as desktop background" work however you never want to use that as it converts it to original JPEG, I can see the jpegery.

I believe it does that for any format that is not JEPG or PNG

are you sure it isn't filesize rather than resolution?

maybe.. I did try dropping the effort way down low on the failing image and it still failed, but maybe I should look at that more.

still, I tried lossless and lossy

<@833420862334042152> Hey, did your PDN plugin ever expose distance directly, or did it always only expose quality?

It always only exposed quality.

Would you consider exposing distance since it gives you better control? I'm not sure how to make that not confusing for people though who would want quality. Maybe I am wrong and this as changed, but I read a while ago quality 99 was meant to map visually to JPEG quality 99, with the difference being size. If you want better quality than JPEG you have to use distance directly.

Anyway, if you increase the distance enough the failing image starts working, but I doubt it is file size because distance 0.2, half the size of the working lossless image 1px larger still fails

it starts working at `-d 0.5001`

That's when gaborish is enabled....

I will not be exposing the distance directly, because as you pointed out having both is confusing. The approach my bundled Paint.NET plugins take is to expose simple options that most users would need, and direct people to using other tools like `cwebp` or `cjxl` if they need more control over the compression options.

The [quality mapping](<https://github.com/0xC0000054/pdn-jpegxl/blob/main/src/Interop/QualityToDistanceLookupTable.cs>) I use is based on the libjxl GIMP plugin.

Oh, what I said before likely does not apply then

I found cjxl's --quality left a lot on the table in some use cases.

cjxl does `0.1 + (100 - quality) * 0.09` ~~that would make 99 0.1 then.....~~ maybe it just got better compared to when I last used it with --quality. it was a long time ago.

oh

```c float JxlEncoderDistanceFromQuality(float quality) { return quality >= 100.0 ? 0.0 : quality >= 30 ? 0.1 + (100 - quality) * 0.09 : 53.0 / 3000.0 * quality * quality - 23.0 / 20.0 * quality + 25.0; } ```

would help if I read the whole thing

I use the same calculation for quality values above 29, here is the GIMP code I based mine on: ```cpp float dist; if (quality >= 30) { dist = 0.1 + (100 - quality) * 0.09; } else { dist = 6.4 + pow(2.5, (30 - quality) / 5.0) / 6.25; } if (dist > 15) { distance = 15; } else { distance = dist; } ```

I see

yours is better because 100 does not remove 0.1 by mapping it to lossless

the difference between 0.1 and 0.19 can be big in real images

I noticed that anyway, maybe it is not common?

So your formula has 100 just be 0.1 and 101 is lossless?

The PDN plugin has you select lossless separately

so 100 maps to 0.1 and there is no 101

It converts every accepted format to JPEG

And if you want to increase the quality of windows' background image conversion you'll have to adjust a registry key

since some w11 update you can have hdr jxr wallpapers, those definitely stay as jxr

How did you verify this?

by looking at the files in `%appdata%\Microsoft\Windows\Themes\TranscodedWallpaper`

there are some restrictions (file size? resolution?) where it will just convert it to sdr jpeg

but if it fits within those, then you get an jxr file in there and an actual hdr wallpaper

if you wanna try it, here are some files from ms https://aka.ms/hdr-backgrounds-wip

whats jxr, hdr jxl?

jpeg xr, older format initially designed by microsoft for windows under the name "hd photo", later standardized as a jpeg format

hdr jxr files on windows are 16 bit linear half float scRGB (meaning the primaries are sRGB and `(1,1,1`) is 80 nits white, wider colors use negative values)

JXR has a revival thanks to recent HDR promotion

and perhaps thanks to some confusion with jxl

(I mean, I’m mostly joking, but who knows)

Yeah HDR variant of JXL

https://en.wikipedia.org/wiki/Perception_of_English_/r/_and_/l/_by_Japanese_speakers

^ this might also not help

worth noting, from what I can tell, if you install MSFT's JPEG XL codec then it will take over thumbnails for *.jxl files. This mostly affects images with alpha, their code seems to apply a bi-level threshold instead of providing a proper alpha channel

I don't know if the order of installation (MSFT WIC JPEG XL codec vs. PDN 5.1.5+) affects things

probably not though, because the first thing PDN's thumbnail provider does is to ask `CLSID_PhotoThumbnailProvider` if it can handle it. This ensures PDN doesn't potentially make thumbnail processing worse, or just change it in some way, for things like JPEG, PNG, etc.

The windows jxl plugin only works for setting jxl files as background? File explorer doesn't thumbnail them for me, and the photos app doesn't open .jxl

some components may need an update rolled for themselves, like to update their file picker, associations or descriptions of format as image-related. probably gonna see those rolling to insider branches of windows/apps first if not already

was the same ever fully rolled out for WebP and AVIF?

from description and the purpose of wic, we know its meant to cover decoding and encoding so thats at least the photos and paint apps. iinm wic allows to use those formats in ms office documents too, and should cover other browsing/import operations like when you connect a device with images

Microsoft stopped properly following WIC in Windows 10

it's just a mess now and I'm not even sure if they care

afaik the last proper first party WIC codec was for JPEG XR back in Windows 8/8.1

well its a big potential deployment so id suppose itd be good if the jxl devs were in contact with whoever handles this extension at ms

I don't think it's a problem that can be solved within the space of the extension. it seems to be more fundamental issues with modern Windows and Microsoft itself

WebP only got modern Photos support when the app was updated a year or two ago, before that the codec was installed but only did thumbnails

Yes

Once they update the file associations database it should probably automatically prompt you to install the plugin in the future

Whenever you click on an image file when you don't have the codec

If you rename .jxl to .jpg it will open correctly

I think their new metro Photos app ignores system codecs entirely, it uses own.

Tested it and Photos did open ".jpg" JXL

"jpg XL"

https://esenthel.com/?id=feature_list#:~:text=JPG-,jpg%20xl,-WEBP

It's such good news really.

I expect the rough edges will be smoothed out in an upcoming os update so the os can recognize file extensions.

I wish ".jjxl" and ".jxll" might catch on as file extensions too.

Makes it easier to mark and identify the names of files which use lossless compression

Which is desirable sometimes, despite what some here might be tempted to argue. Lossless files can be reversibly transformed back and forth to different formats as many times as you like, and that's useful to know

Not that useful. APNG can be .apng too but nobody actually uses it

There is no .agif so why do we need .apng

But naming files .png and .jpg is convenient!

It's annoying when you download a .png but inspect the data and find out it's jpeg data, and vice versa

Viewers really should always fail to display image when it's the wrong extension. I think IrfanView already shows a warning message and suggestion to rename.

It's nice to know that one file is "stuck" that way and a different file can be infinitely and reversibly transformed as many times as you want and still go back again.

What? But it's just a file name. I don't think apps should care, actually. I think it's stupid that windows cares. We aren't in DOS era anymore.

Filenames are just for convenience.

The file extension is really just there to tell Windows which application it should use to open it.

how's premiere pro, ae and photohop at supporting jxl?

They should be able to open extensionless files, yes. But wrong extension is wrong, too much abuse

I dunno. I like to give my files any name I want, and I like it when programs aren't opinionated on how I name my files unless there is a very good and specific reason.

For example I like naming jxl files with the .jjxl suffix or .jxll suffix

For lossless jpeg or regular lossless

Or maybe .jpxl or .jpegxl just for fun, longer, alternate suffix

Maybe .j1xl for "JPEG1 -> XL" transcode or .jjxl for "jpeg -> jxl"

Really I think people should use whatever creative name suffix they want. It's just a shame Windows is so primitive that it needs to keep track of a suffix database.

If you wanna name it .jxls or .ajxl for an animation, or .jpegxl-lossless even, hey, whatever you like, whatever works best for your file system...

People name JPEG1 files by many names. .jpg .jpeg .jfif and sometimes even stupid and goofy things like .jpg-large

`jxlinfo` can display whether JXL is (possibly) lossless or lossy. Other softwares can implement this

I think the "(possibly) lossless" should not show if a JPEG bitstream for possible reconstruction is detected because that means it is lossy from source

I used to think so too, but technically it's a form of lossless, reversible compression where you can get the original (jpeg file) back, haha

It's a strange and unique case. But to make it fast and easy to visually identify them I like naming them .jjxl

So I know I can easily turn the file back into its old jpeg1 form

It's convenient to help me remember the file's compression is reversible

To distinguish them from lossy .jxl files that I can never get back at the same size again if I try to replace them

I might change my mind if libjxl gets a "no decode recompress" mode for all jpeg/jxl input

Where you can reduce quality/precision of jpeg/jxl input WITHOUT fully decoding to pixels, and guarantee the file size will NEVER increase when using lossy compression on lossy input

generally it's not possible to determine if the original encode was done losslessly

mostly because lossy modular exists

there's no real way to determine if the squeeze had quantized residuals

I proposed adding an Annex N extension that included coding parameters

but there were other priorities

there will never be a way to prevent people from doing the equivalent of saving a jpeg as a png: storing coding params as metadata will not give you a guarantee about the full workflow/lifecycle being lossless

and if all you have is a camera JPEG then recompressing that is the most lossless thing you can do, it's certainly "more lossless" than converting it to an 8-bit PNG...

That's not often what people want

people often want to know if they can decompress a file and work with it, or if it's best to leave it as is

for files encoded lossily you generally want to leave them as-is if possible

but if it was encoded losslessly then you can at least convert to other lossless formats (and back) without worry

Exactly. But if you want to include your encoder version and params that can probably be added to a comment box or maker tag or something.

ohgod makernote

Maybe a cjxl flag to optionally write one

But most of the time that's not desired

Unless someone wants to add extra metadata on purpose

IMO, it is most consistent for jxlinfo to inform about the JXL encoding process only. whatever happened in the history of the information before that point is impractical to judge in general.

It just says how the file was encoded last time

Better than nothing

I haven't sent new releases in a while. (Hope this is correct channel because r3dfox supports JXL) https://github.com/Eclipse-Community/r3dfox/releases/tag/v135.0.1

Yeah ||JXL|| ".jpg" with the Alpha channel on Photos

Safer SFW one

Is alpha channel working?

Yes as the background in this window actually reflects the contents beneath

I can't believe I'm saying this, but I am proud of Microsoft (and Apple)

A black background would appear initially and it would be gone in several seconds

It's presumed to be its thumbnail in the beginning

the way the Photo's app work, it loads the stretched out thumbnail first while it's decoding the image

And the JXL thumbnails on Windows are now always with a black background if there's an Alpha channel

Is that normal for other alpha formats on windows too?

No, it is not. Windows displays proper transparency for PNG, etc. rickbrew noted in a [reply](<https://discord.com/channels/794206087879852103/803574970180829194/1346166265114263706>) above that the Microsoft JXL decoder appears to be applying a bi-level threshold instead of providing a proper alpha channel.

I don't have the Microsoft JXL codec installed, so I didn't test its behavior. But Paint.NET 5.1.5 renders the JXL thumbnails in Windows Explorer with the correct transparency.

I didn't know pdn has a thumbnailer provider. That's neat

Yeah. In addition to its native format (PDN), it handles AVIF, DDS, JXL, TGA, and WEBP. Of those 6 formats, all but PDN and TGA also have WIC codecs that are broken in various ways.

The poor DDS support is particularly ironic, given that it is a format they created. For some reason, WIC's DDS codec can only handle the DirectX 9-era DXT formats (DXT1 - BC1, DXT3 - BC2, DXT5 - BC3).

So the pdn thumbnailer does not have the issues the microsoft thumbnailer has?

For those 4 codecs I mean

Interesting, I didn't even know windows had a targa codec

Windows does not have a TGA codec. And yes, the Paint.NET thumbnailer doesn't have the same issues as Microsoft's thumbnailer.

Oh

there's one that exists here (and also a fast VTF codec that's nice as well): https://www.fastpictureviewer.com/codecs/ although their optimized JPEG decoder fails at decoding a bunch of JPEGs so that sucks and also this is paid.

I do search engine optimization as a profession and only deal with images in that regard, but I am unbelievably upset about Google killing/not supporting JPEG-XL. Besides the interop and devs posting on forums, has there ever been an actual social movement for this kind of change?

I'm thinking that maybe the Chrome team hasn't had the right....motivators pushing them towards making this change. Performance, image optimization, and quality is probably the biggest issue most websites face these days. I'm thinking that if the image devs and the SEOs power up, we might be able to put some real pressure. So I've been brainstorming

Having the SEO aspect provides the argument that this is more than having nice, easy images to work with - this can directly affect a businesses bottom line in terms of losing leads to slow website, technical debt of constantly having to compress images, save multiple copies for fallback, and the reliance on CDNs to meet bare minimum performance. This isn't my expertise, so I'd love to hear your thoughts on if maybe we've been pushing at it from the wrong angle.