JPEG XL

is it reasonably fast in your experience?

Colorspace is also sRGB, so it shouldn't display as HDR anyway

it goes above 1 and into the negatives for wcg/hdr

or are you saying it should be tagged differently to indicate that while still having the same pixel data

Pixel data doesn't matter, the decoder will always output the original color space unless otherwise requested. The input was tagged sRGB, so it's outputting sRGB instead of linear, ect

not sure i'm following the color space is sRGB primaries with linear transfer at least mathematically speaking, that can represent every color with any luminance (as long as you don't run into 16 bit float limitations) when imported into krita this works, it's displayed as a normal hdr image

(and the reason i'm even looking into this in the first place is that windows hdr screenshots use this exact encoding but with jxr, so lossless conversion might be of interesting there since nothing supports jxr)

how does the old libjxl implementation in Chromium handle it?

or does it also handle it as SDR?

is that the same as in thorium? same behavior there, clipped sdr

Apparently my eyes skimmed over "Linear transfer function" and read everything else..

sample file for testing

JXR->JXL works fine, even compresses better nowadays (at least for the images I have)! Sadly I can't share an image here, too large

What effort? Try 8

guess i should rerun my test (https://discord.com/channels/794206087879852103/803645746661425173/1250101680620568727) to see if that's true

assuming i can find the code again

Even effort 9 is hardly smaller e8 - 25581.6 kB (24.674 bpp) e9 - 25455.6 kB (24.552 bpp)

But still 5MB smaller than the JXR

For some images it's within 10% now, standard VarDCT is roughly equal IIRC

What does that mean? I know jxl-rs may not be as fast as libjxl, but 20x slower than AVIF is almost like something went wrong And it seems like the JXL decoder in Chromium does not use SIMD at all

my own build (143.0.7499.40) with libjxl 0.11 is about 4 times faster than the canary one, which is about 2 times faster than my build with jxl-rs 0.1.2 (0.1.3? not sure)

on my macbook it looks fast enough when I go to pages like https://jpegxl.info/resources/jpeg-xl-test-page.html or https://jpegxl.info/old/art/

animations play without stuttering, images load as fast as I can scroll

I'm not sure how Jake's benchmark works exactly, it says 150ms for fox.jxl vs 11 to 12ms for fox.avif

when I try https://sneyers.info/browserspeedtest/ I get these numbers: s.jxl: Decode speed: 179.26 MP/s | Fetch: 1385.60ms | 100 decodes: 182.80ms s8.avif: Decode speed: 487.62 MP/s | Fetch: 841.90ms | 100 decodes: 67.20ms s10.avif: Decode speed: 446.43 MP/s | Fetch: 1671.00ms | 100 decodes: 73.40ms s12.avif: Decode speed: 341.69 MP/s | Fetch: 585.20ms | 100 decodes: 95.90ms s-fd3.jxl: Decode speed: 257.81 MP/s | Fetch: 1084.70ms | 100 decodes: 127.10ms

Huh, I thought progressive loading was hooked up?

looks like it's just showing final groups when they're ready

As a starting point, I think this is solid

iiuc it's rendering only fully loaded area, no eagerness

pass (or eager) progression isn't implemented yet, even if we request one, jxl-rs will always wait for data (for now)

we have alpha, animation, wide gamut, HDR working, and speed is reasonable enough to be usable — at least on a beefy cpu like a macbook I don't notice any issue regarding decode speed. Probably for a low-end phone that might be a bit different.

it does feel quite slow when opening HDR images with higher resolution

if it can improve a bit further in terms of speed and progressive loading by the time it's enabled by default in stable, it will be excellent

how much room for improvement in decode speed do you think there is?

not sure, but libjxl is 1.5x faster for the same image at least

For me the animation stutters on <https://jpegxl.info/resources/jpeg-xl-test-page.html>, and scrolling though the home page is a little clunky, but it works

and I think <@179701849576833024> is planning to further improve render pipeline? 😛

multithreading would immediately be a big improvement for large images for sure

Canary for android cannot get the update soon enough

Wait, it just did

nice

works pretty well, only the animation on the jpegxl.info webseite stutters a bit

...why is this a different color?

anybody else got any scripts to force CDNs that can use jxl to use jxl? I wanna set them globally lol

Same thing for the animation

It's definitely the wrong color: it looks identical to the others in fossify gallery

and it looks identical on desktop

will give it a try

Dice are wrong too

A sign error in a red-blue color component? I forgot what the axes of XYB are

oh damn, saw that golden anim_ico a few times, will create a issue, can i copy your screenshots? or do you want to file chromium issue?

i'm too lazy to file one

i m filing and trying to fix, just wanted to know if it is ok to copy the screenshots

Please take the screenshots for sure 😄

Uh, that's ambiguous

Yes, copy them

Don't re-take them yourself 😅

the animation stutters a bit on desktop as well for me. but colors are indeed correct

done: https://issues.chromium.org/issues/475255735 will work on it tonight! 🙂 stutter/performance, investigating if the simd feature flag helps, but in general performance is a overall topic

the android thing is for sure a bug

Oh, for the record, the 16-bit red image which supposedly has a faint webkit logo that I don't have the hardware to see has the correct color

jxl art is also affected so i would assume it's a red/blue channel swap elsewhere

well that is not enabled, testing if it works once enabled, but we'd need to have a jxl-rs roll for that change

Can take a screenshot, but it would be rather uninformative: 4 red squares 😅 but it might be more useful as evidence than an assertion from a random person on discord

the red one will work once dice and animation are ok - i bet

The red one is already working tho, is what I'm saying. It's red as it should be

(left is the actual jxl decoded by chromium, right is decoded to png via the wasm decoder)

Wait, it's not red for you? Fdkdjg

I'm guessing some device information might be useful, then. I'll be happy to provide it

not familiar with graphics programming at all but RGB/BGR mismatch rings some bells i think, e.g. windows uses BGR ordering as the desktop swapchain format in SDR but RGB in HDR

so i would assume that some layer expects BGR but receives RGB instead (or the other way around)

that wide gamut image is red for me too

Ah ok, great

You need a Firefox extension that modifies "Accept:" header for images, you need to set it to just "image/jxl". Expect a LOT of broken images if you don't accept jpeg/png/gif, tho

the hdr images have the right channel order but don't actually seem to trigger hdr? ultrahdr images don't work either, so either something's wrong with my phone or with that chrome build

Why would that need a jxl-rs roll? Can't it just be enabled on the Chromium side instead of jxl-rs making it a default feature?

indeed I am, but that code is scary 😛

the guardian doesnt serve images with jxl on, could it be an issue with how theyre served? pngs and jpgs identifying as jxl or something (canary7632.0/windows). pretending to be another format is a widespread webdev practice, could be worth checking nintendo.com's images when format is manually set to jxl show properly and are correct (generated by cloudinary)

<https://github.com/MishaalRahmanGH/Ultra_HDR_Samples> do these images trigger hdr on android chrome canary for anyone? they work fine on regular chrome for me on android and desktop, and canary desktop too i'm confused, on chrome dev hdr doesn't work either on my phone

fwiw conversion to f16 (which HDR uses) is much much slower than it needs to be

that does smell like some RGB and BGR swap somewhere

what's your OS?

android 15 (hyperos 2)

huh

ok, no idea what that does

Yeah broken for me on Chrome Canary for Android as well

any idea how i can bisect which build broke hdr images? (without building chromium myself)

apk mirror ig

I mean so would progressive loading if the overhead wasn't too high. I did wake up with a thought this morning about the difference between Pass and Eager modes Currently libjxl behaves like Pass and Oxide like Eager (I assume), with only the latter rendering ProgressiveDC. What if the LF passes were included in Pass mode too? Possibly for libjxl as well. Eager could still render partial LF scans of each horizontal or vertical step/incomplete data, but then for a 4K image Pass gets 9 half-res steps instead of 3 (Even if I think Eager should be default, especially with progressive AC on the chopping block which would make it 2 passes vs 8) Pass example (7.5%), Eager example (12.2%), currently libjxl only renders LF with 2-3x the data (20%), jxl-rs renders a HF block with 6x the data (48%)

Here's the test file if people want to mess with <https://google.github.io/attention-center/> and https://jxl-oxide.tirr.dev/demo/index.html

yeah, but there are actual scripts that redirect cdn requests to jxl ones

Android 15 here too, OxygenOS 15.0, security update from November

example https://discord.com/channels/794206087879852103/806898911091753051/1275684586482827330

I'm getting them but they don't load

dumping surface flinger would prolly tell us

<https://i.guim.co.uk/img/media/d69b01902eb4ca9d4c0c224c16bf7649949fe362/109_2793_582_465/master/582.jpg?width=220&dpr=1&s=none&crop=5%3A4>

Huh, <#805722506517807104> missed this one... And the deleted post is still in the channel <https://www.reddit.com/r/jpegxl/comments/1qbcqnp/chromium_has_merged_jpegxl_support/>

Interesting RGB / BGR swap there

I suppose an endianness issue? one thing sends/expects big-endian RGBA and the other thinks it's little-endian ARGB or whatever

someone from the guardian is in this discord, perhaps they can chime in (paperboyo?). assuming they serve jxl fine to ios, perhaps its not an issue with the images

do we have to enable flags for android?

i had to i think

yes

tried to set up the chromium bisect script but it says it can't find adb... despite `adb.exe` being on my PATH

only an Origin Trial force-enables it for a predetermined list of participating websites

The MIME is detected correctly in the network inspector, but maybe it's still going to the wrong decoder

guess i found the android fix! trying to launch that damn emulator 😄

surface flinger only sees rgb layers, no bgr

what was? ~~also this is why I use Waydroid or bliss~~

on android skia handles rgba vs bgra differently

interesting, I didn't are any bgra layers at all in surface flinger so I guess its an in app issue? in that case I don't see why it would be different... weird

unrelated but libraw finally shipped 0.22.0 featuring dng1.7 with jxl for real this time

If Chrome is looking for a guinea pig to do an Origin Trial for jxl, I can probably safely say that Cloudinary is still interested

I tried the image with jxl_cli, and that's https://github.com/libjxl/jxl-rs/issues/609 So I guess we do need another jxl-rs roll

*pending approval my the relevant decision makers at Cloudinary

"a guinea pig" made my day ❤️

A fresh release would also bring fast lossless more in-line with libjxl

ready to roll all day long 🤘

Also I think it should show the broken image icon instead of just blank when decode failed

can't run the chrome bisect script (for android) on my linux laptop either... somehow that also can't find adb despite it very clearly being on my PATH

finding sed adb with adb.exe?

by the way, if someone felt like picking up some of the PRs by lillith it'd be much appreciated 👀

maybe I can take some of those if nobody came up until weekend

no it just doesn't find any adb executable on either windows or linux. thought windows was broken because it looks for `adb` rather than `adb.exe`but now idk

did somehow get it to work on my laptop now though, no idea what made the python errors go away

what do you get with `which adb`?

i solved it not finding adb and aapt by hardcoding the paths in the scripts already, still had weird python errors after that

i think somehow uninstalling chromium from previous attempts made it work now?

idk weird stuff

hm, weird indeed

it's definitely working now though, it's giving me some broken and some working builds

Heya. Yeah, just checked: Thorium and Safari fine, Canary with a flag indeed nope. Accept header is correct (the same), so not sure what’s going on (progressive options? although jxlinfo doesn’t print and our CDN in control of these, IIRC, they `-progressive_ac: 1 -progressive_dc: 1`, but not sure). Have to run now (still on holidays), but if you determine it’s on us, will try to get help. Also, massive thanks to Helmut and all! HNY.

See https://discord.com/channels/794206087879852103/803574970180829194/1460656341025554542

bisect (for hdr not triggering on android) gave me this: https://chromium.googlesource.com/chromium/src/+log/45baec6f3e152fa5e8c67fa7a65d69caf57a7d67..dc8611db7fbba200d23580ac1635fe189bf65036

145.0.7572.0 should be good and 145.0.7573.0 should be bad, will verify that again just to be sure 7572 doesn't work now.... guess i have to bisect again

android CL: https://chromium-review.googlesource.com/c/chromium/src/+/7459081 - phy. verified 🙂 lets hope!

if anyone is crazy enough to use a internet-guy-distributed APK - DM 🙂

https://issues.chromium.org/issues/475475547

if anyone here wants to figure out what broke hdr on android

ohhhh no - hope this is not because of jxl?

seems unrelated to me but idk

nothing in the bisect output seems to be related to jxl

(it does affect jxl hdr images too though)

still not entirely sure if the bisect output is correct, when i verified it using the build numbers (e.g. `1556473`) it gave me it worked, but using the build versions (e.g. `145.0.7572.0`) just gave me two broken builds and then it errored out

just looking at the list of commits, https://crrev.com/70e3639b7ac8c7acb5b3479249192ecb47c43771 looks like it could potentially be the culprit

is that `ProtectRecentlyVisibleTab` feature something i can disable?

i think i passed the flag to disable it but it didn't do anything

could be this? https://chromium.googlesource.com/chromium/src/+/065eeb23d3188413976d97d380582efd92485f35 it does *something* related to hdr metadata

oh, yes, could definitely be it

is this all googlers here? or is just everyone firm with chrome?

and btw whenever i stumble into any discord i really feel old! everything blinks🤪

lots of googlers in here

several non-googlers who use chrome

and a few of us who use firefox :v

Core devs are mostly Google with Jon from Cloudinary AFAIK, those who worked on the spec/libjxl Devs are users of libjxl in their own applications or creators of other implementations. Oxide, Latte, ect The rest of us are just fans and nerds

Though now that I mention it, maybe Paperboyo, hjanuschka, me and ahomosapien should have the dev role too? Paperboyo got The Guardian to serve it the past year and the rest of us have made a lot of commits to the repo

Thought I'd give faster decoding a go on a lossless 4K image, even without the fastpaths in a release yet `cjxl -d 0 --faster_decoding 0 (4.247 bpp), 1 (4.260 bpp), 4 (4.735 bpp)`

Nearly 4x faster, not bad

not sure I understood what you compared

Flattered, but I’m no dev: would barely trust myself with a melody watch… I only make Puss’ eyes to devs. Current status: making Puss’ eyes to JXL devs to get better at low bitrates:

Effort 7 lossless, faster decoding levels 0 (So normal), level 1 and level 4

on jxl-rs?

Yeah, on Chrome Canary

ah I see

that's without fast paths, right?

Yep, without this PR https://github.com/libjxl/jxl-rs/pull/600

(I'm assuming it gives similar results as the original closed PR <https://github.com/libjxl/jxl-rs/pull/598>, which those results are from)

PNG was 111ms for comparison, so 5x slower at half the filesize, should hopefully go down to 2x slower or less with the PR

how would i even go about testing this on firefox (when the time comes if it is not here yet). i prefer it over chrome/chromium

waterfox has complete jxl support on desktop and android (base nightly's with the additional patches). based on libjxl

https://bugzilla.mozilla.org/show_bug.cgi?id=1986393

The timing on getting jxl in Chrome Canary is impeccable, it is JPEG meeting week this week and the midweek plenary is about to start.

haha

I can confirm the BGR - RGB bug on my Android phone (Motorola edge 60)

it's fixed, if you dm me i can send you apk with fix - https://chromium-review.googlesource.com/c/chromium/src/+/7459081 does it!

same on my pixel, fwiw 😄

I like this example because it's not very obvious something is wrong at first glance. it's just different dice with different colors!

and then it is super obviuos and a great showcase of whats wrong too 🙂

https://github.com/hjanuschka/chrome-apks/releases/tag/v1.0.0-jxl-android fixed apk

Did a very rough test of decode times with resampling to emulate rendering a lower res pass. 19MP/s for full, 54MP/s for 1:8, so I think progressive loading could outweigh any slowdown compared to AVIF normally

i wonder, since discord is built on electron, which itself is built on chromium, how long would it take for support to bubble upwards once jxl becomes part of stable builds of chromium?

i can see discord wanting to make an effort to get support for it on the faster side, due to the sheer amount of images being posted

They should reopen this issue https://github.com/electron/electron/issues/43993

do they even need to do anything for this?

like I'm trying to see if some code or component of it has a manual list of things recognized as images and I don't see anything

I think this might be one of those things where they don't care to do anything and also don't have to do anything at the same time

Doesn't discord use its own stack for image processing https://discord.com/blog/modern-image-formats-at-discord-supporting-webp-and-avif

support needs to be done on both ends

Yeah didn't it get added to discord like 4 years or so after it got added to electron/chromium probably gonna be a while

if you can even call it support

Assuming nothing breaks, 2 months until the flag is added to Electron. But it'll still be relatively slow to decode

Interesting <https://www.cast-inc.com/compression/jpeg-image-compression/jpeg-xl-e>

on chrome, 145 is the upcoming beta, meaning support behind a user-switchable flag could reach stable in as little as 2 weeks

on origin trials, shopify might be worth poking since they supposedly had the support and images ready for shopify-powered sites since 2022 - pretty diverse selection of high traffic domains sensitive to performance

wonder what's so different between the Altera and AMD impls

> sensitive to performance Given the SIMD commit and the BGR fix aren't merged, I'd almost say that's a reason trials should wait until the next release. We don't want to enable it for everyone just to get told it's broken

my personal guesstimate is that we'll want to wait for 147

(not because 147 is special, but to optimize things well and not rush too much)

As far as I can tell, nothing. The docs are just worded differently to fit their terminology

yeah could be that they have a very different "DSP element" that causes the ~1.7x

Maybe they can be cherry-picked to 145 once merged Chromium allows "Non-functional issues for Finch-gated features" to be merged in beta, I'm not sure if those meet the criteria

Actually it's already requested https://issues.chromium.org/issues/475899040

Ah good

i bet that all 2 merge requests will make it 🙂 - simd is still in review! (but i'd try to merge that too; not sure though if that would qualify)

Dankeschön.

anyone is having a idea about the firefox status? the phabricator UI is crazy my mind explodes while trying to understand whats the current state 😄

I think the patches for adding in jxl-rs are waiting to be reviewed

as for the current libjxl implementation in the codebase it's completely abandoned and they will not accept patches for it

a few hours ago some of patches related to the jxl-rs implementation where marked as "obsolete" which I'm not entirely sure the purpose of

I think that's because updated patches were uploaded

ah yeah that seems like what's happening

Could just be my weak CPU, but on Canary I can see the animation at the bottom hangs for a frame whenever it loops, making it slowly drift out of sync with the others <https://jpegxl.info/resources/jpeg-xl-test-page.html>

https://jsfiddle.net/z78kunc3/ This is more noticeable

I noticed that too on my m4 mac

so i doubt it's a cpu issue

we have a change open, that enables simd stuff in rust, current canary is without, i think it is the main reason

<@238552565619359744> is it also drifting when you directly only, open https://jpegxl.info/images/anim-icos.jxl in a tab?

and with drifting, you mean it drifts away from webp, apng and gif? for me they all are not 100% in sync

<@623776984987729940> I don't think it's rust version specific, I have the syncing issue with the abandoned libjxl patch as well

animation is crazy or atleast its driving me crazy (or it drove?) 🙁 https://github.com/chromium/chromium/blob/main/third_party/blink/web_tests/images/resources/5_frames_numbered.jxl that is a great test file 5 frames counting numbers with stable duration

Left: 145.0.7632.0 Right: 146.0.7637.0

The animation issue still persists though

simd! 🙂 animations 🙁

3x speedup, not bad

(was hoping for more :P)

should we try to merge request into 145?

SYN+ACK

doesn't chromium do ""LTS"" releases every other release? in this case is 145 or 146 considered an LTS release?

if 145 is considered LTS then yeah it might be worth it to try and get SMID pushed to it

any doc/reference where it says that 145 will be LTS?

would be a great line for the merge request

ah I just checked and it seems like 145 is not considered an LTS release: https://chromiumdash.appspot.com/schedule EDIT: I guess they call them "Extended Support" releases which makes more sense then "LTS" since it's not really long term

still going to try it, worst case it's rejected

will upload your performance screenshot

That's on x64 (Windows) btw, if any one want to test the improvement on arm can use the following link https://storage.googleapis.com/chrome-for-testing-public/146.0.7637.0/mac-arm64/chrome-mac-arm64.zip

TIL arm64 builds! does it include widvine and is a release build? 😄

It's from https://googlechromelabs.github.io/chrome-for-testing/#canary the page is not updated yet but it's already built

I don't think it's too important to merge the speedup, fwiw

it's not broken, at least

think i found the drifting, will give it a try

anyone with drifts, able to run a CL locally? ( https://chromium-review.googlesource.com/c/chromium/src/+/7484708 )

works on my machine, but my machine runs in the cloud via crd, and always works, or lag's - that's why i might have missed it (or because i am not one of you math folks) 😄

I don't think it's due to precision tho, you can tell the duration of 2 is very short

Oops, it seems the screen recording messed it up

So I measured the time, for some reason 2 only last 100ms while other frames last 500ms

Intriguing

<@604964375924834314> do you have any thoughts on whether linear hdr like ^ is expected to work?

I tried to make it work some time ago but with the way Chrome’s pipeline worked, at least at the time, I couldn’t find a way to make it work satisfactorily on both Windows and macOS

but I don’t remember the details

ah, some WIP here https://crrev.com/c/3483826

as you can see, it was a while ago

I think I found why it's 100ms https://issues.chromium.org/issues/41015120#comment7 The decoder probably returned 0 for that frame

This also explains the shift of the other image, which has a < 100ms duration, so 100ms will make it look slower instead of faster

can you check that with jxl-rs directly?

Interesting, I got 33.33 ms duration for the first frame (rest are correct) using jxl_cli (decode to APNG)

... surprising

think i found it!

After looking into it I think jxl-rs correctly decoded the duration, just didn't write the first frame's duration to APNG [`set_frame_delay`](https://github.com/libjxl/jxl-rs/blob/7c74207e5cff878951f9fd3648d293a19291a607/jxl_cli/src/enc/png.rs#L209) should be called before `write_image_data` And the 33.33ms I got is clamped by ffmpeg

anyone wanna try the CL again?

(gonna put, jxl-animation-survivor on my linkedin; once its actually working!)

https://chromium-review.googlesource.com/c/chromium/src/+/7484708

if it works, i am polishing it 😄

would be nice, if a non-remote-desktop person could test it

If only the compile didn't take an hour every time

https://tenor.com/view/troopers-responsible-helpful-doing-my-part-gif-11496062726020391529

bug1: Duration precision loss bug2: FrameDurationAtIndex() was reading from wrong source bug3: Frame durations not available when animation controller requested them

can you file an issue or ideally send a PR? 😄

Sure, I'll try this weekend

thank you 🙂

whats the best way to test canary on arch? Ideally I don't want to compile but will if I have to, appimage or flatpak would be more ideal

interesting that cloudinary defaults to webp instead of avif if avif is missing from accept header, is this a client config issue?

I'll rerun my faster decoding tests later, might do a bit better

https://www.google.com/intl/en/chrome/canary/?platform=linux only .deb or .rpm packages, but many things on the AUR are .deb so it should be good to use

(not chromium I know but at least you don't need to compile)

oh wait, there's `google-chrome-canary` on the AUR, which uses the .deb package which has version 146.0.7637.0-1

here is canary (my local) build including the animation fixes and all the jxl stuff (android RGB): https://github.com/hjanuschka/chrome-apks/releases/tag/jxl-animation-fix-test if you feel comfortable running internet-guy's binaries, i am happy to hear if all is good now (drifting, colors on android)

those are static binaries, should work on all (almost) linux's

about canary, it might be outdated, as my HEAD is different, but it has ALL latest JXL work

arm64: no netflix and chill, it does not come with widvine

~~this is where I pester about riscv builds obviously~~ I have no qualms running the linux builds and android builds in waydroid

oh I need to re-init it

all looks good on desktop

hooray! thanks for testing!

hmmm,. thats weird, this build isn't working in waydroid for me, maybe it's incompatible with libndk? odd issue

never used waidroid tbh

really odd, ill play around with this

it's a bliss labs project to run android in a LXC container with wayland windowing, kinda akin to chromeOS

only supports linux

hm try the full url?

including https://

I've had this happen in ungoogled chromium

no urls working at all, first ive seen of this issue, im assuming its an emulation error but it's not working on libhoudini or libndk

oh wait that's a tab crash not a network error yea

not even chrome://flags works lmao

its working fine on my phone tho so its all fine

works fine on my LOS android phone 👍

did you specifically test for the animation timing/sync issue? that's mainly what these builds are for AFAIK

the animation looked fine but are there many other sites to test?

thanks, and also the https://jpegxl.info/resources/jpeg-xl-test-page.html dice has correct colors 🙂

(think thats confirmed, but asking anyway)

Currently doing a more in-depth benchmark before updating Canary with the SIMD fix, hoping to see some higher improvements with a wider test set

thank you <@238552565619359744>

really excited!

yeah it does have correct colors for me

Hmm, not quite as exciting as I hoped, but still 20% faster for lossless, 2x faster for lossy and 6x faster for upsampling. Not bad for a decade old CPU

not yet sure what we are aiming for, but its an improvement 😄

still excited

simd tends to help vardct a lot, dct algorithm is heavily simdified

Forgot to add the progressive AC command (Also damn Discord lags when I type)

progressive lossless will also show the difference I think

and there is still some optimizations in main that are not yet rolled into chrome: https://github.com/libjxl/jxl-rs/compare/v0.2.2...main

Not sure how I forgot that... Third time's the charm, now with the image resolution and the after result for progressive lossless

Good point, with the fast path commits merged lossless should be around 2x faster than lossy (I think...)

https://googlechromelabs.github.io/chrome-for-testing/#canary

no autoupdating, handy for testing or comparing multiple specific versions

recording of this builds

taskset to 1 thread also seems fine

Weird that GIF was out of sync for you, but looks fixed

yeah

Did a quick test, for now it's still 14% slower than Oxide and libjxl, sitting between normal lossless and FD1. Progressive plus FD4 puts it between FD3 and FD4 (With pending commits) around 30% slower than libjxl and 53% slower than Oxide Very rough testing showed the decode time increase by 100ms per 10% of a 4K file loaded, so the earliest progressive steps would also be the cheapest to render, slowing down as the passes get slower to load too

could I ask you for a summary of memory usage / speed of libjxl/oxide/rs for a bunch of relatively common files? 😄

That depends on what counts as 'relatively common'

I could run those same files again as a start

yeah that'd be a good start

The speedup of neon is a bit smaller than avx2, got ~2.5x

YOOOOOOOOOOOOOOOOOOOOOOOOO Latest version of Chrome Canary has a feature flag to enable JXL image format to the accept header and enables decoding 🚀

Shit am I late? hahaha

welcome to the party

also works in beta, release on 28th: https://chromestatus.com/roadmap

A bit late, but hopefully this helps. Can add more later

yes looks fixed! CL is landing

Oh neat <https://docs.cloud.google.com/release-notes#December_22_2025>

Looks like more work is still needed 🤣 I'm surprised jxl-rs always uses more memory (if I read this right), but I guess it's good because it means there's more room for speedups

also very curious how jxl-oxide uses so little memory sometimes 😄 <@206628065147748352> ?

I guess it's i16 buffers, not sure

jxl-oxide never allocates i32 buffers (even for final output) when it's possible

yeah that would do it

I did consider setting djxl to output 8bit, but I thought it'd be more fair to leave it on default to match jxl-rs

Oh, also in a quick test I tried using --high-precision and it was actually a little bit faster than default

do set it to 8 bits

(or 16 for hdr)

Both djxl and jxl-rs I assume?

djxl at least, jxl-rs is not very good at outputing non-f32 yet xD

(but it will be)

speaking of jxl-rs, what's the current planned priority list between progressive decoding, multithreading, and low memory buffers? I'm just curious as to what we can maybe expect being done first and such between those 3 main things.

I am working on a somewhat big change to the low memory pipeline

which should reduce memory usage significantly

YAY

memory usage is one of my biggest issues with jxl ecosystem rn

then at some point I might also do the f16 thingy

but we'll see when

Here ya go djxl, djxl set to 8-bit, Oxide and jxl-rs with PeakWorkingSetSize next to MP/s

is that on windows?

Yeah

good to know, thanks 🙂

Just tried it in Canary, works fine now after playing for a few minutes

really appreciate the confirmation!!

Hmm, it seems this is also fixed in 7640 but I don't know why

https://www.shikino.co.jp/eng/products/product-ip_core_products_1.php They updated their website with some more info on the jxl hw encoder

Inteeeresting, the q100 comparison is a bit vague, since they make lossless JPEG encoders too but the JXL core is lossy only. Smaller encoder size is great though

For now, thanks to the required buffering https://discord.com/channels/794206087879852103/794206170445119489/1460988956320596090, the HW encodes should actually be more progressive than libjxl's default (Test encode of `cjxl` vs `libjxl-tiny`)

my god....

people really don't know how to measure differences between codecs, pretty sure they just did -q {quality} and measured the resulting size

happens a lot

with cjxl and jpeg it's not *too* stupid though, the q flag is tuned to give roughly the same quality as the corresponding libjpeg-turbo flag or better

Not sure what q100 did for JXL though, since it can't be lossless

And well... It used to be tuned, the distance/real quality has drifted with all the encoder tweaks since v0.8, usually undershooting or overshooting 90 SSIMU2

since v0.1

no idea what they did there, pretty sure that this "Quality" scale is just some internal parameter of their hw encoders, which probably has little to do with the scale used in e.g. libjpeg-turbo or libjxl. They probably made q100 whatever the highest lossy quality is they can still do in their fixedpoint implementation of jxl without running into precision/overflow issues (which I think would be something like libjxl-tiny d0.05), while in jpeg it's probably just quant tables that are all 1s.

do we have any files/examples from the output of their chips? I know it's *based* on libjxl-tiny but it would be nice to have actual real output(s) to inspect and mess around with

yeah, no, I don't have any actual bitstreams from them. If someone has an FPGA available and wants to do some testing, probably it shouldn't be too expensive to get a license from them for just a single instantiation of their codec for evaluation purposes. Though these hw design companies are pretty secretive and may not be interested in letting folks test their stuff; they want to sell this thing to camera/phone manufacturers and other companies that produce devices that may want to have a jxl encoder.

could probably just reach out to them for some sample files 🙂

I do have an FPGA, but I don't know enough how to use it yet-

Am I misunderstanding the BSD-3-Clause license which both libjxl and jxl-rs use? Affinity and Chrome Canary do not have the license notice included for the respective libraries in their distributions

potential adoption for upcoming epub 3.4 spec. Anything useful to them to know before their WG call, link below

https://github.com/w3c/epub-specs/issues/2896

on an aside, epub ebooks are mostly consumed on software that will also read pdfs, so it would be jxl-capable regardless of wether epub spec is updated to standardize its use. in-browser decoding is trending up so browser adoption of jxl could help

enabling the possibility for existing epubs using jpgs to be *losslessly* converted to a newer revision would be big imo. generation loss there is bad since conversions from the og source tend to sacrifice even more quality to shrink filesize, especially from other ebook formats

Yes this is my personal goal with JXL in EPUBs, because there are millions of EPUBs already out there with jpeg, especially comics/manga, with mediocre jpeg quality levels. losslessly converting to JXL is about the only way possible to further optimize those files, and you’re never going to be able to go back and get a better release from the publisher

Since ereaders won’t support jxl for years, my first goal is on-the-fly re-encoding to JXL before serving to “streaming” clients like web browsers

I left a comment raising those points, hopefully it helps

Yep every comment helps. I'll try my best on the ebook production side and streaming code, though realistically it will take many years before it becomes mainstream

WG discussed, transcript in issue. to be honest, webp didnt make sense. *jpegli* wouldve significantly improved the use of the original jpeg, even pdfa recommended vendors upgrade their jpeg codecs since itll still be a popular image format for maximum backward compatibility even for ebooks created in newer pdf specs

a transition to newer spec revisions doesnt require use of newer image formats or fallbacks, just swapping or upgrading core libraries is already an improvement

japan is interesting cuz jxl had almost 34% support on mobile there from just iphones/ipads. Any examples of legacy devices or web services in use there? I thought vendors offered multiple formats for ebooks to cover all bases

is there anyone from akamai in this discord or the jxl wg? part of the reasons i want first class chrome support is to get my company to use it and reduce bandwidth. but we are basically using akamai image manager 😓 which is a great thing but misses jxl support - would love to talk/work on getting it into akamai. my contacts(support) are just too far away from the product

so if anyone knows someone - send them my way please!

Isn't Akami the same one Steam uses? I'm fairly sure it's a reason they haven't updated formats too

Cloudinary uses Akamai (amongst other cdns) to do the actual delivery. It is a bit complicated how Cloudinary is at the same time a big customer of Akamai and also a competitor with its image manager product.

we are largest austrian (or second; maybe redbull is larger) customer of akamai, yet i failed 2 times getting them to take a serious look at jxl (but as before; the contacts we have are at the wrong level i guess). trying to get others from the publishing industry to "ask" too. as it would be super beneficial in terms of bandwidth reduction.

~~sounds like it's time for a good old spam campaign~~

<@623776984987729940> switch to cloudinary? 😛

thought of it, but well that akamai contract is not easy to get out or to change!

wonder if we could do a origin trial, using cloudinary, in case of JXL enabled, but we use a few features from image manager, where i am not yet sure how to port to cloudinary

we need to make akamai support it, that would be a huge upllift in the industry!

Steam is using Fastly recently and delivering AVIF in many places instead of prior PNG assets. They also used Cloudflare, but I do not remember format changes at that time.

Well that's good news for <#1284444511375855667> https://www.fastly.com/blog/level-up-your-images-jpeg-xl-now-supported-by-image-optimizer

those graphs look so messy...

```For JPEG XL images, we use encoding effort 3 and 4 threads. For AVIF images, we use chroma subsampling (422) to achieve smaller image sizes.```

Riiight, moving on kek

draft up for epub 3.4 with jxl as a proposed core media type

anything worth mentioning on the subject? I noticed its rare for sources and stores to mention epub versions but I suppose adoption of newer revisions lags anyway so it wouldnt be an issue

for context on japan. it produces and sells a *ton* of light novels and it seems epub suited that market better since reflowable and features relatively few images (handy to consume on web, within official apps and on e-readers)

to be fair, with the sheer amount of images they handle, encoding compute adds up quickly

I'm guessing effort 3 was an economical choice, balancing encoding compute costs and image transmission bandwidth costs to be the cheapest, everything considered

I assume there's a small percentage of images that gets a large percentage of views, so they might want to spend more encode compute on those popular images to further optimize total costs

https://github.com/w3c/epub-specs/pull/2899

Effort 3 is essentially just XYB JPEG though, only Effort 5 actually uses adaptive quantization and VarDCT

I thought that's what effort 1 was

jxl-rs v0.3 is in current canary

nice, mostly speed improvements I suppose?

yes

hate discord, trying to find the benchmark website thing that did the 60 iterations 🙁

but search here is basically broken

What's the status regarding progressive decode? currently it looks like we only have full group rendering? https://google.github.io/attention-center/

That's because it is, though the idea of implementing libjxl-tiny as effort 2/3 has been brought up before

Yeah, only finished groups work currently https://discord.com/channels/794206087879852103/803574970180829194/1460625531710996591

what's preventing showing at least the LF when it's available?

(I'd personally also like to see even earlier previews of LF frames that are still incomplete, since then we can show something like a 1:16 or 1:32 image very early and clearly be better than progressive jpeg; with just a first render at complete LF we don't really beat progressive jpeg)

iiuc it waits until all dependencies are available for the region, but maybe <@179701849576833024> knows better

guardian displays all jxls correctly in chromium canary 146.0.7651.0 so far <@810102077895344159>

Here ya go, it was in <#822105409312653333> <https://random-stuff.jakearchibald.com/apps/img-decode-bench/>

thanks 🙂

gonna bookmark this time

fox.jxl: Iterations: 50 Mean: 79.00ms Median: 77.65ms Std Dev: 6.68ms Min: 73.50ms Max: 111.10ms Total Time: 3950.20ms fox.avif: Iterations: 181 Mean: 11.08ms Median: 11.00ms Std Dev: 0.63ms Min: 10.30ms Max: 16.60ms Total Time: 2004.80ms

unreleated, but chromium has an odd save behaviour for images pretending to be jpg. right click save=jxl but ctrl+S=jpg

I got 150ms for fox.jxl last week so it's twice as fast now for me.

It'd be cool to finally see it live in action, and would help hide any decode speed issues we still have since rendering seemed 'free' in my tests (Using Helmut's [jxl-ui](https://github.com/hjanuschka/jxl-ui)) More importantly though, it would make progressive lossless images functional. Right now they only work with jxl-oxide, and I think only the WASM demo uses it's progressive decoding AFAIK

Mozilla said it would only accept "performant" decoder for Firefox, what are the exact requirements? Is 7 times slower than AVIF acceptable to them?

I assumed that if picture is loaded too fast browser does not bother with progressive, and prolonged decode time for hi-res images does not trigger rendering progressive steps if image is already loaded. Is my thinking wrong?

😱 just keep in mind jxl-ui is a fun thing! dont take anything there serious

Hence hiding the issue, it's a lot more responsive to get a preview instantly than block by block or nothing at all

I suspect it didn't send the correct accept header when using ctrl+s

I was comparing the UI's progressive rendering time against the CLI's execution time, they seemed identical after numerous runs on large images, so the cost of rendering the progressive DC/lossless steps should be minimal

A while ago we wondered if browsers could add a flag to control the progressiveness, defaulting to Pass but giving the option of Eager Going from ^2 DC/lossless downscales and HF groups (So the image doubles in resolution to 1:8, then centre_loads HF groups in a spiral), to updating on every frame and showing partial groups/squeeze steps like jxl-oxide (Showing each horizontal and vertical squeeze step with individual HF groups loading in top-to-bottom) It might just be a dream, but I wanna see all the format has to offer haha

If that sounds like too much for Pass, maybe an extra level would be useful ```Rust pub enum JxlProgressiveMode { /// Renders all pixels in every call to Process. /// (Partial squeeze steps/LF frame, partial HF/Lossless groups) Eager, /// Renders pixels once LF steps and group passes are completed. /// (^2 squeeze steps/1:8 LF, individual HF/Lossless groups) Groups, /// Renders pixels once passes are completed. /// (1:8 LF, HF passes, Completed Lossless frame) Pass, /// Renders pixels only once the final frame is ready. /// (Completed HF/Lossless frame) FullFrame, ``` Hopefully you get what I mean

I’m a bit confused by this statement. Light novels have way more images than your average novel, and the images are also expected to be much higher fidelity. And the reason why Japan uses EPUB is not really because it “suited” the market, it’s that they got tired of dealing with the proprietary formats like XMDF that needed proprietary software and high licensing fees, plus the major ebook distributors basically require EPUB at this point

that was just my educated assumption, not cold fact

the main issue for progressive is that I have not been thinking about it yet 😛 (I want to optimize the pipeline more first, and get non-progressive rendering to be fast, and get multithreading working before doing better progressiveness)

The main thing holding back Japan specifically from evolving their EPUBs support to e.g. more modern image codecs is because their distribution system involves just about more ebook stores than any other country in the world. For a new format like JXL to take hold, over 50 stores would need to update their pipelines, and they have some amazingly legacy stuff going on internally. There are also 5+ major proprietary processing solutions these stores use (along with their own homebrew) that would need to cooperate

Also, unlike most “western” ebook reading solutions that rely on the platform’s own web engines (which have or will soon add JXL), Japanese systems tend to either embed their own custom (typically outdated) WebKit build or convert to a proprietary format before delivery

an optimized render pipeline benefits both progressive rendering and non-progressive rendering since that's basically the same thing, just using zeroes for the missing coefficients. Only exception is the fancy LF upsampling but that's not strictly necessary (you could also just show a blocky image when only LF is available), and of course it does make sense to skip IDCT when there's no HF available anyway. Would Chrome use multithreaded decode?

I am definitely going to try to do so

jxl benefits from threads more than avif, at least 🙂 (smaller blocks)

That's assuming browsers give it enough threads to work with, I know someone said AVIF is limited to 2 threads in Chrome

that was because they didn't see it giving improvements with more

Ah right

Was it? I though it was images are not expected to consume all the resources, that's why they created animated WebP instead of supporting WebM in <img>

I mean, the occasional 4K GIF I stumble upon still brings my system to it's knees with only 1 thread

It would be nice if jxl-rs can do multithreading based on image size, libavif was not able to do that because they can't get image size before setting thread count

I like that idea, It would probably help to some degree with preventing thread starvation and thrashing

not sure what the benefit would be

Chrome has its own threadpool anyway

I'm a little unfamiliar exactly with how threadpools work but wouldn't there still be a benefit? say there's a page with a bunch of small images and a very large image or two wouldn't it be better if more threads where working on the larger images from the start rather then having to finish up with the small images before getting put towards the large images?

maybe browsers should also consider the amount of images that are to be decoded. e.g. if there are many images that want to render concurrently, just do one thread per image. if there are just two images that are pretty large, give each of them some threads. I'm not sure how bad it'd be, but I feel like the increased context switching the CPU has to do if you have e.g. 8 logical cores, and 8 images with four blocks, for a total of 32 threads active, would lead to it being less efficient than if you just gave every image a single thread?

Thread scaling with JXL is pretty linear, so I think it'd be fine to just let Chrome allocate the threads

the simplest solution is to post all the tasks to the threadpool, and let the threadpool schedule things

so if there is one large image, many threads work on that one

if there are many small images, every image gets a thread

oh yeah good point

hmm, given that browsers already have native Wasm support, it might be feasible to get `MA-tree -> Wasm -> native code (JIT)` working in theory

the idea of JIT compiling MA-trees has been brought up before

I feel like interfacing with the wasm engine like that is orders of magnitudes more work than implementing JXL decoding in browsers itself was, lol

I mean, we already make jxl-rs create a LUT from the MA tree for effort 2, so that's probably native code already or close enough to it

oh that sounds interesting, can you explain how that works?

on a high level

"in theory" is load-bearing here 😛

I feel like I would be such a great manager, I could come up with all sorts of crazy ideas and never have to worry about the implementation! <:KekDog:805390049033191445>

<@623776984987729940> the following file/image doesn't look correct. left is current canary with jxl-rs. right is a version of Chromium with the old libjxl implementation restored.

smells like some colorspace confusion

(possibly the `embedded_color_profile` thingy I was mentioning before <@623776984987729940> )

<@179701849576833024> might be, will take a look

<@179701849576833024> seems to work!

preparing CL

wait can you show a zoom in of the left door? I want to make sure that there isn't a secondary issue cropping up

oof it seems like the colors are getting handled in a way that's crushing them. zoom into the door's window and compare with this picture of the old Chromium libjxl implementation

beware this is via chrome-remote-desktop :/

not having local build env (mac)

ah that might be why then. is there anyway you are able to take a screenshot of the proper rendered out result and get it over to your host machine?

Bear in mind jxl-rs has no dithering right now, and defaults to linear like libjxl

using xfce screenshot

ah yep you are encountering something I was worried about. I'm gonna try to explain my understanding of what's happening but it might be a little off and messy. This is happening due to jxl-rs 0.3.0 having this PR: https://github.com/libjxl/jxl-rs/pull/625 This PR correctly does what it says on the tin however due to that it introduces an issue that was previously only present in libjxl. Read here for slightly more details about the behavior from libjxl that was brought over: https://github.com/libjxl/libjxl/pull/4516#issuecomment-3609792197

it seems like the old libjxl implementation in Chrome managed to bypass this issue entirely. I haven't looked at the code but I assume it was just doing color management differently in a way where this didn't affect it

it was doing color conversion to the display colorspace (with skcms) before converting to u8

would it make sense try and make jxl-rs match the libjxl docs rather then the libjxl codebase in this case? The only project(s) AFAIK that currently uses jxl-rs are the unfinalized JXL support in Chromium and Firefox/Gecko and it would be a shame to have jxl-rs inherit what seems to be a mistake from libjxl

I don't have strong opinions on what colorspace jxl-rs defaults to

as long as it doesn't make the logic overly complicated 😛

I mean what the libjxl docs say compared to what the libjxl codebase does is a bit more complex since it says that linear get used when outputting to floating point and sRGB get used when outputting to integer

that's not overly complicated

moving over to <#1464417869470371912> https://discord.com/channels/794206087879852103/1464417869470371912/1464433719547793662

Tested JXL Extension on clean Windows 11. Good news: JPEG XL EXIF support is as good as JPEG.

Bad news: Rotation is wrong, and...

It's probably reading rotation from the codestream *and* the EXIF instead of only applying one

...and CMYK support is broken. Also bench for comparison, not sure if no rotation or double rotation.

Also tested color profile stress test images, they look identical for both JPG and JXL. So no problems here