JPEG XL

yeah it's absurdly low latency but this is designed basically to be used as a cable (or wireless) protocol for live broadcast and stuff like that

you can compare it more to something like HDMI than to an image format

(or video format)

lol websites nowadays are literally software that disables parts of browser code and reimplements it in javascript and they can't measure download speed of images? even when they cut off image loading so that they can lazy-load images in software by tracking the scroll position and issuing XHR requests on the fly lol

(I mean alright yeah a proper webpage which is not software does rely on media queries etc in order to determine which image sizes to load and can't really decide based on download speed, but don't forget apps on mobile too are a big thing)

also even when software fails, user-defined settings are great controls for that... even if speed isn't an issue, a user might simply decide to switch the images to lowest quality to save their data allowance even if they're using 4G for instance.

a nifty modern example is the Youtube mobile app, it does this nowadays when you're watching videos on mobile broadband, it shows you a little pop-up with 3 or 4 sizes in megabytes and asks you to pick one depending on if you want high quality, balanced or low data usage (IIRC there's an "auto" option and "don't ask again" for annoyed users)

https://github.com/WebKit/WebKit/pull/5433 this is an interesting precedent <@532010383041363969> — it will make avif work on Safari even in old MacOSes that don't have OS-level avif support yet. If they allow this for avif, then we should ask: why not for jxl?

(it's not that relevant in practice since this is only true for MacOS Safari, not the iOS one which will still only support avif if the iOS version is recent enough — and most of the Safari market share is of course on iOS)

I believe Apple is still in denial -- we need to win over their hearts, minds and eyes, not their bureaucratic principles or processes

WebKit is also important for a lot of embedded browsers, like on TVs and game consoles.

I’m confused – weren’t we told that: > The most important point you need to know is that Safari doesn't use WebKit's image decoders at all, so if you want JPEG XL to work in Safari, contributing JPEG XL support to WebKit is not likely going to achieve your goal. — https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30116.html

Yep, contributing to Webkit will add support for some lesser-known browsers, but Apple uses it's own OS-specific code for image & video formats on Safari. I believe it's the same with Edge on Windows with respect to some image & video formats. For instance, AVIF & AV1 only work on Windows & Edge if you install their OS plugin.

I think at this point, not adopting JXL is pure politics.

Or just is worried about poor mobile performance.

Edge doesn't actually support AVIF, and there's been nothing public about support being added

According to https://learn.microsoft.com/en-us/answers/questions/809434/avif-format-not-supported-in-microsoft-edge.html it's by design

I don't use Edge much so I didn't test it, but odd that it only works with AV1. Seems like the plugin should easily support AVIF.

AVIF can be anywhere from tens to thousands of times slower than JXL, yet it's supported in most mobile browsers.

That is true for encoding, but not for decoding. Decode speed is not that different.

I didn't do test by myself but from decoding point of view JXL is one of fastest from what I saw. I had done some JXL vs PNG encoding tests of large scans of movie posters and JXL is wiping floor with PNG (except RAM usage). It baffles me why adoption is so low.

Besides browsers, I think JXL adoption is actually going quite fast. Of course it would always be better if it were even faster, but compared to the adoption curves of new formats in the past, I think we're in a good shape.

CLI tools are one thing, but when JXL is a first class citizen in something like Photoshop I think that'll push it into the forefront

Like no matter how amazing cjxl is, Adobe adding it as the recommended output format in Camera Raw will get more attention

In browsers, it's purely politics. JXL support will no doubt be bad for AVIF adoption. The key decision makers in Chrome are strategically prioritizing the interest of AOM over the interest of the web platform. It is a situation of conflicting interests, which can only be resolved when ecosystem adoption will have reached a stage where it will become untenable to keep blocking JXL.

We already have JXL in the most important FOSS image software: Gimp, Krita, Darktable. Adobe is following; they will likely generalize what they did in Lightroom/Camera Raw to their entire suite.

Camera vendors producing JXL directly will take more time; we are discussing hardware implementations within JPEG but these still need to be developed and will then take time to end up in actual products.

I assume most CDNs will add support but only once browsers support it — the market share of early adopters who have the flag manually enabled is too small to be relevant.

https://twitter.com/Leopeva64/status/1586187642273935360?t=XJqSpiFd-C385N8lLRsuNw&s=19

so is this the (previously undisclosed) outcome?

No idea

<@795684063032901642> can we make a pull request to undo that note and to push the expire milestone to 115 or so? Or is this the way they communicate to us that they're throwing jxl out?

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c81

Now it is time for the chrome codec folks to bring real arguments to the table

Because so far, I have seen only bogus arguments from them like "we cannot support jxl because it would confuse web devs if there are two good image formats, they wouldn't know which one to use"

I'm bit late I guess, but no one here mentioned this https://github.com/telegramdesktop/tdesktop/commit/278ab5ebafc32249f21d3d3bef71acd63a792616

They want AV02 AVIF

(AOMedia AV2 codec(

Well, there is an easy solution for this then.

Deprecate AVIF since the format has more weaknesses vs JXL as an image format.

No

We want AVif av2

What? They complained about having a "one-format-that-does-all," that there should be competition. Now they are complaining there are too many formats? This is getting ridiculous.

why do you want avif2?

<@794205442175402004> <@179701849576833024> Interesting discussion happening in the mpv IRC chatroom 🙂

It's time we have some public discussions about this, for too long this has remained an internal discussion in Google that lead to nothing useful

https://twitter.com/jonsneyers/status/1586368106167164929?t=ebOgw706dOK0AUQWWZAnXg&s=19a

AVIF is a good GIF replacement. JPEG XL is a good JPEG/PNG replacement.

AVIF's Intended Uses: • GIF/meme replacement (AV1 for animated GIF) • Video still captures • Low-bpp images served to users in developing countries where internet is slow/spotty • Low-quality JPEG image replacement JXL's Intended Uses: • Medium-to-high quality JPEG replacement • Lossless PNG replacement • High quality lossy images with alpha transparency • Faster image rendering (progressive & responsive rendering)

There is a need of some build-scripts work in order to enable support in Windows build of Telegram: https://github.com/telegramdesktop/tdesktop/issues/5522#issuecomment-1295915969

Well, with their mention of WebP2, it seems like neither are here to stay in Google's eyes

Except WebP2 development sort-of dropped off a cliff. I think most started working on AVIF. I had a worry that at some point they would expect that AVIF would compete more on the high end. My guess is - they intend to, at some point, make it better for higher quality images. However, in the meantime they just expect everyone to use WebP (which sometimes gets worse compression than JPG) instead of allowing a competing format to enter.

good comment

Feedback on why they are removing jxl from chromium: >>> Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons: - Experimental flags and code should not remain indefinitely - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL - The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default - By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84

that's not really feedback, it's an excuse, unfortunately

It definitely feels rushed to me, one of their arguments was that there was no interest in it, then Adobe said they're supporting it and suddenly it's got to be removed

the same thing can be said for AVIF

the current "feedback" is, blatantly put, just saying they happened to pick AVIF over JPEG XL

they don't explain why AVIF is chosen over JPEG XL

for apparently no reason they picked AVIF first and used that argument to not pick JPEG XL

there are enough reasons to choose AVIF over JPEG XL, of course, but they are silent about them

> - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL > - The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default Support from Adobe, Facebook, Instagram, Intel, Flickr, Smugmug, and a growing number of web developers is not enough? HUH? Netflix was about the only one behind AVIF. CDNs didn't even want to implement it because of the performance issues. Not sufficient incremental benefit as compared to WHAT? A rock? These are BS reasons.

tbf AVIF *was* ready first (by at least a year if I recall correctly)

yes that can be a good reason, but did they give that reason as a main motivation so far?

I don't recall anybody explicitly asking to elaborate wrt incremental benefits, but I assume that they'd reply by saying "well AVIF can do this too", which considers AVIF as an "already existing" format hence "it was there first"

but I'm not the person who wrote the comment nor I am in any position to make that decision so...

what a strange response. it doesn't read like they're open to debate it, either

I would honestly agree if the reason given is that AVIF doesn't increase a code footprint too much compared to JPEG XL, that argument was crucial for APNG over MNG for example

the current "feedback" is not really satisfactory even for who prefers AVIF

"The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default" Someone should push them to quantify what "sufficient incremental improvements" means. What do they consider sufficient? Why did they begin to incorporate it if jxl was insufficient?

well, technical merits aside, I don't think it can be denied that there is a massive industry-wide push for AV1 and AVIF, and as you say AVIF adds very little code, bug surface, etc over AV1

for AV1, undebatable. for AVIF, I'm less sure.

who's *they*? it was mostly *us* ( <@768090355546587137> <@795684063032901642> and in part me) that did that

well, for one I believe Safari supports it now... and IIRC similarly there's an official Windows AVIF plugin, but not one for JPEG XL

Windows support isn't great, it's the side effect of having an AV1 decoder and a HEIF reader

> Why did they begin to incorporate it if jxl was insufficient? Because it's definitely about politics. They are pushing to get greater market share for WebP (~10% so far) and AVIF (<1%). They don't care that those formats don't offer enough improvement over previous formats, is slow, etc. They made it and gosh darn it, everybody should use it. Why else would they include 2 outright lies (lacking support & insufficient progress), and 2 BS excuses (I've seen them push flags down the road, sometimes for years, for other features that were being worked on).

there's also some perception (although it is unclear to me how true it is) that HW AV1 decoding will make AVIF support better

that said, all of these are arguments for *including AVIF*, not for *excluding JPEG XL*

For cameras, yes. For other devices it would likely be pointless for AVIF. AV1, yes, since it's a video format.

for completeness, I think JPEG XL is *more* a Google format than AVIF is - IIRC AVIF was mostly a Netflix idea (https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4)

https://twitter.com/jonsneyers/status/1586387410640044038?

I know 😉 but even still, the idea of making AVIF was not originally from Google 😉

that's fair

for what it's worth, i really do not want to believe it is political and would like to give google the benefit of the doubt

having maintained projects internally at a security-related company, i would take literally any excuse to avoid having to add a parser for even a single file format written in C(++) to my codebase so i cannot fault them too much

but i do find these excuses to be inexcusably low-effort given the work put into jpeg xl by everyone in the industry

If they were valid excuses, and enough, I might accept it as Google doing due-diligence. But they gave multiple reasons that they themselves should know were false. Not sure how to interpret that as anything but political.

it was a quick statement put out by an engineer on a sunday. for all i know they weren't even sober when they posted it. i can imagine a million reasons for that response that lean more toward apathy or incompetence than politics, so it's best not to jump to conclusions

i just hope we hear more during the work week

Mozilla seemly have been pretty hesitant to even support JXL in the first place

Firefox already made their decision - they don't want to keep adding more formats. It was infighting within the dev team - basically came down to senior devs not wanting to add new stuff vs new devs wanting to add new stuff. The senior devs won (and many of the newer devs likely got laid off over the past couple years). At this point, Firefox won't do anything until they see Chrome add it and have enough support.

The excuses... maybe. But they already added the deprecation notice at the end of last week. If anything, they'll just slap the drunk dev on the wrist and give a different set of excuses.

It was already set in stone.

bruh moment

jyrki has just recently indicated that they're once again looking into prioritizing libjxl-tiny (<https://twitter.com/jyzg/status/1586870998980337668>) which seems quite promising

cloudflare has weird infrastructure in place to destructively rewrite webpages and add javascript to make those changes...less-destructive. i'd love to see similar applied toward polyfills, but i wouldn't hold my breath

HN thread about the deprecation: https://news.ycombinator.com/item?id=33399940

Yep, getting a number of people posting on the bug... but they will likely just lock the bug at some point soon.

Speaking of Firefox, is there a reason why development of JXL support completely stopped? There's not even a transparency support yet.

If they don't want it, they won't accept patches to fix deficiencies

Wrote about this a few posts up: https://discord.com/channels/794206087879852103/803574970180829194/1036436695102541834 They laid off a lot of people over the past couple year. A lot of stuff got de-prioritized. Unless it's necessary, they pretty much don't work on it now.

Mozilla layoff has big impact, especially on development stuff

I would imagine developers are not a problem, considering it's an opensource project. But lack of reviewers is a problem, if what Hayasaka said is true.

really good post in response to that sad excuse of a reason to drop jpeg-xl https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c88

I don't think many people would react positively to being called incompetent, even if they are.

Yes, please try to be polite.

I agree, but its the internet. Some are very angry over the decision.

being polite will give a better chance of them actually listening to whats being said

same thing goes with many things

I predict there will be polyfills galore.

I left a comment that I hope isn't too out-of-line with Monorail issue-tracking etiquette; or if it is, that they have some empathy. I know such comments are frowned upon on the Android issue tracker. (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c93)) It's just hard to feel closure from the Chromium team's current response. I hope we can at least be told more.

I mean, it is true.

Anyway, I've got an interesting idea for guerilla marketing against AVIF. I don't like doing this, but it is our last resort outside of the G employees working on JXL to do some lobbying.

Essentially, let's hammer on the points at which AV1 all-intra is weakest at and blast them.

I will also release my fabled JPEG-XL and AVIF P3 article sooner than I expected to hammer these points further.

would that work though? I recall WebP was initially heavily criticized for its loop filter which did blur the image too much, but that didn't stop WebP being adopted.

Yes actually. Because there are are multiple parts completely limited by AV1's video background: 1. YUV. 2. Bad all-intra lossless(not even counting the fact that only adding tiles can speed up lossless decode). 3. No native alpha support(add in alpha and decode performance is severely hurt)/ 4. No native progressive decoding support. 5. Requiring libyuv external library support for maximum encoding/decoding speed. 6. No lossless JPEG transcoding. Etc.

without any value judgement, I think for such an article inferior existing features should be preferred over missing features, because missing features would be harder to argue if the opponents question the rationale

say: lossless JPEG transcoding is of course nice, but they can question "so? we lived fine without them for decades" and it doesn't seem worthwhile to argue against this

if we indeed do this, we should focus on things that AVIF promised and thus *should* do well but doesn't

That doesn't actually work, even in bad faith, because both JPEG-XL and AV1 offer better compression than JPEG, so that wouldn't work all that effectively as a counter argument.

I mean, yeah, but it is better to prevent a possibility of such arguments if possible

Depends on how you look at it... didn't stop adoption or slowed it. It's been about a decade and it still has less than 10% usage. It only started increasing over the past couple years.

Something I just realised, Google refusing to support JXL in Chromium also stops it being used in Electron apps

One thing that needs to be addressed is an extremely common misconception that most images on the web are low-bpp

while in reality the opposite is true

That could be true

you can on e.g. reddit and take a sample of images on the front-page, there will be basically zero <1 bpp images

Also thanks for the insight Veluca

Well yes, also it depends on if we're talking about stored originals (which people sometimes view) or cached downscales (of which JXL would help too, but are technically low bpp)

most images are low bpp

because most images served are thumbnails

Just because something is a thumbnail, doesn't mean it's low-bpp. The current top post on /r/all has a thumbnail of size 4795 bytes and the resolution of 140x105. That means it's bpp is equal to ~2.6

Also, no one really should care about the quality of thumbnails

The quality of full size images is more important

BTW, if anything, larger images tend to have lower bpp because there's more redundancy in them and thus they are inherently more compressible

We don't need to point out weaknesses of avif, we should show strengths of jxl and ask for both to be supported. The whole issue here is that the avif proponents who control Chrome think they need to kill jxl if they want avif to succeed. Let's not make that same mistake. Both can coexist. But we do want both.

and before someone says "maybe it's just reddit". I just went on BBC.com and picked a random thumbnail. The result is 1.3 bpp

and it was the worst case because the image has a huge black frame https://ichef.bbc.co.uk/wwhp/304/cpsprodpb/8C49/production/_127431953_hi079886996.jpg

this is just a myth that people are repating without questioning

another thumbnail from the same website: https://ichef.bbc.co.uk/wwhp/304/cpsprodpb/17B8A/production/_127426179_gettyimages-1244341961.jpg

this time the result is a whopping 3.16bpp

BTW, the full size image https://ichef.bbci.co.uk/news/976/cpsprodpb/17B8A/production/_127426179_gettyimages-1244341961.jpg.webp has bpp of 1.93

JPEGs at q>80 are pretty common. I come across q90 as well.

There are art sites that only support JPEG, PNG and GIF for animation, not even WebP. Those would benefit from a better lossless format for storing fullres artworks.

Speaking of AVIF, Microsoft really needs to fix their implementation, it's pretty much unusable in this state. The colors are all incorrect, YCbCr 4:4:4 is limited to 8bpc, RGB doesn't work at all.

sounds like those thumbnails can use

lower bpp

No, I don't think it make sense to make such a pull request. And yes, it seems like it.

Now the question is if they will just ignore and sit out the backlash, or if they will listen to the rather overwhelming community and industry input and reverse their decision.

I think it would be great to have a blogpost refuting Google's arguments and also other common criticisms of JXL

also i think it would be important to highlight how different the process was for AVIF

did you know there was no experimental period? it was enabled on production releases immediately after implementation

and there definitely was no "hype" around AVIF (community interest)

i even have a title for that article: "The game was rigged from the start: how Apple, Google and Mozilla stacked the deck against JPEG XL" 😛

if you were to write it there's a small problem: cloudinary is banned from hacker news and they are the website most likely to be receptive to that kind of article

I think Chrome is behaving quite irrationally. Question is how can they be brought to reason? Technical arguments don't seem to work, because basically however much better jxl is, "avif will bridge the gap soon", and whatever features are missing they will be added, if needed in avif2.

this another thing that should be mentioned in that blogpost, "possibly avif could be improved to match JXL, but jpeg xl is already here!"

the point is to convince the people on the fence, to gather support. it's unlikely you will convince that specific person who is the gatekeeper

I am afraid it might take something like the tech press jumping on this and exposing the nonsensical biased behavior.

yes, and that blogpost would be a great start

also

phoronix and theregister are the most likely to do that

especially the latter, they love this stuff

but it's possible they aren't even aware of this

also, regarding AVIF vs JXL, i think we should especially focus on "jxl can losslessly transcode jpeg images"

this is a killer feature and something avif can't do at all

when discussing quality there's always room for debate, while this thing is completely indisputable

and it's not like it's some obscure use case, it would make great sense to eventually convert all the images on the internet to jxl

OT, but why?

no idea, but as you can see (if you're logged in and have "show dead" enabled), all the submissions from that domain are [dead]: https://news.ycombinator.com/from?site=cloudinary.com

maybe some spam filter or something, it's hard to tell

it would make sense to contact them, in my experience they reply quickly

it seems it happened around june/july 2017, because that's when submissions started to be [dead]

Seconding this. One way to word it is perhaps mentioning that JXL by design does two things that AVIF by design doesn't - high fidelity imaging (including lossless imaging) and lossless transcoding of existing images - not just lossless formats like png, but legacy jpeg itself. It's going to save terabytes of storage and petabytes of bandwidth. Literally addresses https://xkcd.com/927

Why would Google pick this timing? This is a slap in the face, especially after conformance testing was standardized a few weeks ago!

It genuinely seems malicious if not for Hanlon's razor

Personally, I think it was the release of https://helpx.adobe.com/camera-raw/using/hdr-output.html just over a week ago

Screenshot can't be made on Windows 7 in JPEG XL with a good encoder

At that point JXL went from "Something in the future" to "People can produce them right now"

If the goal is to stop deployment of it, you've got to act quickly to stop people before they start to depend on it

(I really don't want to sound like I think it's some kind of conspiracy, but the timing is too close and odd to me)

My interpretation: the AVIF proponents within Chrome got nervous when Adobe started deploying JXL and encouraging their users to enable the flag, and they decided to quickly kill JXL now they still could.

To me it looks too suspicious to be attributed to incompetence alone.

also, i should stress that a blogpost about this should be respectful and, most importantly, it should not come off as whiny and bitter

this is a real risk

the audience doesn't have the same emotional investment as we do

agreed

What if they got upset that Adobe implemented JXL but not AVIF?

Could be a factor too. Though Adobe is adding AVIF support to their products too.

wft

<:AngryCry:805396146322145301> <:Google:806629068803932281>

The good morning messages everyone are waking up to.

I am relieved tbh that the bullshit is finally getting public.

bizarre to see cdns ship jxl in stark contrast to browsers

they can still save a ton of money on storage, even if they have to transcode for browser delivery maybe? still not the way to go... smh

I've got an interesting and destructive idea. How about CDNs start using RNG and showing JXL images randomly to Chrome clients from 110 onwards and if the client doesn't support it, it shows "JXL image not supported by Chrome".

It would be fun but we cannot take our customers hostage like that.

I mean, Shopify actually did this by mistake on some clients. But yes, I absolutely agree. Hence why it would be destructive. Some people on the AV1 server noted a few weeks ago that Shopify was mistakently showing some clients JXL images, even though the client did not support them...

Oops

<:kekw:808717074305122316>

Yeah, I am really annoyed. I don't mind if they decide whatever they decide based on solid reasons and a fair process. If they have clear criteria and we don't meet them (yet), OK, then we can see what needs to be done. But to read about this decision via a press article on a pending merge that was submitted just before the weekend, and then to get some nonsense reasons, that is just infuriating.

It's just not a respectful way to treat all the jxl contributors and early adopters.

better still is to just ship images with polyfills, so the codec guys get driven nuts by the perf guys for the next N months/years

I suppose the idea is that AVIF will be decoded in hardware but what if the hardware doesn't support features used by the image?

Most AVIF images aren’t going to be hardware-decodable for a long time

They’re too big, shaped weirdly, use 4:4:4 color, etc.

It mostly comes down to 4:4:4, throughput and random access.

The rest really isn't an issue up until we get up to 30MP, but then, purely independent tiles start becoming an issue.

Also I imagine alpha will not be particularly practical on hw

I couldn't find a way how to create an AVIF animation with transparency.

Only cameras are likely to use HW, what would they need alpha for?

this is about new desktop/mobile cpus that are getting hardware support for AV1, so AVIF may be able to use those instructions. like what already exists for h264/5

Nothing, I was referring to the idea of decoding avif in hardware in browsers.

I still wonder what improvement that would bring. Maybe for extremely large images or pages filled with images?

perhaps a WASM build of libjxl can be provided to allow people to use it and gain momentum?

won't be as fast but is a way forward for now

Yes, we already have one but it would be useful to give it some love to make it convenient to use

Which repo is the official one?

Squoosh also has a Wasm build of libjxl, although it looks like it's deprecating its CLI and lib variants and will only focus on its website - see: https://github.com/GoogleChromeLabs/squoosh/pull/1266#issuecomment-1208149979

It's on the libjxl repo itself

FWIW, the next release of <https://github.com/kleisauke/wasm-vips> would also support JPEG XL images.

ok ill take a look - its been a while since i played with libjxl

> Like our colleagues at Cloudinary, we would very much like to see the research that prompted this decision. What metrics and use cases were used to reach the conclusion that JPEG XL was not enough of an improvement over WebP and AVIF?

(on the bugtracker, https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c121)

I think this is the key point. Show us what research the decision is based on.

Yeah, it is actually a huge problem in the animation community for stuff like video streaming and creation. Video with alpha? You get no HW accel since HW decoders usually only expect 1 stream playing from the same source, not 2.

I can totally see how this misplaced focus on hw decode (for still images on the web) will lead to us basically getting only 4:2:0 no-alpha barely HDR-capable images on the web

Also, using PSNR in benchmarks as the one and only metric is still popular, for example from a recent one related to image formats, which I also noticed <https://github.com/strukturag/libheif/wiki/HEIC-vs-AVIF-Benchmark>

Yeah, it could very well be the case that they're just looking at bad metrics and reaching conclusions based on that. It wouldn't surprise me. But we need to see their data first before we can understand what went wrong.

Yeah, that could very well happen.

I mean, there is also the worst case scenario: Google video people not even knowing of certain tools from another somewhat Google standard, even though their usage would benefit them a lot: https://github.com/AOMediaCodec/libavif/issues/919#issuecomment-1135163700

I was actually surprised to see that Wantehchang did not have access to the butteraugli_main tool, which would be by default build when dealing with libjxl...

<:PepeGlasses:878298516965982308> <https://github.com/rigaya/NVEnc/blob/master/GPUFeatures/rtx4090.txt> ```NVDec features H.265/HEVC: nv12, yv12, yv12(10bit), yv12(12bit), yuv444, yuv444(10bit), yuv444(12bit) AV1: nv12, yv12, yv12(10bit)``` <https://github.com/rigaya/QSVEnc/blob/master/GPUFeatures/QSVEnc_DG2_Arc_A380_Win.txt> ```Supported Decode features: H.264 HEVC MPEG2 VP8 VP9 AV1 yuv420 8bit 10bit 8bit 10bit 10bit yuv422 10bit yuv444 12bit 12bit 12bit```

Wait, since when does the A380 support 4:4:4 10-bit AV1?

I have a feeling it is wrong.

Yes, although even 4:4:4 12-bit (up to or only?) AV1

does/will it support progressive decoding? edit: i guess i'd also like to ask this question of libjxl, too. can you "trivially" polyfill the progressive decoding of images with wasm libjxl?

You could use an AVIF polyfill as a starting point. https://github.com/Kagami/avif.js This one creates a service worker then checks all fetch requests for an AVIF file, decodes it with the wasm decoder, and spits the pixels back to the `img` tag.

FYI - I previously created my own libjxl-js build here: https://github.com/chafey/libjxl-js

I think that library is JUST the wasm library, not a polyfill. However, using a polyfill, progressive rendering should be possible using a `canvas` tag. Not sure if it could be done with an `img` tag...

Nice, will check it out. <:PepeOK:805388754545934396>

Thank you.

wasm-vips doesn't currently support progressive decoding of images, including JPEG XL images. It's still on my TODO-list, perhaps it might be possible to hook the output of `vips_sink_screen()` to HTML's `<canvas>` element. For JPEG XL images specifically, libvips still needs to add support for the `JXL_DEC_FRAME_PROGRESSION` event and expose the `JXL_ENC_FRAME_SETTING_RESPONSIVE`/`JXL_ENC_FRAME_SETTING_QPROGRESSIVE_AC` encoding options.

Thank you for the clarification! Congrats on all you've done so far.

the hardware decoding argument is really a non-argument

because the round-trip to the video card for a single image is higher overhead than a software decode

you'd have to make a round-trip for each image because they are separate streams with separate dimensions

https://twitter.com/njdoyle/status/1587167753982672897

and of course he didn't say anything about transcoding jpeg images

and he repeats that myth about rarity of high-bpp images

I see. So hardware decoding individual pictures is not practical.

yes, it seems that many people have the view that the web is only low-bpp images and also all the other features are completely unneeded

that's correct, it's slower than software decoding for, say, a webpage

He also seems to take as accepted that it's JPEG XL vs AVIF, rather than JPEG XL plus AVIF

the AVIF folks as a group seem to think that JPEG XL being present is actively hostile toward AVIF

which is somewhat understandable, because there are no reasons to use AVIF if JPEG XL is present

but then of course you have to wonder if they are backing the wrong format

animations

That's AV1

yeah but there will probably always be places where you can put an animated image but you can't put a video, because people are silly

Most of the analysis would be from web devs and that's exactly what he is saying he is rejecting. The problem is that Nick is: - Ignoring that many don't have access to use a CDN that transcodes images - Throwing opinions of web developers out the window - Ignoring that AVIF lacks any progressive rendering - just make the image lower quality (no.) - Not providing actual data - but requesting it from others? Pay me. - Making an article on Twitter - write an article, don't use a service meant for text messages - What about high quality? Lossless?

Do those multimegabyte PNGs count as low bpp?

It seems people on reddit are mostly on JXL's side: https://www.reddit.com/r/programming/comments/yib184/google_chrome_is_already_preparing_to_deprecate/

the submitter did a good job with a biased pro-jxl headline 😛

AVIF is pretty unreliable. It depends of several components that have to be put together in the right way, which some developers are unable to do. In that regard, WebP is better than AVIF because WebP is working reliably. And WebP also provides functional lossless mode.

Would love to see an energy usage comparison of JXL vs AVIF... Is Akamai selling enough carbon credits?

Chrome supports BMP? Or is it only Windows thing? I thought only MSIE did. Why would anybody use BMP? Although I recall I came across a website where pictures were loading bottom up and very slowly, it was hilarious.

for .ico (favicon) for compatibility, later png/jpeg could be used for the favicon

Possibly, however BMP and ICO are not exactly the same thing.

They all support BMP. I forget what the reasoning behind it was. https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types

Even Microsoft doesn't use BMP for desktop backgrounds anymore.

I wanted to use some retro wallpapers from Win 3.11 but Win10 converted everything to JPEG.

Oh, he made a big mistake posting this publicly <:kekw:808717074305122316>

honestly as a web developer i would kill for browsers to support jpeg xl and support intelligent loading of progressive jxls

_the_ #1 most annoying thing about images for me is having to produce 5 billion different versions of every image

My friends, if I were to post a subjective comparison test, where should I do so?

twitter and reddit would be a good start

I see, that's good.

My primal codec instincts have been fired up by what the guy posted on Twitter <:kekw:808717074305122316> He fails at remember that while AV1 encoders have improved, libjxl has improved as well.

Not to mention that the amount of resources being thrown at making AV1 perform better is a different order of magnitude as the effort spent on libjxl. I am quite convinced that the bitstream potential of jxl is larger and that with equal dev effort the gap would only increase.

JPEG XL is the alien technology from the future of the future

There’s so much potential in the spec

The deprecation is again on the front page of HN: https://news.ycombinator.com/item?id=33412340

There are quite a lot of old websites from the 90s and early 2000s that use BMP, especially for little icons.

Interesting. I wouldn't expect that, considering GIF is older than BMP format. BMP was used since Windows 3.0. Programs supporting GIF were available for DOS as well.

GIF had patent/licencing issues back in the day.

Also, some of those icons on websites were just nicked straight from windows or other programs.

Back in the day, many people also didn't care about patents and licenses. The internet was kind of wild west.

I guess IE allowed using BMP so it happened and we're stuck with it.

It's a pity that other IE exclusive features didn't make it, like marquee or bgsound. I also had a webpage with a midi song playing in background. Those were the times.

https://www.cameronsworld.net/

Not in the same way however. The main aomenc devs are working on how to get PSNR and SSIM up, nothing else really.

Amazed to see people tying themselves in knots to somehow argue that Facebook doesn't have enough of a userbase to matter, or what Adobe doesn't have sway over photographers/designers, so they should be ignored

Looks like you're unfamiliar on how 4chan works

This is bait

It's 4chan, *it is dumb*

This is uber dumb. JXL is a standard partially supported by Google.

>4chan ignored

Agree, it's 4chan.

4chan is a bunch of people pretending to be experts using profanity to whine about how everyone who isn't them is dumb

/g/*

is there anywhere else on 4chan

that's like if i say discord is a bunch of child predators

and at the same time obvious bait post is obvious

the whole pretending to be an expert is meta

yea, but the fact that people on /g/ constantly just put up bait doesn't speak wonders for the platform

not necessarily. that's how most of the internet works

especially twitter

it really isn't though

if "most of the internet" was like /g/ that would be such a nightmare <:kek:857018203640561677>

and g isnt entirely bad

it's almost like you forget how internet forums work

is there a JPEG XL polyfill based on paint worklet?

I *know* that there is a wasm build of libjxl, but I think I never saw one based on paint worklet

Would that have the advantage of also working for css images, not just img tags?

GPU image decode is faster for systems with combined GPU + CPU memory, ie. mobile

GPU decode will use less power too, also important for mobile

low power is important for servers as well, obvs

yes, I'm aware that there is an AVIF polyfill based on service worker (transcoding AVIF into BMP on the fly), but this approach wouldn't work well with JPEG XL where images should be progressively decoded

paintlet seems to be the best way for enabling JPEG XL support today notwithstanding with Chrome

Paintlet for SDR, hdr canvas for HDR?

Some artists already export PNGs in 16 bpc.

IDC if Google supports JXL. I'm going to keep using it. FLAC wasn't popular until quite recently (last 5-10 years), but I was an early adopter of that format too, back when only Linux and a handful of players supported it. AV1 uses a lot of tech developed by xiph.org, same folks behind FLAC and opus. It uses techniques originally meant to be part of Daala. AVIF is a good replacement for gif/mp4 video without sound, but it's a horrible format for images - and while the promise of encode times getting better might be satisfied, it's just not a format suitable for decoding still images.

None of this is new and I'm sure everyone here has said it already, but even if Google kills JXL on the web, it's going to stick around for CDNs simply for storage gains from lossless transcoding of existing images. It's also going to stick around for photographers and animators because of features that av1 doesn't incorporate by design

Just frustrated because I worked on Daala (chroma from luma), the major codec-defining technique of Daala that Google shot down for av1. Would have been amazing to have that fleshed out with the pace of development av1 saw. I don't understand why Google wants a format war with JXL when av1 and JXL are very good at different things and can coexist

They abandon their own technology... Pik, zopfli, etc

Same, starting to work on a polyfill to get it working in the browsers as well. The amount of passive-aggressive on this is staggering (they are still going on Twitter) - at this point, responding to them is pointless. The only other time I've seen this is with Manifest V3. They keep saying it's in good shape and listening to extension developers but security and ad-block developers are posting lists of issues and trying to see if there is any way to resolve it and don't feel they are being listened to. They also shipped the MIDI API without any restriction. Firefox devs have it behind a prompt and have shown it actively being exploited for fingerprinting in the wild. Google has a large advertising platform. I really don't trust Google to be fair, competitive, or impartial at all at this point. They've become authoritarian and pushing things that support the company's interest.

Yup, I cherish JXL and as it matures, will support it as my preferred raster image format of the future. Been here since its predecessor FLIF era.

Google's decision to deprecate JXL will not affect my firm decision to embrace JXL, this format has a lot of potential and I believe on it

if that was the case, why do mobile browsers not use it

I see the benefit of HW encoding for cameras, but decoding seems pointless. Decoding is already much faster than encoding in software and for a single image probably won't make much of a difference unless the image is massive.

iphones decode HEIC images in hardware, for example

in web pages?

or in the gallery app?

safari uses the same decode APIs as everything else

they actually explicitly patch out WebKit to not use the WebKit image decoders, in favor of the OS provided ones

that's safari though

that's the only browser on iphones

it's not

all other browsers use a skin around safari

chrome literally is on iOS

and it doesn't use a UIView as far as I am aware

chrome on iOS is safari, Google has complained a lot about this in fact

so they force other browsers to use the UIView

interesting

in either case, in Google's own world of chrome on android, images are not hardware decoded

yes Firefox is just a WKWebView, and anything else is banned

which still makes the argument about google and hardware decoding a non-argument

i.e. if it was so valuable it would be done

that's fair

this probably boils down to fragmentation

hardware decode is a massive PITA

I'm sure it's not a technical decision but a political one

to drop jxl

they are just citing technical things as an excuse

that's my current leading theory

I used to lurk bugzilla a ton and dear lord, hw decode was a disaster. tons of bugs for every platform, many issues with different decoders and driver versions, etc

hw avif decode is going to be horrifying

given that the lead decision maker of chrome in this regard has his hands heavily in AVIF's creation, coupled with the idea that it's One Or The Other Not Both, in someways made it DOA

they just didn't have the courtesy to say so immediately

yeah, it would be good to have at least one browser with native support for testing and adding features for web use, if the others remove it completely

Completely agree

Would be good for development and testing

Brave, Vivaldi, and Firefox have committed to supporting the current Manifest going forward. I know they use settings and flags to turn off some APIs that have security and privacy risks. Not sure if they can add new things in.

> Hayasaka > If someone made an image viewer application or web browser which makes use of GPU's hardware decoding capabilities, I would try it immediately... I made one here: https://github.com/jcupitt/vipsdisp it's on flathub, so it should be easy to try out: https://flathub.org/apps/details/org.libvips.vipsdisp it uses the GPU to composite and scale the image to the display, and it's asynchronous, so pan and zoom is decoupled from image decode you can pan and zoom around a 300,000 x 300,000 pixel image at 60 fps on a pretty basic machine JXL support too! /off-topic

(no hardware image decode though -- the gpu is just for scale and composite)

it supports a large range of pyramidal formats, so if the image has a pyramid, it can make a very fast thumbnail, yes

Are there common operations in JXL encode/decode that would benefit from a hardware accelerator though?

if there's no pyramid (eg. a huge PNG, worst case) then sadly thumbnails are going to be very slow, of course

it knows about things like SVG scaling and libjpeg shrink-on-load, so they are quick

practically everything that doesn't have a ton of pointer chasing over very large trees will benefit from hardware acceleration, but jxl is fast enough as-is

your phone's gallery app will struggle right now if you have one of those 200mp phones and take full-res pics (it may take 3-4 seconds to fully decode a picture) but that's not a huge problem, esp. since you can progressively decode them as you scroll your phone gallery

The kind of thing I’m thinking of is analogous to matrix multiplication in ML

those sorts of operations are largely very well accelerated by SIMD extensions in modern chips

but it's a very different and less challenging kind of hardware acceleration relative to building an ecosystem of competent hw decoders with good drivers

there's a few operations that are done pixel-by-pixel for examble XYB -> RGB

in my experience autovectorization did work relatively well when it comes to common operations in jxl (not optimal, but reasonable enough)

but some operations are harder to optimize by design, pshufb mentioned (modular MA) trees for example

I thought a lot about this and I have no satisfactory answer right now

MA trees would be quite difficult to GPU-optimize, I imagine

if jpeg xl makes it into Chromium, Intel-adjacent and Linaro-adjacent folks will start writing very nice patches for decode speedups based on SIMD

libjxl has no satisfactory answer either, so it instead specializes known use cases

>if JPEG XL makes it into Chromium I have bad news for you

I know :(

Oh no, decoding speed is currently fine, about on par with JXL for 10b 4:4:4 in lossy. The problem is what happens when you introduce alpha, which is where performance takes a dump vs libjxl.

how much slower is it?

Last time I checked, for an 8MP image single-threaded(can't seem to find it on my PC anymore), it was 69ms for avifdec for 10b 4:4:4, and 67-68ms for libjxl decode. Once I added back an alpha layer to that image, the decoding time jumped to 90ms for libavif, while the libjxl decode time only rose to 76ms. Again, I don't have the exact numbers anymore, but this should be easily repeatable once I update everything AV1 and libjxl related on my system.

I guess I can uninstall Chrome as I don't need it anymore.

Logically, AVIF with alpha must be much slower because the decoder is doing twice the amount of work.

If I needed lossy with alpha, I would use WebP.

I tried using lossy with alpha years ago - I remember waiting for WebP for that reason. When I did try it, it ended up washed out and dull. I read somewhere it had something to do with a restriction using alpha in lossy mode. Not sure if it was ever removed but I remember deeming it a lost cause back then. Maybe it works now?

I will look into it.

WebP should be pretty good for animation as well. Any format can do GIF-like inter frame, which combined with lossy should work pretty well. The point is WebP animation is already well supported.

I use it to test websites but otherwise I just use firefox

Same

has anyone heard anything from any chromium devs since that one comment on the issue? (twitter commentary counts for the sake of this question)

from the devs themselves? as far as I'm aware nothing

I tried a few transparent pictures and didn't see any issues. The colors are close to the PNG original.

After all, I'd expect the alpha blending takes place after the image is converted to RGB.

This was many years ago, back when WebP was first getting supported. I assume they removed whatever the restriction was since then.

Seems so

A Microsoft Edge developer found it bit surprising that https://chromestatus.com/feature/5678152091172864 was not shipped/tested as part of Chrome's origin trials before this decision was made - see: <https://twitter.com/slightlylate/status/1587030785197953024>

Again, this solidifies the hypothesis that the AOM folks are pulling the strings from the back, not just the Chrome folks.

That plus, as I've said before, Google doesn't communicate effectively between different departments. Google -> Microsoft? May the odds be ever in your favor.

Indeed, it looks like at least one API owner was not informed of this decision - see: <https://twitter.com/yoavweiss/status/1586995512313511936> <https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/API_OWNERS>

I might be entirely wrong, but didn't Pik partially come out of a desire by the Google Photos team to reduce backend storage requirements?

Similar to Dropbox and Lepton

Yes. Remember, the team doing this is the AOM/Chrome team, not the other people at Google. This is not a shared decision approved by several tie-in teams.

just say they™ :)

Works on my F2 Pro LineageOS

Chrome timed this quite well, deciding just before the weekend and then this week many people are in holidays due to All Saints / All Souls...

i pointed https://jxl.moe to that chromium thread for if you want to check that page quickly :>

hmmm i should also buy avif and webp

i already had jxl.moe for a while

Nice. Works very well.

Whoops, already been posted in <#822105409312653333>

wasm-vips v0.0.4 is now available, supporting JPEG XL images by default. See comment <https://github.com/kleisauke/wasm-vips/pull/21#issuecomment-1214342112> for some playground links to test with.

Someone suggested that we should try to get Wordpress to speak out in favor of jxl

Elon Musk and Twitter, for the hype train <:Stonks:806137886726553651>

Probably need to support it in GD first: https://github.com/libgd/libgd/issues/699 I think Wordpress will use other libraries if they are installed but will fall back to using GD.

is libgd an image conversion library?

It says "GD is an open source code library for the dynamic creation of images by programmers."

but it's not clear what that means to me

is it like a software-based graphics library like Java2D?

Not directly. It's mostly PHP's image library. You don't just say take image1.jpg and convert to image1.gif. You draw an image onto a canvas context then you can save it as a supported format. You can see details of how php implements it here: https://www.php.net/manual/en/book.image.php

according to that, it looks like java2d

it has support for raster image buffers as a canvas and drawing functions, with import and export

Time to get Elon to support JPEG-XL <:KekDog:805390049033191445>

https://tenor.com/view/elon-musk-gif-25396556

yeah, the twitter jpegs quality after compression is not very good, btw

yeah it's horrible

it doesn’t recompress images less than 5MB and 4096px wide

so if you can fit your own JPEG within those constraints, you can work around that

I have a perl script that does simple binary search to compress a jpeg to a given maximum size

though I mostly use it for Discord (8MB) and Imgur (5MB)

(note `-interlace Plane`, creating a progressive JPEG, and `-sampling-factor 1x1`, making it 4:4:4 – adjust as desired)

I have uploaded a few PNGs on Twitter that have remained PNGs, but I haven’t explored the size limit much

some have become JPEGs

hm, a lot of them, in fact

ah, there might be a difference between pasting an image from the clipboard and actually selecting a PNG file on disk to upload

Pretty sure ImageMagick can do that internally, `-define jpeg:extent=<desired size in bytes>`

oh, yes, that seems to be the case, thanks https://imagemagick.org/script/defines.php#:~:text=jpeg%3Aextent%3Dvalue,setting%20was%20ignored%2E

not sure how “The -quality option also will be respected starting with version 6.9.2-5.”

how can it simultaneously be respected

seems to be treated as a max

I think I might still prefer my script as I get to see what quality was selected in the end

Odd, I get a lower filesize with `-quality 100` than with `-quality 95` when paired with it

but this seems to work only on desktops or when enabling some settings on smartphones (although I'm not sure how it is now)

ah, the twitter limits for JPEG and PNGs are here: https://twitter.com/NolanOBrien/status/1281639466688380928

4) means ≤ 8 bpp

should be fine

the png post in there doesn't seem accurate

https://twitter.com/NolanOBrien/status/1281639467992748032

i've seen plenty of actual png's on twitter larger than 900x900

Someone at Chrome told me: Hey Jon! As you can imagine this has been a hot topic this week with many conversations around it. A more detailed rationale is being worked on for circulation pending approvals. I believe it will be posted in the coming days.

hmm

<:garfieldneutral:823249094180732998> At this point I'm not much interested in their excuses.

I answered this: I see, looking forward to see that. I think it would have been better to first collect all the evidence and arguments, involve internal and external experts and the community in general, agree on what the facts are and identify where there are differences of opinion, carefully weigh all the pros and cons, and _then_ make a decision. Especially when the final decision makers have some horses of their own in the race...

In any case it is kind of suspicious that they still need to work on a more detailed rationale and get it approved _after_ the decision has been communicated. Normally the rationale comes first and the decision follows from it.

really eager to kill it as lazily and as fast as possible, aren't they

perhaps instead of "rationale" they meant to say "rationalization"

"Google-sensei" made me chuckle

Google was doing evil long before they removed it from their policy. 🙊

Their rationale better be that they've secretly made _another_ format with the similar features and better compression during this time and are adding support as well as open sourcing all the required things to allow other browsers and software to also implement it. That's _totally_ it, right?

you forgot putting out standartization and independent implementations

I'd assume things like that would be covered under open sourcing everything. But I guess considering how picky laws can be I'd need to specify.

There will likely be many, on every video formats generation and probably an AI codec for 0.1 and lower bpp

Hi All - as some may know, we are currently working on adding JPEG-XL support to DICOM (the standard for medical images). The fact that google dropped support for JPEG-XL and the open patent issue with MSFT on ANS may cause this effort the be abandoned. We certainly see the value in JPEG-XL but these issues are having broad impact

having readable code would be enough in theory, but in practice a lot of codec code isn't that easy to read

another thing is avoiding usage of patented technologies

I understand, but I think it's best not to rush to conclusions. It looks like Google already changed its tone from "we will remove it" to "no support at this time". The Microsoft patent is not an issue for jxl.

Microsoft has the chair of SC 29, which is the subcommittee under which JPEG operates within ISO. They have never declared that their patent is relevant for JPEG XL. And indeed, it isn't: their patent is about adjusting dynamic probabilities during decode, while JXL only uses of ANS with static probabilities. Also the libjxl implementation has been public since the beginning and it predates the filing of Microsoft's patent, so even if it would be relevant (which it isn't), it could never contain claims that would cover things used in libjxl without easily demonstrable prior art.

Also I think it should be clarified that it was not "Google" who dropped support for jxl, but more specifically Google Chrome. The team at Google that has been working on jxl is still working on jxl and I don't think that will change.

Even more specifically, AOM itself.

Some of the companies that are part of AOM are in support of JXL.

Would you be willing to share this on the Google issue?

DICOM is a use case where the fidelity problems of webp and avif are too big — misdiagnosis due to the tumor getting smoothed away by compression is not something anyone is waiting for — yet having a browser-supported image format is very practical in the modern world.

I recently released version 1.0.2 of the Paint.NET JPEG XL plugin. This version updates libjxl to version 0.7.0 and adds support for EXIF and XMP metadata.

Why is there no link? Why didn't you send the addon file here? Unclear.

I assumed that people would know to get the plugin from the Paint.NET forum: <https://forums.getpaint.net/topic/120716-jpeg-xl-filetype/>

👍 https://github.com/0xC0000054/pdn-jpegxl/releases

I'm (probably) going to be doing WSI DICOM (WSI == whole slide imaging, ie. virtual microscopy) support in openslide over the next few months on an NIH research grant and I'd love to include jxl support as you say, being able to serve tiles to a web browser with a simple memcpy() is pretty much a must-have feature, since ootherwise scaling to large numbers of users becomes impossibly expensive I think everyone is very likely to stick with jpeg in dicom (99% of current WSI DICOMs) if jxl doesn't get browser support

> which is being more and more supported - particularly by web browsers

<:sadboi:494652587732238337>

> JPEG XL import/export — Affinity Photo has been a leader in editing wide colour gamut and HDR images, with full support for full HDR displays, but now external developers can see what you see in Affinity Photo thanks to this new export option.

awesome

more evidence of "not enough interest from the entire ecosystem"

<https://news.ycombinator.com/item?id=33530356> Affinity Designer (and Affinity Photo, Affinity Publisher) just had their big Version 2 release today, with a main feature being full Import / Export for JPEG XL. This is a major commercial creative suite, and hugely popular in the professional world. 2nd only to Adobe Illustrator, Photoshop, etc.

nice to have good news from Affinity after bad news from Chrome! I hope we will find a way to convince the browser ecosystem, too 🙂

it's pretty major- artists are going to be demanding jxl support in browsers now after seeing the quality/filesize improvements first hand.

Great news, and may give Adobe a bit of a push to add to Photoshop & Illustrator.

Bro, JPEG-XL got ffmpeg support before AVIF.

That alone should be a contributing factor for supporting it.

At this rate, every single piece of image-related software in the world will have JXL support before the browsers even think about it again.

That's the ideal scenario.