|
|
veluca
|
2026-01-13 11:47:20
|
is it reasonably fast in your experience? |
|
|
jonnyawsom3
|
2026-01-13 11:48:03
|
Colorspace is also sRGB, so it shouldn't display as HDR anyway |
|
|
dogelition
|
2026-01-13 11:48:47
|
it goes above 1 and into the negatives for wcg/hdr |
|
2026-01-13 11:49:13
|
or are you saying it should be tagged differently to indicate that while still having the same pixel data |
|
|
|
jonnyawsom3
|
2026-01-13 11:51:17
|
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 |
|
|
|
dogelition
|
2026-01-13 11:54:08
|
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 |
|
2026-01-13 11:56:02
|
(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) |
|
|
username
|
2026-01-13 11:56:53
|
how does the old libjxl implementation in Chromium handle it? |
|
2026-01-13 11:57:06
|
or does it also handle it as SDR? |
|
|
|
dogelition
|
2026-01-13 11:57:43
|
is that the same as in thorium? same behavior there, clipped sdr |
|
|
|
jonnyawsom3
|
2026-01-13 11:59:34
|
Apparently my eyes skimmed over "Linear transfer function" and read everything else.. |
|
|
|
dogelition
|
2026-01-13 12:00:53
|
sample file for testing |
|
|
RaveSteel
|
2026-01-13 12:01:31
|
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 |
|
|
|
jonnyawsom3
|
2026-01-13 12:02:10
|
What effort? Try 8 |
|
|
|
dogelition
|
2026-01-13 12:02:42
|
guess i should rerun my test (https://discord.com/channels/794206087879852103/803645746661425173/1250101680620568727) to see if that's true |
|
2026-01-13 12:02:52
|
assuming i can find the code again |
|
|
|
RaveSteel
|
2026-01-13 12:04:16
|
Even effort 9 is hardly smaller
e8 - 25581.6 kB (24.674 bpp)
e9 - 25455.6 kB (24.552 bpp) |
|
2026-01-13 12:07:01
|
But still 5MB smaller than the JXR |
|
|
|
jonnyawsom3
|
2026-01-13 12:08:59
|
For some images it's within 10% now, standard VarDCT is roughly equal IIRC |
|
|
whatsurname
|
2026-01-13 12:17:34
|
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 |
|
|
dormosaurus
|
2026-01-13 12:21:42
|
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) |
|
|
_wb_
|
2026-01-13 12:58:06
|
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/ |
|
2026-01-13 12:58:33
|
animations play without stuttering, images load as fast as I can scroll |
|
2026-01-13 01:06:32
|
I'm not sure how Jake's benchmark works exactly, it says 150ms for fox.jxl vs 11 to 12ms for fox.avif |
|
2026-01-13 01:07:04
|
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 |
|
|
|
jonnyawsom3
|
2026-01-13 01:14:32
|
Huh, I thought progressive loading was hooked up? |
|
|
|
_wb_
|
2026-01-13 01:19:48
|
looks like it's just showing final groups when they're ready |
|
2026-01-13 01:22:28
|
As a starting point, I think this is solid |
|
|
Tirr
|
2026-01-13 01:22:56
|
iiuc it's rendering only fully loaded area, no eagerness |
|
2026-01-13 01:24:23
|
pass (or eager) progression isn't implemented yet, even if we request one, jxl-rs will always wait for data (for now) |
|
|
|
_wb_
|
2026-01-13 01:25:11
|
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. |
|
|
|
Tirr
|
2026-01-13 01:26:38
|
it does feel quite slow when opening HDR images with higher resolution |
|
|
|
_wb_
|
2026-01-13 01:26:41
|
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 |
|
2026-01-13 01:29:59
|
how much room for improvement in decode speed do you think there is? |
|
|
|
Tirr
|
2026-01-13 01:31:31
|
not sure, but libjxl is 1.5x faster for the same image at least |
|
|
|
jonnyawsom3
|
2026-01-13 01:31:44
|
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 |
|
|
|
Tirr
|
2026-01-13 01:33:06
|
and I think <@179701849576833024> is planning to further improve render pipeline? ๐ |
|
|
AccessViolation_
|
2026-01-13 01:35:24
|
multithreading would immediately be a big improvement for large images for sure |
|
|
|
RaveSteel
|
2026-01-13 01:38:58
|
Canary for android cannot get the update soon enough |
|
2026-01-13 01:40:24
|
Wait, it just did |
|
2026-01-13 01:40:26
|
nice |
|
2026-01-13 01:41:55
|
works pretty well, only the animation on the jpegxl.info webseite stutters a bit |
|
|
|
dogelition
|
2026-01-13 01:45:40
|
...why is this a different color? |
|
|
Quackdoc
|
2026-01-13 01:48:05
|
anybody else got any scripts to force CDNs that can use jxl to use jxl?
I wanna set them globally lol |
|
|
Magnap
|
2026-01-13 01:50:14
|
Same thing for the animation |
|
2026-01-13 01:51:16
|
It's definitely the wrong color: it looks identical to the others in fossify gallery |
|
|
|
dogelition
|
2026-01-13 01:51:27
|
and it looks identical on desktop |
|
|
hjanuschka
|
2026-01-13 01:51:40
|
will give it a try |
|
|
|
Magnap
|
2026-01-13 01:51:53
|
Dice are wrong too |
|
2026-01-13 01:53:08
|
A sign error in a red-blue color component? I forgot what the axes of XYB are |
|
|
|
hjanuschka
|
2026-01-13 01:53:41
|
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? |
|
|
|
dogelition
|
2026-01-13 01:54:04
|
i'm too lazy to file one |
|
|
|
hjanuschka
|
2026-01-13 01:54:30
|
i m filing and trying to fix, just wanted to know if it is ok to copy the screenshots |
|
|
|
Magnap
|
2026-01-13 01:54:43
|
Please take the screenshots for sure ๐ |
|
2026-01-13 01:54:50
|
Uh, that's ambiguous |
|
2026-01-13 01:54:54
|
Yes, copy them |
|
2026-01-13 01:55:03
|
Don't re-take them yourself ๐
|
|
|
|
RaveSteel
|
2026-01-13 01:56:33
|
the animation stutters a bit on desktop as well for me. but colors are indeed correct |
|
|
|
hjanuschka
|
2026-01-13 01:57:01
|
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 |
|
2026-01-13 01:57:07
|
the android thing is for sure a bug |
|
|
|
Magnap
|
2026-01-13 01:58:20
|
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 |
|
|
|
dogelition
|
2026-01-13 01:59:19
|
jxl art is also affected so i would assume it's a red/blue channel swap elsewhere |
|
|
|
hjanuschka
|
2026-01-13 01:59:25
|
well that is not enabled, testing if it works once enabled, but we'd need to have a jxl-rs roll for that change |
|
|
|
Magnap
|
2026-01-13 02:00:41
|
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 |
|
|
|
hjanuschka
|
2026-01-13 02:01:03
|
the red one will work once dice and animation are ok - i bet |
|
|
|
Magnap
|
2026-01-13 02:01:27
|
The red one is already working tho, is what I'm saying. It's red as it should be |
|
2026-01-13 02:02:07
|
|
|
|
|
dogelition
|
2026-01-13 02:02:40
|
(left is the actual jxl decoded by chromium, right is decoded to png via the wasm decoder) |
|
|
|
Magnap
|
2026-01-13 02:04:44
|
Wait, it's not red for you? Fdkdjg |
|
2026-01-13 02:05:32
|
I'm guessing some device information might be useful, then. I'll be happy to provide it |
|
|
|
dogelition
|
2026-01-13 02:06:02
|
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 |
|
2026-01-13 02:06:41
|
so i would assume that some layer expects BGR but receives RGB instead (or the other way around) |
|
2026-01-13 02:07:43
|
that wide gamut image is red for me too |
|
|
|
Magnap
|
2026-01-13 02:08:04
|
Ah ok, great |
|
|
VcSaJen
|
2026-01-13 02:09:55
|
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 |
|
|
|
dogelition
|
2026-01-13 02:11:21
|
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 |
|
|
|
whatsurname
|
2026-01-13 02:12:04
|
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? |
|
|
|
veluca
|
2026-01-13 02:14:18
|
indeed I am, but that code is scary ๐ |
|
|
HCrikki
|
2026-01-13 02:14:53
|
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) |
|
|
|
dogelition
|
2026-01-13 02:14:53
|
<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 |
|
|
|
veluca
|
2026-01-13 02:15:07
|
fwiw conversion to f16 (which HDR uses) is much much slower than it needs to be |
|
2026-01-13 02:16:08
|
that does smell like some RGB and BGR swap somewhere |
|
2026-01-13 02:16:13
|
what's your OS? |
|
|
|
dogelition
|
2026-01-13 02:16:29
|
android 15 (hyperos 2) |
|
|
|
veluca
|
2026-01-13 02:16:34
|
huh |
|
2026-01-13 02:16:44
|
ok, no idea what that does |
|
|
|
whatsurname
|
2026-01-13 02:21:17
|
Yeah broken for me on Chrome Canary for Android as well |
|
|
|
dogelition
|
2026-01-13 02:27:31
|
any idea how i can bisect which build broke hdr images? (without building chromium myself) |
|
|
|
whatsurname
|
2026-01-13 02:28:24
|
apk mirror ig |
|
|
|
jonnyawsom3
|
2026-01-13 02:30:44
|
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%) |
|
2026-01-13 02:32:49
|
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 |
|
|
|
Quackdoc
|
2026-01-13 02:34:20
|
yeah, but there are actual scripts that redirect cdn requests to jxl ones |
|
|
|
Magnap
|
2026-01-13 02:34:46
|
Android 15 here too, OxygenOS 15.0, security update from November |
|
|
|
Quackdoc
|
2026-01-13 02:34:55
|
example https://discord.com/channels/794206087879852103/806898911091753051/1275684586482827330 |
|
|
|
jonnyawsom3
|
2026-01-13 02:40:56
|
I'm getting them but they don't load |
|
|
|
Quackdoc
|
2026-01-13 02:41:00
|
dumping surface flinger would prolly tell us |
|
|
|
jonnyawsom3
|
2026-01-13 02:41:04
|
<https://i.guim.co.uk/img/media/d69b01902eb4ca9d4c0c224c16bf7649949fe362/109_2793_582_465/master/582.jpg?width=220&dpr=1&s=none&crop=5%3A4> |
|
2026-01-13 02:46:13
|
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/> |
|
|
|
_wb_
|
2026-01-13 02:50:27
|
Interesting RGB / BGR swap there |
|
2026-01-13 02:52:37
|
I suppose an endianness issue? one thing sends/expects big-endian RGBA and the other thinks it's little-endian ARGB or whatever |
|
|
|
HCrikki
|
2026-01-13 02:53:49
|
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 |
|
|
|
Quackdoc
|
2026-01-13 02:57:24
|
do we have to enable flags for android? |
|
|
|
dogelition
|
2026-01-13 02:57:32
|
i had to i think |
|
|
|
HCrikki
|
|
|
dogelition
|
2026-01-13 02:58:01
|
tried to set up the chromium bisect script but it says it can't find adb... despite `adb.exe` being on my PATH |
|
|
|
HCrikki
|
2026-01-13 02:58:02
|
only an Origin Trial force-enables it for a predetermined list of participating websites |
|
|
|
jonnyawsom3
|
2026-01-13 02:58:33
|
The MIME is detected correctly in the network inspector, but maybe it's still going to the wrong decoder |
|
|
|
hjanuschka
|
2026-01-13 03:03:00
|
guess i found the android fix! trying to launch that damn emulator ๐ |
|
|
|
Quackdoc
|
2026-01-13 03:03:04
|
surface flinger only sees rgb layers, no bgr |
|
2026-01-13 03:03:33
|
what was? ~~also this is why I use Waydroid or bliss~~ |
|
|
|
hjanuschka
|
2026-01-13 03:04:51
|
on android skia handles rgba vs bgra differently |
|
|
|
Quackdoc
|
2026-01-13 03:05:59
|
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 |
|
|
|
HCrikki
|
2026-01-13 03:18:49
|
unrelated but libraw finally shipped 0.22.0 featuring dng1.7 with jxl for real this time |
|
|
|
_wb_
|
2026-01-13 03:26:32
|
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 |
|
|
|
whatsurname
|
2026-01-13 03:26:49
|
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 |
|
|
|
_wb_
|
2026-01-13 03:29:44
|
*pending approval my the relevant decision makers at Cloudinary |
|
|
|
hjanuschka
|
2026-01-13 03:31:12
|
"a guinea pig" made my day โค๏ธ |
|
|
|
jonnyawsom3
|
2026-01-13 03:32:41
|
A fresh release would also bring fast lossless more in-line with libjxl |
|
|
|
hjanuschka
|
2026-01-13 03:36:48
|
ready to roll all day long ๐ค |
|
|
|
whatsurname
|
2026-01-13 03:37:54
|
Also I think it should show the broken image icon instead of just blank when decode failed |
|
|
|
dogelition
|
2026-01-13 03:40:43
|
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 |
|
|
|
Quackdoc
|
2026-01-13 03:42:26
|
finding sed adb with adb.exe? |
|
|
|
veluca
|
2026-01-13 03:43:25
|
by the way, if someone felt like picking up some of the PRs by lillith it'd be much appreciated ๐ |
|
|
|
Tirr
|
2026-01-13 03:44:34
|
maybe I can take some of those if nobody came up until weekend |
|
|
|
dogelition
|
2026-01-13 03:50:12
|
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 |
|
2026-01-13 03:50:29
|
did somehow get it to work on my laptop now though, no idea what made the python errors go away |
|
|
|
RaveSteel
|
2026-01-13 03:50:52
|
what do you get with `which adb`? |
|
|
|
dogelition
|
2026-01-13 03:51:30
|
i solved it not finding adb and aapt by hardcoding the paths in the scripts already, still had weird python errors after that |
|
2026-01-13 03:51:38
|
i think somehow uninstalling chromium from previous attempts made it work now? |
|
2026-01-13 03:51:40
|
idk weird stuff |
|
|
|
RaveSteel
|
2026-01-13 03:51:50
|
hm, weird indeed |
|
|
|
dogelition
|
2026-01-13 03:52:08
|
it's definitely working now though, it's giving me some broken and some working builds |
|
|
|
paperboyo
|
2026-01-13 03:59:21
|
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. |
|
|
|
whatsurname
|
2026-01-13 04:02:48
|
See https://discord.com/channels/794206087879852103/803574970180829194/1460656341025554542 |
|
|
|
dogelition
|
2026-01-13 04:03:56
|
bisect (for hdr not triggering on android) gave me this: https://chromium.googlesource.com/chromium/src/+log/45baec6f3e152fa5e8c67fa7a65d69caf57a7d67..dc8611db7fbba200d23580ac1635fe189bf65036 |
|
2026-01-13 04:05:15
|
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 |
|
|
|
hjanuschka
|
2026-01-13 04:08:48
|
android CL: https://chromium-review.googlesource.com/c/chromium/src/+/7459081 - phy. verified ๐ lets hope! |
|
2026-01-13 04:09:12
|
if anyone is crazy enough to use a internet-guy-distributed APK - DM ๐ |
|
|
|
dogelition
|
2026-01-13 05:00:47
|
https://issues.chromium.org/issues/475475547 |
|
2026-01-13 05:01:02
|
if anyone here wants to figure out what broke hdr on android |
|
|
|
hjanuschka
|
2026-01-13 05:10:49
|
ohhhh no - hope this is not because of jxl? |
|
|
|
dogelition
|
2026-01-13 05:11:06
|
seems unrelated to me but idk |
|
2026-01-13 05:11:42
|
nothing in the bisect output seems to be related to jxl |
|
2026-01-13 05:12:38
|
(it does affect jxl hdr images too though) |
|
2026-01-13 05:20:49
|
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 |
|
|
spider-mario
|
2026-01-13 05:23:29
|
just looking at the list of commits, https://crrev.com/70e3639b7ac8c7acb5b3479249192ecb47c43771 looks like it could potentially be the culprit |
|
|
|
dogelition
|
2026-01-13 05:25:05
|
is that `ProtectRecentlyVisibleTab` feature something i can disable? |
|
2026-01-13 05:38:33
|
i think i passed the flag to disable it but it didn't do anything |
|
2026-01-13 05:38:37
|
could be this? https://chromium.googlesource.com/chromium/src/+/065eeb23d3188413976d97d380582efd92485f35
it does *something* related to hdr metadata |
|
|
|
spider-mario
|
2026-01-13 06:15:41
|
oh, yes, could definitely be it |
|
|
|
hjanuschka
|
2026-01-13 06:25:36
|
is this all googlers here? or is just everyone firm with chrome? |
|
2026-01-13 06:26:11
|
and btw whenever i stumble into any discord i really feel old! everything blinks๐คช |
|
|
lonjil
|
2026-01-13 06:31:45
|
lots of googlers in here |
|
2026-01-13 06:32:07
|
several non-googlers who use chrome |
|
2026-01-13 06:32:16
|
and a few of us who use firefox :v |
|
|
|
jonnyawsom3
|
2026-01-13 06:33:09
|
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 |
|
2026-01-13 06:37:59
|
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 |
|
2026-01-13 07:38:19
|
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)` |
|
2026-01-13 07:38:42
|
Nearly 4x faster, not bad |
|
|
|
veluca
|
2026-01-13 07:46:43
|
not sure I understood what you compared |
|
|
|
paperboyo
|
2026-01-13 07:51:37
|
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: |
|
|
|
jonnyawsom3
|
2026-01-13 08:04:09
|
Effort 7 lossless, faster decoding levels 0 (So normal), level 1 and level 4 |
|
|
|
veluca
|
2026-01-13 08:05:49
|
on jxl-rs? |
|
|
|
jonnyawsom3
|
2026-01-13 08:05:58
|
Yeah, on Chrome Canary |
|
|
|
veluca
|
2026-01-13 08:06:04
|
ah I see |
|
2026-01-13 08:06:30
|
that's without fast paths, right? |
|
|
|
jonnyawsom3
|
2026-01-13 08:08:19
|
Yep, without this PR https://github.com/libjxl/jxl-rs/pull/600 |
|
2026-01-13 08:09:08
|
(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) |
|
2026-01-13 08:19:42
|
PNG was 111ms for comparison, so 5x slower at half the filesize, should hopefully go down to 2x slower or less with the PR |
|
|
Pheubel
|
2026-01-13 09:08:40
|
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 |
|
|
|
HCrikki
|
2026-01-13 09:14:10
|
waterfox has complete jxl support on desktop and android (base nightly's with the additional patches). based on libjxl |
|
|
|
jonnyawsom3
|
2026-01-13 09:15:04
|
https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 |
|
|
|
_wb_
|
2026-01-13 09:32:12
|
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. |
|
|
|
veluca
|
|
|
_wb_
|
2026-01-13 09:40:26
|
|
|
2026-01-13 09:41:05
|
I can confirm the BGR - RGB bug on my Android phone (Motorola edge 60) |
|
|
|
hjanuschka
|
2026-01-13 10:06:44
|
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! |
|
|
|
veluca
|
2026-01-13 10:20:13
|
same on my pixel, fwiw ๐ |
|
|
|
AccessViolation_
|
2026-01-13 10:27:09
|
I like this example because it's not very obvious something is wrong at first glance. it's just different dice with different colors! |
|
|
|
hjanuschka
|
2026-01-13 10:41:29
|
and then it is super obviuos and a great showcase of whats wrong too ๐ |
|
2026-01-13 10:41:35
|
https://github.com/hjanuschka/chrome-apks/releases/tag/v1.0.0-jxl-android fixed apk |
|
|
|
jonnyawsom3
|
2026-01-14 01:47:17
|
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 |
|
|
|
Pheubel
|
2026-01-14 09:04:28
|
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? |
|
2026-01-14 09:05:54
|
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 |
|
|
|
RaveSteel
|
2026-01-14 09:21:22
|
They should reopen this issue
https://github.com/electron/electron/issues/43993 |
|
|
|
username
|
2026-01-14 09:35:55
|
do they even need to do anything for this? |
|
2026-01-14 09:36:39
|
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 |
|
2026-01-14 09:37:23
|
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 |
|
|
|
whatsurname
|
2026-01-14 09:40:15
|
Doesn't discord use its own stack for image processing
https://discord.com/blog/modern-image-formats-at-discord-supporting-webp-and-avif |
|
|
|
username
|
2026-01-14 09:41:56
|
support needs to be done on both ends |
|
|
adap
|
2026-01-14 10:26:31
|
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 |
|
2026-01-14 10:26:38
|
|
|
2026-01-14 10:27:02
|
if you can even call it support |
|
|
|
jonnyawsom3
|
2026-01-14 01:04:49
|
Assuming nothing breaks, 2 months until the flag is added to Electron. But it'll still be relatively slow to decode |
|
2026-01-14 11:48:42
|
Interesting <https://www.cast-inc.com/compression/jpeg-image-compression/jpeg-xl-e> |
|
|
|
HCrikki
|
2026-01-15 12:52:43
|
on chrome, 145 is the upcoming beta, meaning support behind a user-switchable flag could reach stable in as little as 2 weeks |
|
2026-01-15 01:00:24
|
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 |
|
|
|
veluca
|
2026-01-15 01:12:35
|
wonder what's so different between the Altera and AMD impls |
|
|
|
jonnyawsom3
|
2026-01-15 01:14:15
|
> 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 |
|
|
|
veluca
|
2026-01-15 01:17:13
|
my personal guesstimate is that we'll want to wait for 147 |
|
2026-01-15 01:17:46
|
(not because 147 is special, but to optimize things well and not rush too much) |
|
|
|
jonnyawsom3
|
2026-01-15 01:18:45
|
As far as I can tell, nothing. The docs are just worded differently to fit their terminology |
|
|
|
veluca
|
2026-01-15 01:19:18
|
yeah could be that they have a very different "DSP element" that causes the ~1.7x |
|
|
|
whatsurname
|
2026-01-15 02:27:16
|
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 |
|
2026-01-15 02:39:04
|
Actually it's already requested
https://issues.chromium.org/issues/475899040 |
|
|
|
jonnyawsom3
|
2026-01-15 03:24:04
|
Ah good |
|
|
|
hjanuschka
|
2026-01-15 07:47:24
|
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) |
|
|
|
5peak
|
2026-01-15 11:09:22
|
Dankeschรถn. |
|
|
|
hjanuschka
|
2026-01-15 01:55:03
|
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 ๐ |
|
|
|
username
|
2026-01-15 01:59:57
|
I think the patches for adding in jxl-rs are waiting to be reviewed |
|
2026-01-15 02:00:50
|
as for the current libjxl implementation in the codebase it's completely abandoned and they will not accept patches for it |
|
2026-01-15 02:02:42
|
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 |
|
|
|
veluca
|
2026-01-15 02:06:43
|
I think that's because updated patches were uploaded |
|
|
|
username
|
2026-01-15 02:11:13
|
ah yeah that seems like what's happening |
|
|
|
jonnyawsom3
|
2026-01-16 04:56:53
|
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> |
|
2026-01-16 04:59:05
|
|
|
|
|
whatsurname
|
2026-01-16 06:57:03
|
https://jsfiddle.net/z78kunc3/
This is more noticeable |
|
|
|
adap
|
2026-01-16 07:04:06
|
I noticed that too on my m4 mac |
|
2026-01-16 07:04:39
|
so i doubt it's a cpu issue |
|
|
|
hjanuschka
|
2026-01-16 07:09:45
|
we have a change open, that enables simd stuff in rust, current canary is without, i think it is the main reason |
|
2026-01-16 07:12:00
|
<@238552565619359744> is it also drifting when you directly only, open https://jpegxl.info/images/anim-icos.jxl in a tab? |
|
2026-01-16 07:12:41
|
and with drifting, you mean it drifts away from webp, apng and gif?
for me they all are not 100% in sync |
|
|
|
dormosaurus
|
2026-01-16 08:36:23
|
<@623776984987729940> I don't think it's rust version specific, I have the syncing issue with the abandoned libjxl patch as well |
|
|
|
hjanuschka
|
2026-01-16 09:00:37
|
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 |
|
|
|
whatsurname
|
2026-01-16 09:22:45
|
Left: 145.0.7632.0
Right: 146.0.7637.0 |
|
2026-01-16 09:24:40
|
The animation issue still persists though |
|
|
|
hjanuschka
|
2026-01-16 09:43:43
|
simd! ๐ animations ๐ |
|
|
|
veluca
|
2026-01-16 09:44:32
|
3x speedup, not bad |
|
2026-01-16 09:44:38
|
(was hoping for more :P) |
|
|
|
hjanuschka
|
2026-01-16 09:44:58
|
should we try to merge request into 145? |
|
|
|
5peak
|
2026-01-16 09:45:31
|
SYN+ACK |
|
|
|
username
|
2026-01-16 09:45:59
|
doesn't chromium do ""LTS"" releases every other release? in this case is 145 or 146 considered an LTS release? |
|
2026-01-16 09:46:35
|
if 145 is considered LTS then yeah it might be worth it to try and get SMID pushed to it |
|
|
|
hjanuschka
|
2026-01-16 09:47:40
|
any doc/reference where it says that 145 will be LTS? |
|
2026-01-16 09:47:46
|
would be a great line for the merge request |
|
|
|
username
|
2026-01-16 09:48:24
|
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 |
|
|
|
hjanuschka
|
2026-01-16 09:48:44
|
still going to try it, worst case it's rejected |
|
2026-01-16 09:49:22
|
will upload your performance screenshot |
|
|
|
whatsurname
|
2026-01-16 10:01:22
|
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 |
|
|
|
hjanuschka
|
2026-01-16 10:03:32
|
TIL arm64 builds! does it include widvine and is a release build? ๐ |
|
|
|
whatsurname
|
2026-01-16 10:04:42
|
It's from https://googlechromelabs.github.io/chrome-for-testing/#canary the page is not updated yet but it's already built |
|
|
|
veluca
|
2026-01-16 10:08:11
|
I don't think it's too important to merge the speedup, fwiw |
|
2026-01-16 10:08:15
|
it's not broken, at least |
|
|
|
hjanuschka
|
2026-01-16 10:17:47
|
think i found the drifting, will give it a try |
|
2026-01-16 10:51:16
|
anyone with drifts, able to run a CL locally? ( https://chromium-review.googlesource.com/c/chromium/src/+/7484708 ) |
|
2026-01-16 10:52:00
|
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) ๐ |
|
|
|
whatsurname
|
2026-01-16 11:45:26
|
I don't think it's due to precision tho, you can tell the duration of 2 is very short |
|
2026-01-16 11:54:32
|
Oops, it seems the screen recording messed it up |
|
2026-01-16 12:16:58
|
So I measured the time, for some reason 2 only last 100ms while other frames last 500ms |
|
|
|
veluca
|
2026-01-16 12:20:07
|
Intriguing |
|
|
|
dogelition
|
2026-01-16 12:28:21
|
<@604964375924834314> do you have any thoughts on whether linear hdr like ^ is expected to work? |
|
|
|
spider-mario
|
2026-01-16 12:30:59
|
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 |
|
2026-01-16 12:31:07
|
but I donโt remember the details |
|
2026-01-16 12:33:41
|
ah, some WIP here https://crrev.com/c/3483826 |
|
2026-01-16 12:33:45
|
as you can see, it was a while ago |
|
|
|
whatsurname
|
2026-01-16 12:38:45
|
I think I found why it's 100ms
https://issues.chromium.org/issues/41015120#comment7
The decoder probably returned 0 for that frame |
|
2026-01-16 12:44:30
|
This also explains the shift of the other image, which has a < 100ms duration, so 100ms will make it look slower instead of faster |
|
|
|
veluca
|
2026-01-16 12:47:28
|
can you check that with jxl-rs directly? |
|
|
|
whatsurname
|
2026-01-16 01:09:45
|
Interesting, I got 33.33 ms duration for the first frame (rest are correct) using jxl_cli (decode to APNG) |
|
|
|
veluca
|
2026-01-16 01:42:40
|
... surprising |
|
|
|
hjanuschka
|
2026-01-16 02:05:55
|
think i found it! |
|
|
|
whatsurname
|
2026-01-16 02:06:36
|
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 |
|
|
|
hjanuschka
|
2026-01-16 02:06:40
|
anyone wanna try the CL again? |
|
2026-01-16 02:07:07
|
(gonna put, jxl-animation-survivor on my linkedin; once its actually working!) |
|
2026-01-16 02:07:35
|
https://chromium-review.googlesource.com/c/chromium/src/+/7484708 |
|
2026-01-16 02:07:50
|
if it works, i am polishing it ๐ |
|
2026-01-16 02:08:06
|
would be nice, if a non-remote-desktop person could test it |
|
|
|
RaveSteel
|
2026-01-16 02:08:25
|
If only the compile didn't take an hour every time |
|
|
|
hjanuschka
|
2026-01-16 02:09:12
|
https://tenor.com/view/troopers-responsible-helpful-doing-my-part-gif-11496062726020391529 |
|
2026-01-16 02:09:13
|
bug1: Duration precision loss
bug2: FrameDurationAtIndex() was reading from wrong source
bug3: Frame durations not available when animation controller requested them |
|
|
|
veluca
|
2026-01-16 02:49:55
|
can you file an issue or ideally send a PR? ๐ |
|
|
|
whatsurname
|
2026-01-16 02:54:58
|
Sure, I'll try this weekend |
|
|
|
veluca
|
2026-01-16 03:21:29
|
thank you ๐ |
|
|
|
Quackdoc
|
2026-01-16 04:02:54
|
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 |
|
2026-01-16 04:50:57
|
interesting that cloudinary defaults to webp instead of avif if avif is missing from accept header, is this a client config issue? |
|
|
|
jonnyawsom3
|
2026-01-16 04:51:55
|
I'll rerun my faster decoding tests later, might do a bit better |
|
|
TheBigBadBoy - ๐ธ๐
|
2026-01-16 05:12:03
|
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 |
|
2026-01-16 05:12:37
|
(not chromium I know but at least you don't need to compile) |
|
2026-01-16 05:12:56
|
oh wait, there's `google-chrome-canary` on the AUR, which uses the .deb package
which has version 146.0.7637.0-1 |
|
|
|
hjanuschka
|
2026-01-16 06:52:51
|
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) |
|
2026-01-16 06:53:07
|
those are static binaries, should work on all (almost) linux's |
|
2026-01-16 06:57:48
|
about canary, it might be outdated, as my HEAD is different, but it has ALL latest JXL work |
|
2026-01-16 06:57:58
|
arm64: no netflix and chill, it does not come with widvine |
|
|
|
Quackdoc
|
2026-01-16 06:59:49
|
~~this is where I pester about riscv builds obviously~~ I have no qualms running the linux builds and android builds in waydroid |
|
2026-01-16 07:01:07
|
oh I need to re-init it |
|
2026-01-16 07:05:16
|
all looks good on desktop |
|
|
|
hjanuschka
|
2026-01-16 07:13:35
|
hooray! thanks for testing! |
|
|
|
Quackdoc
|
2026-01-16 07:15:54
|
hmmm,. thats weird, this build isn't working in waydroid for me, maybe it's incompatible with libndk? odd issue |
|
|
|
hjanuschka
|
2026-01-16 07:17:48
|
never used waidroid tbh |
|
|
|
Quackdoc
|
2026-01-16 07:18:11
|
really odd, ill play around with this |
|
2026-01-16 07:18:40
|
it's a bliss labs project to run android in a LXC container with wayland windowing, kinda akin to chromeOS |
|
2026-01-16 07:18:59
|
only supports linux |
|
|
|
AccessViolation_
|
2026-01-16 07:20:01
|
hm try the full url? |
|
2026-01-16 07:20:07
|
including https:// |
|
2026-01-16 07:20:29
|
I've had this happen in ungoogled chromium |
|
|
|
Quackdoc
|
2026-01-16 07:20:34
|
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 |
|
|
|
AccessViolation_
|
2026-01-16 07:20:59
|
oh wait that's a tab crash not a network error yea |
|
|
|
Quackdoc
|
2026-01-16 07:21:01
|
not even chrome://flags works lmao |
|
2026-01-16 07:21:27
|
its working fine on my phone tho so its all fine |
|
2026-01-16 07:22:09
|
works fine on my LOS android phone ๐ |
|
|
|
username
|
2026-01-16 07:33:11
|
did you specifically test for the animation timing/sync issue? that's mainly what these builds are for AFAIK |
|
|
|
Quackdoc
|
2026-01-16 07:40:08
|
the animation looked fine but are there many other sites to test? |
|
|
|
hjanuschka
|
2026-01-16 07:58:28
|
thanks, and also the https://jpegxl.info/resources/jpeg-xl-test-page.html dice has correct colors ๐ |
|
2026-01-16 07:58:35
|
(think thats confirmed, but asking anyway) |
|
|
|
jonnyawsom3
|
2026-01-16 08:04:14
|
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 |
|
|
|
hjanuschka
|
2026-01-16 08:07:23
|
thank you <@238552565619359744> |
|
2026-01-16 08:07:29
|
really excited! |
|
|
|
Quackdoc
|
2026-01-16 08:17:56
|
yeah it does have correct colors for me |
|
|
|
jonnyawsom3
|
2026-01-16 08:20:09
|
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 |
|
|
|
hjanuschka
|
2026-01-16 08:20:50
|
not yet sure what we are aiming for, but its an improvement ๐ |
|
2026-01-16 08:20:55
|
still excited |
|
|
|
Tirr
|
2026-01-16 08:21:41
|
simd tends to help vardct a lot, dct algorithm is heavily simdified |
|
|
|
jonnyawsom3
|
2026-01-16 08:21:58
|
Forgot to add the progressive AC command (Also damn Discord lags when I type) |
|
|
|
Tirr
|
2026-01-16 08:25:27
|
progressive lossless will also show the difference I think |
|
|
|
hjanuschka
|
2026-01-16 08:28:49
|
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 |
|
|
|
jonnyawsom3
|
2026-01-16 08:33:09
|
Not sure how I forgot that... Third time's the charm, now with the image resolution and the after result for progressive lossless |
|
2026-01-16 08:43:20
|
Good point, with the fast path commits merged lossless should be around 2x faster than lossy (I think...) |
|
|
|
HCrikki
|
2026-01-16 09:05:18
|
https://googlechromelabs.github.io/chrome-for-testing/#canary |
|
2026-01-16 09:05:50
|
no autoupdating, handy for testing or comparing multiple specific versions |
|
|
|
Quackdoc
|
2026-01-16 09:56:52
|
recording of this builds |
|
2026-01-16 09:58:54
|
taskset to 1 thread also seems fine |
|
|
|
jonnyawsom3
|
2026-01-16 10:19:14
|
Weird that GIF was out of sync for you, but looks fixed |
|
|
|
Quackdoc
|
|
|
jonnyawsom3
|
2026-01-16 11:41:15
|
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 |
|
|
|
veluca
|
2026-01-16 11:56:27
|
could I ask you for a summary of memory usage / speed of libjxl/oxide/rs for a bunch of relatively common files? ๐ |
|
|
|
jonnyawsom3
|
2026-01-17 12:18:09
|
That depends on what counts as 'relatively common' |
|
2026-01-17 12:18:41
|
I could run those same files again as a start |
|
|
|
veluca
|
2026-01-17 12:20:42
|
yeah that'd be a good start |
|
|
|
whatsurname
|
2026-01-17 03:00:19
|
The speedup of neon is a bit smaller than avx2, got ~2.5x |
|
|
SEO-Master1337
|
2026-01-17 04:23:20
|
YOOOOOOOOOOOOOOOOOOOOOOOOO
Latest version of Chrome Canary has a feature flag to enable JXL image format to the accept header and enables decoding ๐ |
|
2026-01-17 04:23:54
|
Shit am I late? hahaha |
|
|
A homosapien
|
2026-01-17 04:27:24
|
welcome to the party |
|
|
Jarek Duda
|
2026-01-17 05:01:36
|
also works in beta, release on 28th: https://chromestatus.com/roadmap |
|
|
|
jonnyawsom3
|
2026-01-17 06:24:41
|
A bit late, but hopefully this helps. Can add more later |
|
|
|
hjanuschka
|
2026-01-17 06:49:25
|
yes looks fixed! CL is landing |
|
|
|
jonnyawsom3
|
2026-01-17 07:13:58
|
Oh neat <https://docs.cloud.google.com/release-notes#December_22_2025> |
|
|
|
veluca
|
2026-01-17 08:27:30
|
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 |
|
2026-01-17 08:33:49
|
also very curious how jxl-oxide uses so little memory sometimes ๐ <@206628065147748352> ? |
|
|
|
Tirr
|
2026-01-17 09:16:00
|
I guess it's i16 buffers, not sure |
|
2026-01-17 09:16:56
|
jxl-oxide never allocates i32 buffers (even for final output) when it's possible |
|
|
|
veluca
|
2026-01-17 09:42:35
|
yeah that would do it |
|
|
|
jonnyawsom3
|
2026-01-17 06:20:24
|
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 |
|
2026-01-17 06:34:05
|
Oh, also in a quick test I tried using --high-precision and it was actually a little bit faster than default |
|
|
|
veluca
|
2026-01-17 07:10:12
|
do set it to 8 bits |
|
2026-01-17 07:10:18
|
(or 16 for hdr) |
|
|
|
jonnyawsom3
|
2026-01-17 07:16:33
|
Both djxl and jxl-rs I assume? |
|
|
|
veluca
|
2026-01-17 07:17:01
|
djxl at least, jxl-rs is not very good at outputing non-f32 yet xD |
|
2026-01-17 07:17:05
|
(but it will be) |
|
|
|
username
|
2026-01-17 10:32:55
|
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. |
|
|
|
veluca
|
2026-01-17 10:40:24
|
I am working on a somewhat big change to the low memory pipeline |
|
2026-01-17 10:40:33
|
which should reduce memory usage significantly |
|
|
|
Quackdoc
|
2026-01-17 10:46:53
|
YAY |
|
2026-01-17 10:47:13
|
memory usage is one of my biggest issues with jxl ecosystem rn |
|
|
|
veluca
|
2026-01-17 10:53:59
|
then at some point I might also do the f16 thingy |
|
2026-01-17 10:54:09
|
but we'll see when |
|
|
|
jonnyawsom3
|
2026-01-17 10:57:01
|
Here ya go
djxl, djxl set to 8-bit, Oxide and jxl-rs with PeakWorkingSetSize next to MP/s |
|
|
|
veluca
|
2026-01-17 10:57:26
|
is that on windows? |
|
|
|
jonnyawsom3
|
|
|
veluca
|
2026-01-17 11:01:09
|
good to know, thanks ๐ |
|
|
|
jonnyawsom3
|
2026-01-18 12:13:04
|
Just tried it in Canary, works fine now after playing for a few minutes |
|
|
|
hjanuschka
|
2026-01-18 12:40:20
|
really appreciate the confirmation!! |
|
|
|
whatsurname
|
2026-01-18 02:43:50
|
Hmm, it seems this is also fixed in 7640 but I don't know why |
|
|
|
_wb_
|
2026-01-18 11:28:23
|
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 |
|
|
|
jonnyawsom3
|
2026-01-18 08:55:05
|
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 |
|
2026-01-18 09:03:56
|
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`) |
|
|
Lumen
|
2026-01-19 09:10:29
|
my god.... |
|
2026-01-19 09:10:47
|
people really don't know how to measure differences between codecs, pretty sure they just did -q {quality} and measured the resulting size |
|
|
|
veluca
|
2026-01-19 09:30:49
|
happens a lot |
|
2026-01-19 09:31:35
|
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 |
|
|
|
jonnyawsom3
|
2026-01-19 09:33:08
|
Not sure what q100 did for JXL though, since it can't be lossless |
|
2026-01-19 09:34:47
|
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 |
|
|
monad
|
2026-01-19 11:24:19
|
since v0.1 |
|
|
|
_wb_
|
2026-01-19 11:26:46
|
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. |
|
|
|
username
|
2026-01-19 11:31:19
|
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 |
|
|
|
_wb_
|
2026-01-19 11:45:20
|
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. |
|
|
|
AccessViolation_
|
2026-01-19 11:47:09
|
could probably just reach out to them for some sample files ๐ |
|
|
|
Lumen
|
2026-01-19 12:15:02
|
I do have an FPGA, but I don't know enough how to use it yet- |
|
|
|
runr855
|
2026-01-19 07:39:30
|
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 |
|
|
|
HCrikki
|
2026-01-21 04:45:24
|
potential adoption for upcoming epub 3.4 spec. Anything useful to them to know before their WG call, link below |
|
2026-01-21 04:45:26
|
https://github.com/w3c/epub-specs/issues/2896 |
|
2026-01-21 04:49:52
|
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 |
|
2026-01-21 04:52:32
|
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 |
|
|
chocolatkey
|
2026-01-21 11:00:31
|
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 |
|
2026-01-21 11:02:01
|
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 |
|
|
|
jonnyawsom3
|
2026-01-21 11:44:04
|
I left a comment raising those points, hopefully it helps |
|
|
|
chocolatkey
|
2026-01-22 01:02:19
|
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 |
|
|
|
HCrikki
|
2026-01-22 03:51:42
|
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 |
|
2026-01-22 03:55:07
|
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 |
|
2026-01-22 04:01:56
|
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 |
|
|
|
hjanuschka
|
2026-01-22 04:38:14
|
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 |
|
2026-01-22 04:38:30
|
so if anyone knows someone - send them my way please! |
|
|
|
jonnyawsom3
|
2026-01-22 04:40:38
|
Isn't Akami the same one Steam uses? I'm fairly sure it's a reason they haven't updated formats too |
|
|
|
_wb_
|
2026-01-22 05:08:47
|
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. |
|
|
|
hjanuschka
|
2026-01-22 06:30:49
|
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. |
|
|
|
Quackdoc
|
2026-01-22 06:35:35
|
~~sounds like it's time for a good old spam campaign~~ |
|
|
|
veluca
|
2026-01-22 07:43:16
|
<@623776984987729940> switch to cloudinary? ๐ |
|
|
|
hjanuschka
|
2026-01-22 07:43:47
|
thought of it, but well that akamai contract is not easy to get out or to change! |
|
2026-01-22 07:44:22
|
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 |
|
2026-01-22 07:45:00
|
we need to make akamai support it, that would be a huge upllift in the industry! |
|
|
|
monad
|
2026-01-22 08:17:43
|
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. |
|
|
|
jonnyawsom3
|
2026-01-22 08:19:12
|
Well that's good news for <#1284444511375855667> https://www.fastly.com/blog/level-up-your-images-jpeg-xl-now-supported-by-image-optimizer |
|
|
|
AccessViolation_
|
2026-01-22 08:34:12
|
those graphs look so messy... |
|
|
NovaZone
|
2026-01-23 12:31:10
|
```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.``` |
|
2026-01-23 12:31:24
|
Riiight, moving on kek |
|
|
|
HCrikki
|
2026-01-23 08:17:18
|
draft up for epub 3.4 with jxl as a proposed core media type |
|
2026-01-23 08:20:35
|
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 |
|
2026-01-23 08:25:09
|
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) |
|
|
|
AccessViolation_
|
2026-01-23 08:26:20
|
to be fair, with the sheer amount of images they handle, encoding compute adds up quickly |
|
2026-01-23 08:27:15
|
I'm guessing effort 3 was an economical choice, balancing encoding compute costs and image transmission bandwidth costs to be the cheapest, everything considered |
|
2026-01-23 08:30:27
|
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 |
|
|
|
jonnyawsom3
|
2026-01-23 08:34:00
|
https://github.com/w3c/epub-specs/pull/2899 |
|
2026-01-23 08:50:58
|
Effort 3 is essentially just XYB JPEG though, only Effort 5 actually uses adaptive quantization and VarDCT |
|
|
|
AccessViolation_
|
2026-01-23 08:52:10
|
I thought that's what effort 1 was |
|
|
|
hjanuschka
|
2026-01-23 08:54:35
|
jxl-rs v0.3 is in current canary |
|
|
|
_wb_
|
2026-01-23 08:56:01
|
nice, mostly speed improvements I suppose? |
|
|
|
hjanuschka
|
2026-01-23 08:56:05
|
yes |
|
2026-01-23 08:56:24
|
hate discord, trying to find the benchmark website thing that did the 60 iterations ๐ |
|
2026-01-23 08:56:31
|
but search here is basically broken |
|
|
|
_wb_
|
2026-01-23 08:56:34
|
What's the status regarding progressive decode? currently it looks like we only have full group rendering? https://google.github.io/attention-center/ |
|
|
|
jonnyawsom3
|
2026-01-23 08:57:13
|
That's because it is, though the idea of implementing libjxl-tiny as effort 2/3 has been brought up before |
|
2026-01-23 08:57:57
|
Yeah, only finished groups work currently https://discord.com/channels/794206087879852103/803574970180829194/1460625531710996591 |
|
|
|
_wb_
|
2026-01-23 08:59:15
|
what's preventing showing at least the LF when it's available? |
|
2026-01-23 09:01:57
|
(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) |
|
|
|
Tirr
|
2026-01-23 09:03:41
|
iiuc it waits until all dependencies are available for the region, but maybe <@179701849576833024> knows better |
|
|
|
HCrikki
|
2026-01-23 09:04:19
|
guardian displays all jxls correctly in chromium canary 146.0.7651.0 so far <@810102077895344159> |
|
|
|
jonnyawsom3
|
2026-01-23 09:04:23
|
Here ya go, it was in <#822105409312653333> <https://random-stuff.jakearchibald.com/apps/img-decode-bench/> |
|
|
|
hjanuschka
|
2026-01-23 09:04:29
|
thanks ๐ |
|
2026-01-23 09:04:33
|
gonna bookmark this time |
|
|
|
_wb_
|
2026-01-23 09:10:20
|
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 |
|
|
|
HCrikki
|
2026-01-23 09:10:42
|
unreleated, but chromium has an odd save behaviour for images pretending to be jpg. right click save=jxl but ctrl+S=jpg |
|
|
|
_wb_
|
2026-01-23 09:11:36
|
I got 150ms for fox.jxl last week so it's twice as fast now for me. |
|
|
|
jonnyawsom3
|
2026-01-23 09:15:49
|
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 |
|
|
|
VcSaJen
|
2026-01-23 09:17:37
|
Mozilla said it would only accept "performant" decoder for Firefox, what are the exact requirements? Is 7 times slower than AVIF acceptable to them? |
|
2026-01-23 09:20:23
|
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? |
|
|
|
hjanuschka
|
2026-01-23 09:25:25
|
๐ฑ just keep in mind jxl-ui is a fun thing! dont take anything there serious |
|
|
|
jonnyawsom3
|
2026-01-23 09:26:22
|
Hence hiding the issue, it's a lot more responsive to get a preview instantly than block by block or nothing at all |
|
|
|
whatsurname
|
2026-01-23 09:27:11
|
I suspect it didn't send the correct accept header when using ctrl+s |
|
|
|
jonnyawsom3
|
2026-01-23 09:29:03
|
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 |
|
2026-01-23 09:37:38
|
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 |
|
2026-01-23 10:00:39
|
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 |
|
|
|
chocolatkey
|
2026-01-23 10:18:27
|
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 |
|
|
|
HCrikki
|
2026-01-23 10:20:50
|
that was just my educated assumption, not cold fact |
|
|
|
veluca
|
2026-01-23 10:22:28
|
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) |
|
|
|
chocolatkey
|
2026-01-23 10:23:16
|
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 |
|
2026-01-23 10:26:00
|
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 |
|
|
|
_wb_
|
2026-01-23 03:02:39
|
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? |
|
|
|
veluca
|
2026-01-23 03:04:42
|
I am definitely going to try to do so |
|
2026-01-23 03:05:00
|
jxl benefits from threads more than avif, at least ๐ (smaller blocks) |
|
|
|
jonnyawsom3
|
2026-01-23 03:08:37
|
That's assuming browsers give it enough threads to work with, I know someone said AVIF is limited to 2 threads in Chrome |
|
|
|
veluca
|
2026-01-23 03:10:51
|
that was because they didn't see it giving improvements with more |
|
|
|
jonnyawsom3
|
2026-01-23 03:11:12
|
Ah right |
|
|
|
whatsurname
|
2026-01-23 03:45:18
|
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> |
|
|
|
jonnyawsom3
|
2026-01-23 03:55:04
|
I mean, the occasional 4K GIF I stumble upon still brings my system to it's knees with only 1 thread |
|
|
|
whatsurname
|
2026-01-23 04:03:49
|
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 |
|
|
|
username
|
2026-01-23 04:06:45
|
I like that idea, It would probably help to some degree with preventing thread starvation and thrashing |
|
|
|
veluca
|
2026-01-23 04:14:36
|
not sure what the benefit would be |
|
2026-01-23 04:14:46
|
Chrome has its own threadpool anyway |
|
|
|
username
|
2026-01-23 04:19:07
|
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? |
|
|
|
AccessViolation_
|
2026-01-23 04:20:18
|
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? |
|
|
|
jonnyawsom3
|
2026-01-23 04:22:37
|
Thread scaling with JXL is pretty linear, so I think it'd be fine to just let Chrome allocate the threads |
|
|
|
veluca
|
2026-01-23 04:22:40
|
the simplest solution is to post all the tasks to the threadpool, and let the threadpool schedule things |
|
2026-01-23 04:23:00
|
so if there is one large image, many threads work on that one |
|
2026-01-23 04:23:10
|
if there are many small images, every image gets a thread |
|
|
|
AccessViolation_
|
2026-01-23 04:24:52
|
oh yeah good point |
|
2026-01-23 04:27:03
|
hmm, given that browsers already have native Wasm support, it might be feasible to get `MA-tree -> Wasm -> native code (JIT)` working in theory |
|
2026-01-23 04:27:24
|
the idea of JIT compiling MA-trees has been brought up before |
|
2026-01-23 04:30:16
|
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 |
|
|
|
jonnyawsom3
|
2026-01-23 04:32:30
|
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 |
|
|
|
AccessViolation_
|
2026-01-23 04:33:08
|
oh that sounds interesting, can you explain how that works? |
|
2026-01-23 04:33:50
|
on a high level |
|
|
|
veluca
|
2026-01-23 04:34:26
|
"in theory" is load-bearing here ๐ |
|
|
|
AccessViolation_
|
2026-01-23 04:36:01
|
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> |
|
|
|
username
|
2026-01-24 12:07:09
|
<@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. |
|
|
|
veluca
|
2026-01-24 12:09:58
|
smells like some colorspace confusion |
|
2026-01-24 12:11:27
|
(possibly the `embedded_color_profile` thingy I was mentioning before <@623776984987729940> ) |
|
|
|
hjanuschka
|
2026-01-24 12:13:20
|
<@179701849576833024> might be, will take a look |
|
2026-01-24 12:49:22
|
<@179701849576833024> seems to work! |
|
2026-01-24 12:49:24
|
preparing CL |
|
|
|
username
|
2026-01-24 12:51:46
|
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 |
|
|
|
hjanuschka
|
|
|
username
|
2026-01-24 01:00:50
|
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 |
|
|
|
hjanuschka
|
2026-01-24 01:01:50
|
beware this is via chrome-remote-desktop :/ |
|
2026-01-24 01:02:12
|
not having local build env (mac) |
|
|
|
username
|
2026-01-24 01:03:22
|
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? |
|
|
|
jonnyawsom3
|
2026-01-24 01:05:23
|
Bear in mind jxl-rs has no dithering right now, and defaults to linear like libjxl |
|
|
|
hjanuschka
|
2026-01-24 01:06:03
|
using xfce screenshot |
|
|
|
username
|
2026-01-24 01:12:00
|
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 |
|
2026-01-24 01:13:27
|
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 |
|
|
|
veluca
|
2026-01-24 01:18:20
|
it was doing color conversion to the display colorspace (with skcms) before converting to u8 |
|
|
|
username
|
2026-01-24 01:24:23
|
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 |
|
|
|
veluca
|
2026-01-24 01:24:52
|
I don't have strong opinions on what colorspace jxl-rs defaults to |
|
2026-01-24 01:25:14
|
as long as it doesn't make the logic overly complicated ๐ |
|
|
|
username
|
2026-01-24 01:27:32
|
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 |
|
|
|
veluca
|
2026-01-24 01:27:54
|
that's not overly complicated |
|
|
|
username
|
2026-01-24 01:37:12
|
moving over to <#1464417869470371912>
https://discord.com/channels/794206087879852103/1464417869470371912/1464433719547793662 |
|
|
|
VcSaJen
|
2026-01-24 09:16:10
|
Tested JXL Extension on clean Windows 11.
Good news: JPEG XL EXIF support is as good as JPEG. |
|
2026-01-24 09:17:26
|
Bad news: Rotation is wrong, and... |
|
|
|
jonnyawsom3
|
2026-01-24 09:18:08
|
It's probably reading rotation from the codestream *and* the EXIF instead of only applying one |
|
|
|
VcSaJen
|
2026-01-24 09:20:25
|
...and CMYK support is broken.
Also bench for comparison, not sure if no rotation or double rotation. |
|
2026-01-24 09:32:05
|
Also tested color profile stress test images, they look identical for both JPG and JXL. So no problems here |
|