JPEG XL

Question: is it possible at this point to add other forms of quantization dithering into the JXL standard? Fruit dithering quantization is still quite effective, and far faster than error diffusion dithering.

After someone attempts it first and makes as much progress as possible, then it will be much clearer what subset of JXL is easy to implement in those limitations and what is possible with some cleverness and what is just plain pain in the ass to do.

This could be particularly useful for libjxl-tiny in particular.

Are you talking about something encode-side or decode-side?

Encode side for AC quant.

Then the answer is yes - the encoder is not standardized.

Encoders can do whatever they want, as long as they produce a valid bitstream.

Here is the speed test thing in a way that works in Firefox (nightly with the flag enabled) too: https://sneyers.info/browserspeedtest/firefox.html

FF Nighty, Android 9, 2018 smartphone: s.jpg: Decode+render speed: 17.25 MP/s | Fetch: 748.00| Decode: 12.00| Render: 7.00 s.jxl: Decode+render speed: 5.12 MP/s | Fetch: 667.00| Decode: 60.00| Render: 4.00 s-fd1.jxl: Decode+render speed: 8.62 MP/s | Fetch: 1024.00| Decode: 35.00| Render: 3.00 s-fd2.jxl: Decode+render speed: 7.80 MP/s | Fetch: 969.00| Decode: 40.00| Render: 2.00 s-fd3.jxl: Decode+render speed: 7.99 MP/s | Fetch: 1242.00| Decode: 39.00| Render: 2.00 s8.avif: Decode+render speed: 6.83 MP/s | Fetch: 877.00| Decode: 47.00| Render: 1.00 s10.avif: Decode+render speed: 9.93 MP/s | Fetch: 1167.00| Decode: 31.00| Render: 2.00 s12.avif: Decode+render speed: 6.97 MP/s | Fetch: 1055.00| Decode: 45.00| Render: 2.00 s.webp: Decode+render speed: 16.38 MP/s | Fetch: 1159.00| Decode: 17.00| Render: 3.00

Running it some more on my phone, jxl seems to average to the same speed as avif 12-bit, both at 60ms on average. Avif 8-bit comes in at roughly 40ms, so jxl is not that much slower.

here's my galaxy a50 on firefox nightly ``` s.jpg: Decode+render speed: 9.36 MP/s | Fetch: 760.00| Decode: 24.00| Render: 11.00 s.jxl: Decode+render speed: 3.60 MP/s | Fetch: 586.00| Decode: 81.00| Render: 10.00 s-fd1.jxl: Decode+render speed: 4.96 MP/s | Fetch: 962.00| Decode: 62.00| Render: 4.00 s-fd2.jxl: Decode+render speed: 7.62 MP/s | Fetch: 1229.00| Decode: 40.00| Render: 3.00 s-fd3.jxl: Decode+render speed: 5.04 MP/s | Fetch: 995.00| Decode: 59.00| Render: 6.00 s8.avif: Decode+render speed: 6.97 MP/s | Fetch: 658.00| Decode: 43.00| Render: 4.00 s10.avif: Decode+render speed: 11.30 MP/s | Fetch: 325.00| Decode: 29.00| Render: 0.00 s12.avif: Decode+render speed: 9.10 MP/s | Fetch: 234.00| Decode: 36.00| Render: 0.00 s.webp: Decode+render speed: 18.20 MP/s | Fetch: 443.00| Decode: 16.00| Render: 2.00 ```

what do all these timings actually mean? lots numbers with no units on them

also not surprised about avif being faster on unmodified firefox lol

the first number is megapixels per second. The others are time to download (in milliseconds), time to decode, and time to actually put the decoded image on an image canvas.

I see

https://sneyers.info/browserspeedtest/multi.html

I get similar results regarding webp in Falkon browser (QtWebEngine, Blink based): s.jpg: Decode speed: 15.27 MP/s | Fetch: 184.84ms | 500 decodes: 10732.28ms s8.avif: Decode speed: 15.01 MP/s | Fetch: 169.11ms | 500 decodes: 10914.57ms s12.avif: Decode speed: 14.63 MP/s | Fetch: 212.83ms | 500 decodes: 11199.54ms s.webp: Decode speed: 300.89 MP/s | Fetch: 179.94ms | 500 decodes: 544.52ms ~~Kinda makes me think that it either caches the decode result somehow, or has a specialized code path somewhere so it doesn't decode images unless the result is actively being used.~~ (Edit: it's significantly faster on single image decode as well)

(apparently QtWebEngine uses an old version of blink that still suffers from this: <https://bugs.chromium.org/p/chromium/issues/detail?id=877083>)

Here's what I'm getting in Firefox Nightly s.jpg: Decode speed: 167.90 MP/s | Fetch: 3.80ms | 500 decodes: 975.80ms s.jxl: Decode speed: 38.16 MP/s | Fetch: 3.14ms | 500 decodes: 4293.34ms s-fd3.jxl: Decode speed: 42.40 MP/s | Fetch: 3.06ms | 500 decodes: 3864.28ms s8.avif: Decode speed: 46.39 MP/s | Fetch: 2.90ms | 500 decodes: 3531.96ms s10.avif: Decode speed: 42.49 MP/s | Fetch: 3.50ms | 500 decodes: 3855.76ms s12.avif: Decode speed: 38.93 MP/s | Fetch: 2.80ms | 500 decodes: 4208.96ms s.webp: Decode speed: 71.93 MP/s | Fetch: 3.24ms | 500 decodes: 2277.84ms

a thread could probably be created in this channel to continue posting about results

decode speed measurement

yeah good idea

moved my own messages to the thread (manually, by copying and then removing them)

discord needs a "move this message to that thread" function

https://chromium-review.googlesource.com/c/chromium/src/+/4081749/8#message-d0ea06062e881b618f63f4649e7e216dd19117d1

Looks like they're ripping out the code, not just expiring the flag...

Was already said they would, no?

It wasn't quite clear if they meant actually removing the code or following the usual process of expiring a flag but keeping it available for a few more versions

https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/xX-NnWtTBQAJ > After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment.

Yeah - IIUC, normally when experiments are removed, they expire the flag, keep it available (behind another 'temporarily unexpire flags' flag) for 2 more milestones, and then do the actual removal.

Seems like they just want it out asap...

And for no logical reason, as far as we can tell.

What exactly can we do at this point?

rip

Promote Palemoon and somehow get Firefox to merge the fixed patches and enable JXL in mainline.

That is the only way Chrome will be forced to support JXL.

I get the latter part, but does promoting Pale Moon really do anything? It's such a small browser.

Small in terms of market share, I mean.

sadly I don't see promoting palemon as doing much and I really believe that mozilla doesn't care about jxl

My friend, they don't care about AVIF or proper color management <:KekDog:805390049033191445>

Still no animated AVIF support. Again, the main issue is Mozilla's lack of manpower more than anything else. I personally believe JXL would have already been merged in mainline if they had their pre June 2020 numbers.

There's actually some work on supporting it now, https://bugzilla.mozilla.org/show_bug.cgi?id=1788119

Firefox and/or Safari? Or perhaps get a non-chrome chromium browser like Edge or Opera to keep the code and enable support, deviating from upstream?

I'm guessing Safari or Edge may make the most impact, along with Firefox.

The relative rush they seem to have to rip out the jxl code from chrome, could be an indication that they're really scared of people enabling the flag and using it. Otherwise they could have just announced they're not going to enable it, but keep it until the expiration milestone it had (M115), with the usual 2 extra versions where it's still there but behind an additional flag.

Why exactly would they be scared of people enabling the flag?

They first announced removal like one week after Adobe gave their users instructions on how to enable the flag

I think they probably have internal telemetry showing how many people enable that flag, and they must have seen a sudden uptick

If they see too many people enable the flag, it might get harder to justify removing it. Perhaps that's why they are rushing things now?

I am just speculating

We can request other forks of Firefox like Waterfox to build in JPEG-XL support; it should be easier for them as they're forked from a newer codebase unlike Pale Moon, so including the pending Phabricator patches should be a no-brainer

I think WebKit has also implemented JPEG-XL support? They just haven't enabled it in Safari yet, but we can request other WebKit-based browsers like Epiphany to build JPEG-XL support too

Yes, getting it in other webkit and gecko browsers would be nice

making a pull request would probably be better then a issue

me and a friend have the need changes lined up

when they are online ill see about getting a pull request made

That would be cool

yep :)

That would be great!

I believe it's because they expected less people had enabled it so as to justify "low interest reports". But since that did not happen they resort to pulling smelly stuff out their bums.

also with the backporting effort from <@707907827712131102> of jpeg xl for palemoon it should be easy to create a pull request for waterfox classic also! hopefully that's alright I know that in the past waterfox classic has used code from palemoon so it should be fine

even if firefox eventually supported jxl (which seems unlikely, given how reluctant if not negative they are towards the idea), their market share is too small to have influence on chrome IMO. i'd love to be proven wrong though...

Firefox is like 33% of all current independent web-standard implementations (I don't count KHTML). It still have weight

I believe it eventually boils down to whether web developers are willing to add new sources to their `<picture>` (or even willing to use `<picture>` in the first place)

if they are willing, *some* major browser having JPEG XL support can be a reason to add another `<source>` because they can easily add one (well, not that easy, but comparably easier than no `<picture>`)

but if they are not willing in general, the lowest common denominator will be probably WebP or sometimes JPEG and nothing will change

I don't really think Mozilla has any motive to outright remove jxl support, but they don't really have any motive to rush the implementation out of the door either because they have limited resources and now that Chrome has dropped the support there's no need for feature parity

They just need to accept the patches, it's not like it's a huge effort on their side (except for HDR, but for that, most of the effort would be to get HDR in general supported, e.g. also for avif)

Actually, it would have a huge influence. Why? Performance metrics. Lower bandwidth = better performance.

but there is another way, lowering bandwidth even more by lowering quality to just an acceptable level (which is where avif seems to be aiming)

it would be very interesting to adaptively adjust the preferred image format by bandwidth

HTTP does have a way to signal this, namely HTTP negotiation, and it can also signal a quality factor to determine the final outcome

so that for example if a client requests jxl with q=0.8 and avif with q=0.6 and a server has png with q=0.2, jxl with q=0.5 and avif with q=0.6, then the server calculates a product of qualities (here jxl q=0.4 and avif q=0.36 while png being discarded) and pick the alternative with the highest quality (here jxl)

q is actually a preference, but the client can prefer more demanding formats (higher q) when bandwidth is limited

so q would be inversely proportional to bandwidth

yeah, but this adds complexity, although some CDNs can do something like this, but I think most will go the easier way of less formats and the smallest size with acceptable quality

there's also the `Save-Data` client hint. E.g. in Cloudinary, when you use `q_auto` without qualifiers, it will send `q_auto:good` by default and `q_auto:eco` (which produces a somewhat lower fidelity image) to clients who have `Save-Data` set.

And in combination with f_auto, that can mean that clients who want to save data (which can be because of slow network but also because of metered/expensive network) can e.g. get a webp or an avif, while those who don't get a 4:4:4 jpeg or occasionally even a near-lossless webp.

If jxl would be an option, we would likely often send that, but since we can adjust per-image and per-desired-fidelity, probably in some cases avif would still be used (low-fidelity images with hard edges, in particular).

Not when banding is a massive issue 😂

Notice how they always used 8-bit AV1 in their comparisons...

quality is a problem for users, but not always for companies and instead of improving quality they rather want to reduce their costs for example youtube, I notice a lot of previews with banding, especially animated webp this is even more relevant to new video formats, like vp9 bitrate compared to avc is often much lower than the real encoders efficiency gap, also av1, sometimes it is half of vp9 size

I'm fine with anyone using my patches for Pale Moon! They're MPL-licensed after all. Though I'm not sure if all of my patches would get backported cleanly into their Classic branch, as Pale Moon and Waterfox Classic forked from mozilla-central at different points, with Pale Moon at 52 and Waterfox at 56...

there are some big code differences between 52 and 56 but they are pretty close in most areas since they are only 4 versions apart

Yeah, but in some areas Waterfox is ahead of us in the backporting since they have the Mozilla refactoring that is present in 53-56 for free, and who knows maybe they don't even need our RGBA workaround and alpha premultiplication fix

The AV1 decoder is one example, WC has dav1d since they have the refactoring changes on the video decoders, while we're stuck with libaom. I actually have tried putting dav1d to Pale Moon's platform, but my only obstacle is literally the decoder itself, all the other plumbing for the build system is there...

off topic but I still remember when basilisk was based on 53 instead of 52

Anyway if anyone's interested here's the current "progress" of dav1d support in Pale Moon: https://repo.palemoon.org/jobbautista9/UXP/commits/branch/dav1d-attemptfix

My recent comment in the bug tracker might be useful to anyone who used JPEG XL in Chrom(e|ium) Canary before, but now can't because of Google's ||retarded|| changes: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c299

oh wow its at 744 stars now

https://en.wikipedia.org/wiki/Streisand_effect

yup lol

There are a lot of people that hadn't even heard of JXL that are asking what it is. Only a good thing.

If anybody is interested, I've updated my JXL.js WASM decoder to use multiple threads (workers). Try it here: https://niutech.github.io/jxl.js/multithread/

Nice work

it really seems like they're afraid of JXL traction

That's really cool, congrats on making it multithreaded.

Thank you!

Any benchmarks?

You can test it yourself by comparing https://niutech.github.io/jxl.js/ with https://niutech.github.io/jxl.js/multithread/ (clearing cache in dev tools after every run)

I think they mean split out decode / render benchmarking like Jon was showing earlier: https://discord.com/channels/794206087879852103/803574970180829194/1050327200618008616 I have that information printed to the console for each image that is decoded.

Probably a stupid idea, but what about we do an image host, like Imgur but only JPEG-XL images are allowed

We all upload images there, and intentionally link there instead of using a platform's existing upload feature, you know, out of spite

FWIW, JPEG-XL support is on my to-do list in 2023 for the <https://github.com/weserv/images> project. See e.g. comment <https://github.com/weserv/images/issues/238#issuecomment-974857730>.

Other than AVIF encode (😅), I think our servers can handle that.

why would you make a service that is inherently user hostile? 🤔

this kind of thing would only make sense if that service had very big market share, but there are already many popular image hosts like imgur etc

I heard the market share was reason why firefox added webp support after so many years, because web developers started using webp without a fallback, many websites appeared simply broken in firefox. but I don't think a new image hosting service would have that sort of monopolistic position

youtube started showing previews only in webp after a while and also no longer encodes avc for videos higher than 1080p and since it is a very popular service, other browsers and platforms have been forced to support webp and vp9 (and now av1 as well)

Huh, that Catbox/pomf + embed.moe solution is neat, I will definitely use that when posting found fanart in r/touhou

Yeah, that's why I said it's probably a stupid idea :P

No fallbacks is user hostile indeed, and if YouTube did that with WebP, it's kind of dirty tactics to force firefox and safari to implement things they don't want to implement. I don't think this is how I would want jxl to be pushed. Forcing things down people's throats is not the right way, whether it is forcing them to use something or forcing them not to use it.

They never encoded h.264 stuff higher than 1080p.

https://blog.youtube/news-and-events/whats-bigger-than-1080p-4k-video-comes/

there were 4k videos on youtube even before vp8 and vp9 came out, and I saw a lot of 2k+ videos in avc, I don't remember the exact period, but it was probably before 2013-2015 and now it's only vp9+

semi-unrelated but HLS and DASH are such alien technologies. I once looked into how to implement a HTML5 video that takes screen resolution and bandwidth into account and there seems to be very little open source tools and documentation available

it's basically all 3rd party services that handle it for you. you'd think it would not be that complicated to encode a video in several resolutions and split it into segments and generate some metadata to go along with it

The actual encoding I think can be done with ffmpeg

This is a good blog post that covers setting up DASH streaming: https://shkspr.mobi/blog/2017/07/using-youtube-to-transcode-videos-to-dash-on-the-command-line/

What's this? https://chromium-review.googlesource.com/c/chromium/src/+/4095497

someone random made it

a non google person

This is pretty cool but it doesn’t really explain the process, since you are just using YouTube to generate DASH fragments and metadata for you…

There is some stuff in the FFmpeg documentation, though it is fairly dense. https://ffmpeg.org/ffmpeg-formats.html#dash-2

Technically someone could fork Chromium, add JXL, and do nothing else but keep the code up-to-date with the Chromium base and likely have a smash hit browser... Call it Chromium XL <:kekw:808717074305122316>

Intel? Adobe? Facebook?

Sadly it wouldn't include google chrome. I wonder if there's still hope for jxl. I wonder if it's possible to force chrome to adapt this format

I stopped using Chrome years ago BECAUSE of the <:Google:806629068803932281> part.

https://github.com/mozilla/standards-positions/issues/522 is there a way to request that issue to be re-opened? I think there's quite some new information to be added there now (it was locked almost a year ago).

I've added a quick benchmark to JXL.js README, you can also check the times in web console.

Does MS Edge use Blink's decoders, or does it use Windows OS' decoders? I thought it used Blink's, but AVIF is unsupported, so I dunno.

it uses blink afaiu, but I assume Edge makes their own choices in enabling or disabling things, and they might want to wait to support avif until they have full OS level support for it too (or maybe they're actually taking a position here and don't want avif to become a permanent part of the web platform? I have no idea)

which makes it all the more annoying that Chrome devs don't just disable the flag in Chrome M110, but they rip out the code from Chromium so all the downstream browsers like Edge, Opera etc don't get a choice (unless they would patch it in again, but that's a lot more effort than just changing a flag).

Im afraid they missed out on that opportunity now, since we have introduced official support in Pale Moon now . Transparency will be fixed forthwith and we'll have progressive and animation support in January

They can still be better than Chrome 🙂

I think they already are ;)

in one more area then 🙂

well it would be a good reversal of trend in that case. since how they've been aping chrome and losing their uniqueness

https://github.com/mpv-player/mpv/pull/10998

https://github.com/mozilla/standards-positions/issues/721 I can only try, right?

Did I miss it or did it get delayed?

update for chrome dev with jxl removal has arrived <:SadCat:805389277247701002>

It got delayed because I made huge mistakes on the AV1 side and one of my editors pointed it put <:PepeSad:815718285877444619>

the issue was closed with 793 stars, the only chance now would be large media coverage - write to journalists, youtubers, influencial people describing this scandalous situation

https://storage.googleapis.com/avif-comparison/decode-timing.html Somehow the AVIF team's decode benchmarks still show AVIF with much better decode performance than JPEG XL. Is this data accurate? I'm getting conflicting information from both sides. https://storage.googleapis.com/avif-comparison/images/decode-timing/charts/DecodeMPs_Chrome-110-Win_AVIF_JPEGXL_WebP_JPEG_900w.png

Also, the issue is now **closed** *WontFix*. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c325

I think it depends a lot on what exact colorspace the avif is in

If it's specifically 8-bit 4:2:0 and the right colorspace signaling, it is a lot faster than if one of those things is different

Also the testing methodology they're using seems to have significant error margins, because I don't know what else can cause such differences between 0.4 MP and 0.3 MP

What exactly is colorspace signaling? But anyway, yes, it's at least for sure 4:2:0 (`-y 420`)

Highly suspicious that 2 threads is more than twice as fast than 1 thread

The ICC profile, or the enum colorspace (avif also supports both ways)

So the only thing they compare is "decoding speed" which they claim JXL is unbelievably slow according to one chart, "encoding speed" where they ridiculously claim AVIF is faster to encode than JXL, "quality" that isn't based on human perception and where they have an insane methodology of taking the average of a whole bunch of useless data to skew the averages, and lastly "lossless" where they admit JXL excels at but claim it's still slow.

What was absolutely not compared or considered in this farce of a comparison is the lack of features in AVIF.

The lack of progressive decoding or lossless JPEG transcoding

And all of the other limitations of AVIF

Who are these selfish people, who refer to themselves as "WE have decided to end the experiment blah blah..."

https://sneyers.info/browserspeedtest/index2.html e.g. here I get very different results than on the other image, and I don't really know what causes that

Who even is "we"

I would really like to know who my exalted lord of the internet is

I'm using nightly and AVIF decoding is significantly slower according to this page.

Pretty sure firefox nightly uses dav1d

> Note: For JPEG XL and JPEG XL progressive 8.1 megapixel test sets, the JPEG XL decoder was causing a color issue with the decoded files, so we could not get valid MS-SSIM values, so for those files we picked the quality that was closest to an average 0.95 bpp.

I wonder what happened there...

Yeah, I wonder. It's not like anyone from Google consulted with anyone.

Or asked for anyone else's opinion

I realized that they have used non-progressive decoding for progressive JPEG XL images, what a bummer

```javascript function decodeImage(imageByteStream, mimetype) { imageFetchedMilli = performance.now(); if (imageIndex > 0) csvFetchingTimes += ',' csvFetchingTimes += (imageFetchedMilli - timeBeforeSrcSet).toString(); imageDecoder = new ImageDecoder({data: imageByteStream, type: mimetype}); imageDecodeStart = performance.now(); imageDecoder.decode({frameIndex : 0}).then(renderImage); } ```

this requires `{ ..., completeFramesOnly: false }` to the `imageDecoder.decode` call to enable progressive decoding

I assume the decode comparison by the AVIF team wasn't tested with <https://chromium-review.googlesource.com/c/chromium/src/+/4031214>?

All vardct jxl images are progressive btw, so the distinction they're making is a bit misleading. The examples in the recent blogpost on saliency-based compression for example, would not be in the "progressive" category in this comparison...

Would be interesting to make a measurement for "time to render first preview", if that can be done in this api.

https://jsfiddle.net/rgz0a2v1/3/ I've tried to make a visual test out of those test images, but `Image` seems to cache decoding results in addition to raw image files?

can see a reason to use `ImageDecoder` (somehow incorrectly, which can be well unintentional)

Context: I haven't noticed that decoding AVIF images is faster than JPEG-XL images in the past, especially outside the browser-context. But this was tested with aom (see e.g. <https://github.com/lovell/sharp-libvips/issues/97> for details).

Anyways, I plan to update the round-trip benchmarks at <https://github.com/kleisauke/wasm-vips/tree/simd/test/bench#results> to include both AVIF and JPEG-XL images.

I don't see significant _inherent_ (i.e. caused by the format specification, not by the specific implementation) reasons why avif and jxl decoding should have a substantially different decode speed. In the end, in both cases the decoder is doing entropy decode, dequant, iDCT, filtering, and color conversion. I don't see substantial differences in the underlying overall computational complexity. But of course implementations and integrations can differ, and especially having more specialized code paths for specific cases can make a difference.

It's not *that* odd, mobile CPUs are odd (and AFAIU 1/2 threads means "not tiled/tiled"

But those numbers do look a bit odd

I've tried to insert progressive decoding (it's a matter of overwriting that function in the inspector), and it didn't make any difference. thinking about that, progressive decoding wouldn't show up when you have fully cached images...

so I guess we can't actually use that API to verify progressive decoding in a controlled manner

because we can't control the transport

One big implementation difference is that dav1d has specific code paths for 8-bit, 10-bit and 12-bit, while libjxl does everything with 32-bit floats at the moment. On low-end cpus that makes a huge difference — but it's not something that is inherent to the format: it should be possible to add faster specialized code paths in libjxl too when only 8 or 10 bit precision is needed, but that's a lot of implementation work. Question is to what extent decode speed is not just 'fast enough for the web' anyway.

There's no way to truncate the fetched bitstream?

only if you do that from the server side

ah, nope

so did you mean to truncate the stream *in the middleware*?

hmm that may work

Oh, so it's not the same input file, yeah that can explain things.

Oh, the 0.4 MP images are the Kodak set and the 0.3 MP images are the rasterized no-alpha emojis. Yeah that would explain the difference.

here's hoping the dav1d people make a djxld next lol

I think it only really makes a noticeable difference if you have a very low end phone on a very fast network, tbh.

> _fast enough for the web_ But the differences in these graphs are drastic. Even allowing for 15% smaller JXLs than AVIFs, according to these measurements, my phone battery would die much quicker browsing the same site filled with JXLs instead of AVIFs, no? And quicker still if it's already a weak battery, because the phone is old...

When using two threads, more power is used than when using one thread

But in general I think image decode is only a very small fraction of what drains a phone battery when browsing

On the cpu side, much more is going on, like javascript

And cpu is not that power consuming anyway compared to transmission, screen, etc.

If a progressive preview allows you to make a navigation decision 1 second earlier, the saving in other battery consumers (continuing the loading of the page, executing js, lighting up the display, etc) might very well make up for all the image decoding you're gonna do that day.

in general the most power-consuming part of your phone is screen

if you can dim the screen you can considerably reduce the power drainage

your battery will drain significantly quicker if you *consistently* download and decode images for many hours, but nobody does that

Also: cpus have power saving idle modes where they use almost no power, and during transfer at least one core needs to be awake anyway to process the data coming in from network. If decoding is done in a streaming way, the total awake time is lower than if you first fetch and then decode.

Basically it's not reliable to draw conclusions on battery life based on isolated decode time alone, and in any case the overall impact of image decoding on phone battery life is likely pretty small.

For video this is way more relevant, and it could actually be a reason to avoid av1 on phones if it can do hw h264 or vp9 but has to do av1 in software.

Thanks, makes sense.

It's not too hard to measure how much power it actually draws

And there can be weird second order effects

Measuring power consumption in 'lab conditions' is not that relevant imo, since differences in user behavior that are caused by differences in how the image loads will have a bigger impact than anything else. If a progressive preview causes the user to realize 'this is not the thing I was looking for' or 'this is the link I want to click' a fraction of a second earlier and navigate away from the page, that will have way more impact than differences in image decode cpu cost.

Again this is different for video, which is a much more passive thing so you can measure the real effect on battery more easily.

Web browsing is a more active thing and differences in ux and user behavior will play a much bigger role than for video consumption (where the ux is the same regardless of codec, the screen power draw is the same regardless of codec, and the only differences are in the cost of decode)

<:PepeSad:815718285877444619>

You can't really stop receiving responses for a request already made, but you could stop decoding those bytes, yes. No idea if browsers already do that atm.

It is possible, but the browser would have to do it, not the decoder. You can mimic this using the Intersection API and a fetch request using an abort signal. I don't think there are any browsers with this functionality built in.

you could close the TLS socket prematurely, could you?

we need to run a Manchurian Candidate for a chromium leadership role

https://forums.opera.com/topic/59327/jpeg-xl-support

> If Chromium will no longer support it, most probably all Chromium based browsers will do the same

This is likely correct, but it kind of makes me wonder why Chromium forks still exist, if they basically always just follow upstream. Are they really just skins with various branding?

no, some exist to make brendan eich money with various scummy schemes

In Opera and Edge's case, that would defeat the whole purpose of dropping own engine in favor of Blink.

Not really. Maintaining your own engine is a lot of work. Getting updates from upstream is a lot more convenient. But there is no point in forking if you always just blindly follow upstream. Normally a fork only follows upstream changes to the extent that the fork authors agree with the upstream changes, skipping changes they don't like and adding patches with things they want to do differently.

If even in a case like this where according to many people "upstream is wrong", all the forks are still just going to follow upstream, then I wonder why those forks keep bothering with having their own browser: just tell people to install Chrome if you're going to be just the same thing as Chrome anyway.

Perhaps the purpose is to take all Google's telemetry and replace it with their own, and also bloat the browser with their unnecessary services.

yeah, mostly replacing services and ui, adding some features, but not something like core changes or adding any standards

I wonder why edge still doesn't support avif then though

probably because there were attempts to make os-based support with hardware decoding

that would make sense for av1 video, but why postpone avif images for that?

this is just a guess but i'm pretty sure the reason edge doesn't support avif is because they messed with the code that handles av1 to make it rely on codecs installed from the microsoft store (like they did for some other video codecs) and ended up breaking avif since it relies on the same library

for example if I go on the gpu page av1 is under the media foundation section

so yeah they probably just broke avif support and haven't bothered to fix it since I can't think of any other incentive for them to not support avif

is there even a WIC plugin for avif?

basically chromium is used as base for adding new browser features but it's often debatable if these are genuine useful or a """value-add""" to lock users into some other ecosystem like for example edge uses microsoft account and it has other integrations to microsoft services

it's basically the same thing with android, manufacturers take the open source version and then add some customizations to it. like with operating systems, creating a browser from scratch is a lot of work so it's effective to use an open source project as a base rather than trying to build your own

Reminds me of Maxthon Browser and other browsers that used Windows' web view (Trident)

https://www.reddit.com/r/firefox/comments/zpyihe/in_firefox_1080_stable_i_enabled_jpegxl_jxl_in/

Is that true? If so, that is nice!

Didn't work for me

Though mine is a different version (108.0.1)

Tried it on a fresh install (linux firefox-108.0.1.tar.bz2) - doesn't work for me either

yeah, it doesn't work for windows 108.0.1

maybe the website they are using to test is doing something wrong?

https://jpegxl.io/tutorials/firefox/

^ i can't test at the moment but see if this website displays anything

but there's also jpegxl.info https://preview.redd.it/x5cdu5d58w6a1.png?width=1920&format=png&auto=webp&s=14ab69eb30c7bbbf3ab31bb15b47f519308a7d45

I wanted to try on android firefox, but it doesn't even have about:config in the stable version on android?!

That's firefox doing jxl with alpha wrong. The patches to fix that are there, but aren't getting merged

It used to, but they removed it at some point

avif and av1 is in the microsoft store

in firefox 108.0.1 (64-bit) stable on MacOS, enabling the jxl flag doesn't work

in firefox 108.0 (64-bit) stable in debian, enabling the jxl flag also doesn't work

Don't you have to be using nighly build?

yes

https://www.reddit.com/r/jpegxl/comments/zpynur/in_firefox_1080_stable_i_enabled_jpegxl_jxl_in/

but someone on reddit is saying it works for them on the stable build, which is weird

It's not weird that random people on the internet don't know what they're doing or saying :)

no, but this seems something oddly specific to say just randomly/accidentally

Looks like arch linux thing, presumably they compiled it from source with some weird flags?

The weird thing is, in their official "Experimental features" page they claim that it's shipped in Beta and Developer Edition channels since FF 90, even though it's not true: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#jpeg_xl_support.

Waterfox just started building JPEG-XL support into their browser: https://github.com/WaterfoxCo/Waterfox/issues/2924

nice! however it's not enabled by default and they are also missing all the unmerged patches

me and a friend where gonna make a pull request

however my friend hasn't been available to do so

not because of any technical reasons just because of life and timing

me and friend solved that I forgot exactly how but my friend has the code diffs

telegram: "AVIF, JPEG XL, HEIF support in Windows build" https://github.com/telegramdesktop/tdesktop/pull/25585

Could it be a firefox study to enable it in stable?

hi I'm the friend lol

Waterfox is based on Firefox ESR, so it's almost actual Firefox? I think it would be better to apply patches before enabling JXL by default

According to this list of unknown accuracy it isn't a study. https://www.jeffersonscher.com/sumo/shield.php

https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 this shows "Updated 5 days ago" but I cannot see _what_ was updated

Somebody just CC'd to the bug, according to the history: https://bugzilla.mozilla.org/show_activity.cgi?id=1539075

oh, does that cause it to be 'updated'?

yeah

so we still don't know then what caused firefox stable on arch linux to somehow have jxl working (behind the flag)?

That is a possibility, but the more likely possibility is that Arch building stuff.

I don't see anything obvious in either direction here: https://github.com/archlinux/svntogit-packages/blob/packages/firefox/trunk/PKGBUILD

does anyone have a link to the frog test page?

https://jpegxl.io/articles/browser-support/

Probably this one

ah nvm I found it

I was looking for something like this: https://jpegxl.info/test-page/

FWIW, I use Arch Linux 108.0.1 stable and it's not working, even with the flag enabled

looks like it might be exclusive to 108.0

lots of sites use webp

> We have had WebP for years, and still almost no one uses it This statement always amazes me. Dude, the second most popular site in the world just shows all the animated previews in webp. 😄

pretty much every web developer I know of will disagree 🤔

The original "jxl" image they're mentioning is at https://w2w-images.sftcdn.net/image/upload/v1620662834/Ghacks/IMG_20200308_194050.jxl. It's a transcoded JPEG file, so it's already smaller as-is. > Original JXL file: 4.6M (4720201 bytes) > Reconstructed JPG file: 5.5M (5699320 bytes) If we try to match their reported sizes via mozjpeg and cwebp, and try to re-encode to JXL with a similar SSIMULACRA2 score: > Re-encoded JPG file (`cjpeg -q 80`): 1.9M (1949355 bytes) > JPG SSIMULACRA2 score: 71.01064555 > JXL matching JPG (`cjxl -q 88.1`): 2.3M (2368304 bytes) > JPEG-matching SSIMULACRA2 score: 71.05529657 > Re-encoded WebP file (`cwebp -q 75`): 1.6M (1666804 bytes) > WebP SSIMULACRA2 score: 61.90709567 > JXL matching WebP (`cjxl -q 80.875`): 1.5M (1507413 bytes) > WebP-matching SSIMULACRA2 score: 61.90007021 I can't seem to match the WebP size exactly. Maybe the encoder has improved somewhat. The re-encoded JPEG being bigger than the re-encoded JXL is a bit surprising, though.

On another note, for some reason, when going from Original JXL -> PNG (via `djxl`) -> JXL (via `cjxl -q 88.1`) -> PNG via ImageMagick, the resulting image comes out much darker than the original:

When decoding the last step via `djxl` instead of ImageMagick, I do get correct results.

<@557099078337560596> is the PNG darker when viewed in Firefox?

Yep. Same on Chrome.

what about other image programs?

I can't test other image programs right now, but the Photos app in Windows 11 and mpv also show the darker image. You can get the PNG by doing: ``` > wget https://w2w-images.sftcdn.net/image/upload/v1620662834/Ghacks/IMG_20200308_194050.jxl > djxl IMG_20200308_194050.jxl test.png > cjxl -q 88.1 test.png q88.1.jxl > magick q88.1.jxl q881.png ```

I believe this is related to the color management bug in IM

it writes gamna2.2 instead of an sRGB chunk

I can test this when I get back to my computer

Yeah the imagemagick gAMA chunk thing drives me up the wall

I think you can avoid it by embedding an ICC profile

I just tested it, and no, it does not build with JXL support because of the Nightly check. I opened a pull request to fix the issue: https://github.com/WaterfoxCo/Waterfox/pull/2936

> Weirdly, the `image.jxl.enabled` config option is already set to `true` by default in 000-waterfox.js. This means that all Waterfox releases have broken JPEG XL support, since Firefox (and therefore Waterfox) sends the Accept: image/jxl header even if the JXL decoding support is not actually built and present.

At least there is now a test page: https://jpegxl.info/test-page/

Thanks, I'll mention that in the PR.

it will be at the same level as normal firefox nightly until me and demez get around to making a pull request for the unmerged patches

Community builds of stable chromium and/or firefox with jxl enabled by default would be awesome.

Yeah I made that page because I needed something to test my ICC patch on

There is a discussion thread for ungoogled chrome to retain jxl support, but it seems like they won't do it. https://github.com/ungoogled-software/ungoogled-chromium/discussions/2184

I wrote something there, whether it will convince them is another thing 😅

https://www.phoronix.com/news/Darktable-4.2-Released Darktable 4.2 Released With JPEG-XL Support

I like that this is what the phoronix headline chose to highlight

(well, more accurately, that this is what Michael chose to highlight in the headline)

(but you get what I mean)

also The Register, but others nearly ignored the topic - still getting large media coverage could reverse the Chrome decision, at least stimulate a real discussion

pull request made for waterfox https://github.com/WaterfoxCo/Waterfox/pull/2938

I only noticed this now backreading the AV1 Discord (https://discord.com/channels/587033243702788123/615105639567589376/1054587998731247676), but LibreWolf (Firefox fork) now builds with JXL support (but with `image.jxl.enabled` still defaulting to `false`) out-of-the-box on Stable: https://gitlab.com/librewolf-community/browser/source/-/merge_requests/47

Whoa, that's nice

Does anybody know where I can see the issue tracker for Fennec F-Droid? I want to suggest to them too to build in JPEG-XL, so that I don't have to keep Nightly on my Android

Well they have their own significant modifications such as enabling about:config, so I thought there could be a chance they would accept JPEG-XL too

By now the JPEG XL decoding support tracking bug is the most starred issue of status WontFix opened in the last 10 years: https://bugs.chromium.org/p/chromium/issues/list?sort=-stars&colspec=ID%20Status%20Summary%20Stars%20opened&q=Status%3DWontFix%20opened%3Etoday-3650&can=1

Have you tried this https://discord.com/channels/794206087879852103/794206170445119489/1045305064832639106

oh whoops

That chunk can be removed

from the patch file

Merged <:megapog:816773962884972565> https://github.com/telegramdesktop/tdesktop/pull/25572

<:megapog:816773962884972565>

but jxl is very slow to decode for some reason, it feels like 100x slower maybe compiler, flags, debug build, simd not working? and avif decoding is not affected

hmm, yeah, decoding speed on the release build is pretty much like the real one, so debug build is the reason why it's so slow but also, telegram (qt?) doesn't seem to have ICCv4 support

https://twitter.com/unevenprankster/status/1606464959306686464 What exactly is byte stride calculation?

https://www.reddit.com/r/duckduckgo/comments/ztb01i/jpegxl_for_image_search/ "With Pale Moon (which has DuckDuckGo as its default search) now having almost complete support for the JPEG XL image format, and Librewolf (which also has DDG as default I think) building in JPEG XL support into their browser in their next release, would DDG consider serving JPEG XLs in its image search when the user opts-in to it? Currently preview images are served in JPEGs, which JPEG XL can losslessly (i.e. can be reversed back into JPEG bit-by-bit exact) and quickly transcode with an average of 20% data savings. This seems to be a no-brainer to me: both DDG and the user benefit from reduced bandwidth requirements. Hope DDG considers this feature request!"

> Rest assured sticking with QOI, bigger disk space but loads ultra-fast, compresses to ZIP nicely, is all you need omegalul

> Either you output a flat array of size width\*height\*bytes or I'm not using it cause that's just not how the band plays buddy does libjxl use padding or something?

Oh, so that's why I'm seeing more upvotes to my post there lol

Wait, Palemoon now supports full JXL? <@707907827712131102>

Well, outside of HDR of course <:KekDog:805390049033191445>

i'm still reeling due to "compresses to ZIP nicely" somehow being considered a _good_ thing for an image format??

ICC is the only thing left, and I have no idea why it's not working

https://repo.palemoon.org/jobbautista9/UXP/commit/32347f54881ad058afbf83af200e283ee9ea697c

Doesn't work obviously

I looked at other image decoders on how they did ICC, and I don't see how mine differs from them...

Yeah

Are you getting the data icc profile or the original icc profile? You always need the data one for showing the image.

Is it the JXL_COLOR_PROFILE_TARGET_DATA? I'm using it

Here's a build: https://job.tilde.team/palemoon/

It's based on master + jxl-0.7 branch

Make sure to set gfx.color_management.mode in about:config to 1 or 2

Windoze version pls

Whoops, sorry, I don't have a Windows machine for me to compile on :(

it’s because otherwise, poor ZIP feels left out, being valuable only for archiving rather than compression

it’s important to maintain good relationships with your business partners

QOI is more of a team player in this regard

ugh i don't like how the discussion around qoi has gone

it's a very cool project! i've written 2 qoi encoders, it was fun and i probably couldn't have done that for very many other formats. and it seems to have gotten some people interested in compression which is awesome. but i have a hard time really seeing practical use cases for it in production, and a lot of that effort would be better spent on newer formats that are better than "not very much worse than png"

qoi is a nice toy format that is good for didactical purposes. I don't see any real use cases for it though. It has a rather narrow scope (fast lossless 8-bit sRGB with alpha) and it gets beaten by standardized and more generic formats like png and jxl even within that narrow scope.

yeah

it's extremely simple, which I guess is nice if you have extreme limitations on the decoder size — but I don't really know use cases where the decoder size has to be really low but the compressed image sizes can be "quite ok", i.e. somewhat worse than png

did OP file an issue with libjxl or attempt to address their concern in any other way

reminds me of how you can enable gzip on favicons to compress them more efficiently, ico is basically a container for multiple bitmaps

the problem with qoi is that it is typically considered as one single complete format, while it shouldn't be and even the author didn't mean that

it's best understood as a vehicle for making your own image format, as it gives a baseline and is simple enough to tweak by yourself

more generally speaking I have no problem with making my own format, there are some rules of thumb but once you grok them being able to make my own format opens much more possibility

but most people don't seem to think like me

So... container similar to mkv? Or it's more like .tar?

I believe Nigel Tao's QOIR (https://github.com/nigeltao/qoir/) best represents my mindset, but Tao already has an experience with iconvg and wuffs, so is also an oddball out 😉

no, the intention is that you will have a complete control over the format, as you have a simple encoder and decoder

if you look at the career of Dominic Szablewski (who made QOI) he is pretty much an indie game developer, who tend to make many things from scratch

I'm not going to make a value judgement about that, but I meant that if you want to make things from scratch, you'd rather have them simple and flexible

<@707907827712131102> BTW, when Palemoon gets full JPEG-XL support, tell me so I can get the Openmandriva maintainers to add it 👍

We already have Palemoon on OM. We'd only have to add in the JXL stuff.

There is something I don't get though.

Will Palemoon get proper JXL support in its main branch?%

If they wish to build themselves, the build configuration just needs to be sane and the additions made to the build configuration should only be those that are necessary for the target distro

So only use GCC as the compiler, and don't use system libs

If in doubt you can always ask on the forum, just paste the mozconfig you're gonna use and Moonchild is going to check if it's ok to have official branding

OOPS, I forgot I enabled sndio right there lol

It's really supposed to be just a personal build

Maybe I should've disabled official branding

this suddenly reminds me of the old OpenBSD ports controversy with Pale Moon...

Btw there's also a shortened version in the forum: https://forum.palemoon.org/viewtopic.php?f=24&t=26031

New builds at https://job.tilde.team/palemoon/jxl-icc/

This time with official branding disabled to make it clear it's unofficial

ICC still doesn't work unfortunately

GCC compiler lmao. Since Openmandriva uses Clang by default and needs to use system libs, I guess it'll work 🙂

(why?)

I mean, for system libs, that I understand

Clang produced unstable binaries (crashes on startup)

At least it used to

I'm actually considering proposing that we switch to Clang 15 for Linux builds, but I'd like to daily-drive this Clang build first for at least a month

https://repo.palemoon.org/MoonchildProductions/UXP/pulls/2071

https://forum.palemoon.org/viewtopic.php?f=3&t=24742&p=194241

do you know which version of clang used to have that issue?

latest clang tends to be pretty good, unless of course there's horrible UB somewhere that GCC just didn't happen to do weird things with

I found a 2020 thread where someone using Clang said the binary failed to run, but they didn't specify a version: https://forum.palemoon.org/viewtopic.php?f=5&t=24863&p=195234&hilit=clang#p195234

I'm guessing Clang 9 and below don't really work well with our platform

it's also on BSD, so who knows what was the issue 😛

Well this thread also showed failure with Clang 9 on Linux, this time packaging couldn't be done

The point is that the data structures don't require a thicc manual to read. Like Farbfeld image format.

I don't think you need a thick manual to read PNG.

Hell, when I'm not busy with school I'm writing a JXL decoder, and it's pretty straightforward.

QOI is simpler though, no doubt about that. And PPM is even simpler.

There probably is some kind of frontier plot for complexity verses "goodness". With PPM at one extreme, and something like JXL at another. PNG and JPEG probably do pretty well as middle values on it.

*Video standards at the extreme end lmao.

farbfeld is the simplest image format

Doesn't PPM store the image size as ascii?

yep

Yeah... All I can say is, check out farbfeld.

writing a PNG decoder is relatively nontrivial, even if you're allowed to use a library for the deflate (e.g. zlib, jvm deflate, etc.)

writing a PNG encoder however can be done very easily if you're willing to sacrifice efficiency in the name of code size

<@179701849576833024> I actually found an Android application that can handle JXL images: https://github.com/oupson/jxlviewer It'd be so nice if there was a performance counter 😄

oh interesting

I assume ADB can do the performance counter part 😛

<:Poggers:805392625934663710> but not on windows yet https://github.com/telegramdesktop/tdesktop/pull/25623

maybe I can add some code for this 🤔

In the logcat or in an image info window

Yes, that would be great. Also, could you make a similar image viewer for AVIF using the latest stable libyuv, libavif and libdav1d?

I can try, but I don't have a lot of time so I can't guarantee anything

the new version of telegram on PC (windows) now supports JPEG XL (when sent as a file)

does drag&drop work

yes, everything works. and generates a preview that is embedded in the message (telegram API) and this preview is visible on all devices. Works on all JXL art that I checked, but here's an example with a winner in my tg https://t.me/my_content/8395

Well jpegXL->telegram->web preview WORK

animation and larger previews will not work (like for jpeg and png) also this version should bring avif and av1 support (without hw decoders)

animated jxl haha

There is also a Chrome extension: <https://chrome.google.com/webstore/detail/jpeg-xl-viewer/bkhdlfmkaenamnlbpdfplekldlnghchp>

It makes jxl.js generate PNGs from the JPEG XL images rather than JPEGs, which allows for transparency to work.

I suppose that’s fair enough. 🤔

On the Chrome webstore page, there is a tab that says that, I kinda wish the Mozilla page had something like that too.

🫴 JPEG XL jxl.js WASM decoder

Isn’t it more sensible to use a separate extension for that? I feel like most people would be using `<picture>` rather than branching on it on the server. (And it’s also what I think makes more sense in general.)

Though as I said in <#794206170445119489>, I feel like jxl.js should not load the fallback images in `<picture>` while it decodes the JPEGL XL one, which feels kinda wasteful. I’m also not sure how easy (or possible) it might be with the functions exported by the Wasm binary, but it’d also be neat if it could support progressive decoding. I noticed images take a while to show up, so that might help. On the other hand, maybe the bottleneck is processing speed rather than download time, and adding support for progressive decoding might make it take longer to fully load.

It works for me if I disable scripting. I think jxl.js will still let error events fire, and the page seems to be using scripting to detect JPEG XL support, supposedly using error events.

I was looking up how to do it in Firefox. (I use IceCat, which has this feature in the settings page.) You can disable it on `about:config`, under `javascript.enabled`, then once you reload the page, it won’t run scripts. (Interestingly enough, Chrome allows you to change that setting as a permission per site, and it’s kinda unfortunate that Firefox doesn’t have that by default.)

Shopify is already serving JPEG XL when Accept header is correctly indicates support.

Cloudinary too, but only for those who have it enabled (which is not many, since it isn't really worth it as long as the number of clients that support it is very low)

It seems it can be configured in `about:config` under `image.http.accept`. I suppose it might still be useful for Chrome, though.

i added jxl.js to this so it's possible it may conflict

although having the extension brings another question: add code to the website to tell people to get an extension?, or add code to the website that does the extension?

https://res.cloudinary.com/jon/image/fetch/f_auto/http://sneyers.info/jon.jpg

i think the extension would be handy if it can change the accept headers

You can use my Cloudinary account for testing

https://res.cloudinary.com/jon/image/fetch/f_auto/[insert image url here]

That should produce a jxl if the accept header includes image/jxl

And other formats otherwise

I feel like an option is to use `<picture>`. Also adding something that let users know that their browser doesn’t support JPEG XL (with a link that explains what JPEG XL is), in hopes to bring it to people’s attention.

Using `image.http.accept` works for me on IceCat (and likely on Firefox too).

I don’t know how easy this would be to accomplish because the browser starts downloading the images using a preload scanner when it first receives HTML. Unless extensions can hook into this behavior and change it

using <picture> puts it in a weird position. if using <picture>, it means you are able to serve multiple formats, and then you would be able to detect the headers anyway. and by extension it means that there's little to no cost/disadvantage in serving multiple formats

jxl.js uses mutation observers, which I suppose might be delayed compared to how the browser processes it, but it’s about as quick as you can get updates from the DOM, so it might be possible to prevent them from loading (or at least cancel the request) by removing the `<source>` elements appropriately.

I don’t think I fully understand what you’re trying to say. But I feel like it’s generally useful if a URL to an image (at least in general) is able to download the same image regardless of the headers sent. So fetching a `foo.png` URL ough to download a PNG, whereas fetching a `foo.jxl` URL would download a JPEG XL, which allows for people to download images more easily using tools like `wget`, or by manually entering URLs.

in order to serve multiple formats you either convert it on the fly or store multiple formats

for me and I would imagine a lot of others, it's not trivial

I think content negotiation is very often used with CDNs and services like Cloudflare and Cloudinary

Where you can just go into the control panel and click a button to enable new formats

I understand. But at that point, I feel like it’s a matter of “Should jxl.js be used in pages, or through the extension?” rather than “Should `image/jxl` be sent on the `Accept` header?”

Picture tag requires changes to the website source code so it’s not that easy for non technical users

what I see is that if using a CDN/something that deals with the conversion, ~~does using jxl even matter~~does using picture solve anything? if not using one, picture isnt an option

You can implement picture tag without a CDN

You just have to do the conversion yourself, either on your computer or on your own server

that's what i mean by something that deals with the conversion

picture only solves the problem of not being able to see the image

Well, you can also do content negotiation without a CDN too, with something like apache htaccess rewrite

but if you want to receive jxl from among all of the options, the only real way is to always send the accept header and ?not use <picture>

I used "no webp" extension, so it's definitely possible

Content negotiation and picture tag are two different approaches to solve the same problem, the only difference is that does the browser or the server select the correct image format

A lot of stuff can be done both from html side, and from http side. Like encoding, etc.

I think what I'm trying to get at is I use jxl to store less and using picture goes against that

I don’t understand how `<picture>` makes that more difficult than `Accept`. Supposedly, if you want to convert on the fly, you can do so either way. With `<picture>`, when someone requests `image.png`, you can convert from JPEG XL on the fly, but serve it verbatim if you receive a request to `image.jxl`.

it's not that it's more difficult than accept. the conversion on the fly is the same for both, but there's no point

(for me who cares about storage but not about bandwidth)

Converting on the fly is something you generally only do with cdn caching in front so the conversion only happens on cache misses

Well, you probably want to serve a JPEG or PNG fallback for browsers that don’t support JXL or don’t support JavaScript. There’s also plenty of things that don’t support anything other than JPEG or PNG like content management systems and 3rd party services

I understand. But I don’t see how this is an argument for adding `Accept` to the extension. (I can and I wouldn’t mind it, but I’m just trying to understand the point you’re trying to make.)

If you want your content to have a preview image on facebook, twitter or discord you can’t even use a webp (I think) but definitely not a JXL

my point is that if jxl is only ever going to be served by cdns that work by Accept, then doesnt that make it the only useful thing - with the purpose of jxl in this case being saving bandwidth

https://gitlab.com/adhami3310/Converter

I mean yeah, if you want to have 100% coverage, the accept header would be nice to have

But there are sites that use picture and not the Accept header, like https://jpegxl.info

But I don’t really understand what you mean by “saving bandwidth”, are you talking about the user downloading two images or having to store the image in two different formats in the server? <@288069412857315328>

if serving multiple formats, the use case of jxl is the client downloading a (hopefully) smaller file

otherwise- what is the point in serving jxl

The issue with downloading two images is a bug/issue with the extension/library which can be potentially fixed in the future

i'm not concerned about double download

I don’t get it. What are you concerned about then?

I want it to be useful, and I think that it is most useful if it can send the accept header

Sending the accept header would indeed be the way to actually get jxl files from most of the early adopters.

Well, I’ve been investigating sending the `Accept` header appropriately in the extension. Seems it was fairly straightforward! However, it also seems like jxl.js uses the extension in the URL’s file name to determine whether it should do something, which seems suboptimal. Ideally, I’d build libjxl to Wasm myself, and create my own script for it, optmized for the extension’s use case.

Url filename extensions are not reliable. Response headers are what really tells what you're getting.

(just inspecting the first 12 bytes of the response to see if it's a jxl also works)

Many urls you'll get at sites that use Cloudinary will either have no extension or one that is unrelated to the actual file format.

Indeed, that makes sense. For the purposes of jxl.js, it works fine, but not for the extension. The problem is that there is no easy way of intercepting the browser’s request and know what the response headers or first few bytes are. I suppose maybe it could work with a service worker, but I’m not sure if that’d be ideal because it might interfere with the website’s own service worker if it wants to use one.

res.cloudinary.com/jon/f_auto/sample and res.cloudinary.com/jon/f_auto/sample.png and res.cloudinary.com/jon/f_auto/sample.jpg all produce the same response, and it can be a jpeg, webp, avif or jxl depending on what the Accept header says

> JPEG XL is a new image format created by the same group that created the familiar JPEG format. is this actually true?

<@171381182640947200> looks like both chrome and firefox have an API which extensions can use to modify request headers https://developer.chrome.com/docs/extensions/reference/webRequest/ https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest

but for chrome it seems like the API is going away soon and you need to use something called declarativeNetRequest https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/#network-request-modification

it might be possible to modify headers with it also https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/#type-ModifyHeaderInfo

yes. https://jpeg.org/jpegxl/ JPEG stands for "Joint Photographic Experts Group"

i do wonder if anyone in current jpeg WG1/anyone on jxl had their hand in jpeg

where in that page it says that JPEG developed it