|
HCrikki
|
2026-01-24 09:37:11
|
are the ms extension/Photos guys here? if not, maybe worth sharing a discord join link as feedback. some limitations and inefficiencies may be a result of unfamiliarity |
|
|
jonnyawsom3
|
2026-01-24 09:43:26
|
The weird thing is those should be handled by libjxl |
|
|
VcSaJen
|
2026-01-24 09:47:27
|
MS Paint can't open JPEG XL ๐ . But it can open webp and AVIF. It can't save in any of those formats. |
|
|
0xC0000054
|
2026-01-24 10:09:01
|
Strange. I would have thought MS Paint supported any format that WIC can load. |
|
2026-01-24 10:15:18
|
The WIC AVIF codec is still broken in various ways, e.g. not supporting transparency. |
|
|
|
VcSaJen
|
2026-01-24 10:21:49
|
I wonder when extension will be integrated by default instead of it being downloadable from the store? I guess when Edge ships JPEG XL via Blink. |
|
2026-01-24 10:22:45
|
I sent bug report via Feedback Hub app, but sometimes this feels like screaming into the void. I dunno if the devs who created that extension will ever see it. |
|
|
|
HCrikki
|
2026-01-24 10:35:23
|
photos prompts to download it when you open a jxl. it fails on win10 - shockingly one of the only few store listings available for win11 that are artificially blocked from win10 |
|
|
whatsurname
|
2026-01-24 10:54:56
|
They didn't even get WebP right: https://www.winhelponline.com/blog/webp-appear-dark-windows-photo-viewer/ |
|
|
|
0xC0000054
|
2026-01-24 11:50:15
|
I was aware of that as well. Buggy Microsoft codecs are one of the reasons Paint.NET uses my plugins to take over DDS, AVIF, WebP, and JXL thumbnail handing for Windows Explorer. The poor DDS support is the most baffling to me as Microsoft created that format. The WIC DDS codec can only read the BC1 (DXT1), BC2 (DXT3), and BC3 (DXT5) formats used by DirectX 9.0 and earlier. Most modern games would be using BC7 and the other DirectX 10+ formats. |
|
|
monad
|
2026-01-25 08:58:07
|
I see the issue giving JXL to Thorium, but not with mpv. So apparently there is some correct way to handle libjxl output, but mpv still doesn't improve djxl-produced PNGs. |
|
|
Tirr
|
2026-01-25 09:34:36
|
https://github.com/libjxl/jxl-rs/pull/654 should fix this, but not confirmed visually, it seems to work at least in unit test |
|
|
|
monad
|
2026-01-25 12:26:15
|
<@206628065147748352> It does not address PNG writing, correct? At least, I didn't see a difference on one problem image. |
|
|
|
veluca
|
2026-01-25 12:36:41
|
jxl-cli decodes to f32 _for now_ |
|
2026-01-25 12:36:50
|
(working on it rn) |
|
|
username
|
2026-01-25 05:13:44
|
thanks for trying to tackle this! ~~I do have to ask where/how exactly is the `srgb` color encoding ยฟtype? being handled?
context:
https://discord.com/channels/794206087879852103/1464417869470371912/1464434704911696023
https://discord.com/channels/794206087879852103/1464417869470371912/1464436312416452628~~ |
|
2026-01-25 05:29:58
|
~~I'm not the best at reading Rust code so this might already be handled cleanly and I just don't realize it~~ |
|
2026-01-25 05:42:42
|
oh wait I somehow missed that jxl-rs does in-fact have both brought over from libjxl whoops |
|
2026-01-25 05:44:16
|
don't know how I missed it since it's directly next to the other one but oh well: https://github.com/libjxl/jxl-rs/blob/1391a269d00469dc587eb9ec3d6b8bda1ce3f2fe/jxl/src/api/color.rs#L1107 |
|
2026-01-25 05:48:31
|
oh I know how now. I was reading the diffs for the PR that made the the color handling more like libjxl and it only had to bring over `LinearSRGB` from libjxl since jxl-rs already had `SRGB` present which is why I thought jxl-rs only had one but not the other, whoops. sorry for the noise! |
|
|
_wb_
|
2026-01-27 06:04:54
|
is there a specified criterion for getting jxl enabled by default in Chrome? |
|
|
|
username
|
2026-01-27 06:09:10
|
there is this document but I'm not entirely sure if it's really the definitive criteria: https://docs.google.com/document/d/1oT7K2h4Xf4E0ScUmsOQx0zXUVJj57qBwcsa3yK9SJr0/ |
|
|
|
jonnyawsom3
|
2026-01-27 06:20:37
|
There's this https://chromestatus.com/feature/5188299478007808 |
|
2026-01-27 06:22:08
|
It has a link at the bottom explainting each stage of shipping |
|
|
|
veluca
|
2026-01-27 06:51:08
|
tldr: "it works" + it's fast enough (~close to libjxl is enough), and it's well supported enough that it's not likely that any issues will be dropped on the floor |
|
2026-01-27 06:51:38
|
(at least that's my understanding) |
|
|
|
_wb_
|
2026-01-27 07:46:28
|
"it works" - that we already have, it's already working better than the Safari integration (which doesn't support animation)
"fast enough" - not quite libjxl speed yet but the gap is shrinking, right? When we add progressive decode, the _perceived_ speed will be much better, which I think is probably more important than the actual final image decode speed. With MT, the actual speed should get a nice boost too. Regarding single-threaded final-image decode speed, how large is the gap with libjxl now and how much room is there still left to improve jxl-rs?
"well supported" - hard to quantify but I think we have a large enough community that cares about it to consider this one OK... |
|
|
A homosapien
|
2026-01-27 07:49:12
|
I think multithreading and progressive decoding are the last two hurdles |
|
|
|
username
|
2026-01-27 07:50:23
|
I mean there's also gainmap support but personally eh I would be fine if it wasn't a blocker |
|
2026-01-27 07:52:50
|
I'm a bit worried that people will "misuse" the gainmap support by assuming "this is how I do HDR everywhere!" and then mass creating SDR to HDR gainmapped JXLs that don't take advantage of any of the benefits of using gainmaps while also undermining JXL's native HDR support as well |
|
|
|
veluca
|
2026-01-27 07:54:10
|
> "it works" - that we already have, it's already working better than the Safari integration (which doesn't support animation)
yeah we want a bit better than what we have now though ๐ laundry list: (1) progressive (2) animation that doesn't eat up gazillions of memory (3) making sure there are no crashes etc (4) possibly the gainmap stuff |
|
2026-01-27 07:55:16
|
"fast enough" -> yup gap is shrinking indeed, on the systems (and image) I tested the gap is somewhere in between 10% and 30% but there's definitely room for improvement left |
|
2026-01-27 07:56:08
|
> "well supported" - hard to quantify but I think we have a large enough community that cares about it to consider this one OK...
I think we've talked about more precise ways to quantify this but not sure I should say here ๐ but I think we are reasonably close |
|
|
|
jonnyawsom3
|
2026-01-27 07:56:16
|
~~I consider no gainmaps a feature~~ |
|
|
|
veluca
|
2026-01-27 07:57:07
|
and of course figuring out how to do MT well can help a lot too |
|
|
|
VcSaJen
|
2026-01-27 08:04:28
|
Hopefully Android adopts it sooner rather than later. There's a lot of trailing versions. |
|
|
|
username
|
2026-01-27 08:06:25
|
I don't think the Android team particularly cares about JXL. their preferred formats seem to be AVIF and gainmapped JPEGs |
|
2026-01-27 08:07:58
|
probably gonna have to wait at least half a decade or longer.. |
|
|
|
VcSaJen
|
2026-01-27 08:12:45
|
Well, they did add mime-type a while ago, and it's recognized as image. Baby steps. |
|
|
AccessViolation_
|
2026-01-27 08:20:34
|
I hope we fix desaturation before hardware encoders start showing up in phones |
|
|
awxkee
|
2026-01-27 08:20:53
|
I'm not sure about AVIFs, android don't decode about half of cases properly for years. It took more than 2 years to make decoding AVIFs with alpha |
|
|
|
jonnyawsom3
|
2026-01-27 08:22:15
|
At the quality cameras *should* be capturing at, it won't be much of an issue, but I'd bet it will still be noticable if we look for it |
|
|
|
awxkee
|
2026-01-27 08:23:43
|
with that speed YCgCo Avifs / Avif gainmaps is expected in android in ~2045 |
|
|
|
HCrikki
|
2026-01-27 08:24:01
|
Android preinstalls webview. Over time, this will make jxl decode available to all apps and games displying web content |
|
|
|
awxkee
|
2026-01-27 08:24:37
|
I tend to think android team responsible for images don't have any plans |
|
2026-01-27 08:24:42
|
It goes how it goes |
|
|
|
AccessViolation_
|
2026-01-27 08:28:39
|
JXL is a lot more compelling than AVIF as a photography format though. phone manufacturers might want to brag about it when they release new phones |
|
|
|
awxkee
|
2026-01-27 08:29:26
|
They do already. AFAIK samsung already for 2 years ships JXL support |
|
|
|
AccessViolation_
|
2026-01-27 08:29:38
|
oh yeah, though only for raws right? |
|
|
|
awxkee
|
2026-01-27 08:29:39
|
The problem here that those "patches" is not available in API for developers |
|
|
|
AccessViolation_
|
2026-01-27 08:29:58
|
are you talking about the Patches coding tool? |
|
|
|
awxkee
|
2026-01-27 08:30:00
|
So for common developer it's the same as "no support" |
|
|
|
AccessViolation_
|
2026-01-27 08:30:14
|
oh, code patches |
|
|
|
awxkee
|
2026-01-27 08:31:30
|
Yeah, I meant manufacturers doesn't ship clear android, so it's patched/changed/reworked whatever |
|
|
|
AccessViolation_
|
2026-01-27 08:32:06
|
gotcha |
|
|
|
awxkee
|
2026-01-27 08:33:39
|
So some of them do have already JXL in their patched OS |
|
2026-01-27 08:33:57
|
but for third party applications that you probably want to use those API is not available |
|
2026-01-27 08:34:29
|
so de-facto this is very close to "JXL is not supported" as you can use it only in a few dedicated OS applications |
|
2026-01-27 08:37:39
|
To pass this step it needs google support, to make standard, ensure that ALL manufacturers will support required APIs etc |
|
2026-01-27 08:37:57
|
until then you can assume "JXL is not supported" |
|
|
|
HCrikki
|
2026-01-27 09:05:40
|
the preinstalled gallery apps adding support would be a sufficient start |
|
2026-01-27 09:09:00
|
its not easy checking support on android since detection schema for jxl libraries hasnt been added to libchecker and similar |
|
|
|
whatsurname
|
2026-01-28 08:09:25
|
YCgCo AVIF support is already there since [Android 16 QPR1](https://android.googlesource.com/platform/external/rust/crabbyavif/+/0f5a15299871794e762eebe1d750c6392cc05e96).
The problem is, the platform AV1 decoder only has guaranteed support for main profile (i.e. no 4:4:4 support), which defeats the purpose of using YCgCo.
For gainmaps, they said they're working on it in Android 16 release notes, so I'd expect to see it in Android 17. |
|
|
Oleksii Matiash
|
2026-01-28 08:52:11
|
Yes. No jxl support in samsung gallery |
|
|
|
whatsurname
|
2026-01-28 10:02:51
|
It's actually more complicated than I thought. The software decoder does support 4:4:4, it's some other restrictions caused the image fail to decode.
Anyway, the platform decoder is not reliable. I think the only "new" format that's safe to use the platform decoder is WebP (and for still images only), other formats should bundle their decoders instead. |
|
|
|
_wb_
|
2026-01-28 10:47:45
|
The Android platform has a problem imo if they can basically only provide decent support for formats that are > 10 years old. |
|
|
|
awxkee
|
2026-01-28 10:54:34
|
Android had a bug with YUV encoding in JPEGs until ~2015 so it was encoding greenish JPEGs starting it existence |
|
2026-01-28 10:55:26
|
So using this information format age criteria seems to be >23 years old. |
|
2026-01-28 11:01:03
|
I understand that they may want to rely on hardware encoders and decoders, but almost all of these problems could be addressed with software fallbacks. They haven't done that for years and in some cases for decades so this level of support seems intentional. |
|
2026-01-28 11:07:08
|
All of this leads to funny situations where they aggressively promote โreducing binary sizeโ to enhance the user experience, reduce traffic, etc. However, if your application works with images, you have to bundle all the image decoders yourself, and each one adds dozens of megabytes to the size. As a result, the average size of an Android media application becomes far beyond any reasonable level. |
|
2026-01-28 11:07:23
|
Like https://github.com/T8RIN/ImageToolbox/releases/tag/3.5.2 has average size ~100MB per application ๐ |
|
2026-01-28 11:12:14
|
And that's not even counting that the developer would miraculously need experience with all codecs at once ๐ |
|
|
|
whatsurname
|
2026-01-28 11:36:30
|
Should link them to a single shared library instead.
For reference Tachiyomi bundled decoders for JPEG/PNG/WebP/HEIC/AVIF/JXL, and it only takes 5 MB total for arm64-v8a. |
|
|
|
jonnyawsom3
|
2026-01-28 11:45:57
|
Considering ImageToolbox's feature list, I doubt you're getting it much smaller |
|
|
|
awxkee
|
2026-01-28 11:47:07
|
There are problems that most of android developers not familiar that deep with native libraries and when you need encoding support only built AOM for aarch64 takes 5mb |
|
2026-01-28 11:48:10
|
As mentioned above it's possible in theory rebuild all libraries with linking into one library and if it's lucky day with LTO size will be reduced notably |
|
2026-01-28 11:49:30
|
The problem here it requires a lot of work for each library and reasonable understanding level how it works |
|
2026-01-28 11:49:59
|
And one can't just include external library in single lane in gradle using this approach |
|
2026-01-28 11:54:10
|
Also this wouldn't work well for GPL (libheif, de265) and any closed source applications |
|
|
|
whatsurname
|
2026-01-28 12:00:11
|
They can license the image decoder wrapper under LGPL |
|
|
|
_wb_
|
2026-01-28 01:17:02
|
I don't get why Android cannot work more like a regular linux distro, so you can just have an android app with dependencies and use shared libraries that are only installed when something actually needs it. You cannot at the same time care about binary size (traffic, install size) _and_ basically require everyone to duplicate everything constantly and use static binaries or self-shipped libraries. |
|
|
|
VcSaJen
|
2026-01-28 01:37:16
|
AFAIK there's `androidx.*` acting like a standard library that's included inside apk (instead of `android.*`, which is a part of OS), which allows you to use newer features even in older Android versions. |
|
|
|
awxkee
|
2026-01-28 01:38:10
|
androidx in it's bigger part is also compile time dependency not shared. |
|
|
|
VcSaJen
|
2026-01-28 01:38:28
|
Yeah. |
|
|
|
awxkee
|
2026-01-28 01:43:28
|
This will break their store delivery system. The mobile ecosystem is a bit different from desktop if you have conflicts, you can't just rebuild your dependencies, and they don't want to tell the user "well, not today". Even if it's not perfect, this system allows users to have hundreds of applications on their devices, many of which have dependencies that aren't compatible with each other. iOS went different way, they have more comprehensive standard SDKs so until one need something give or take specific it's possible to just use standard SDKs. |
|
2026-01-28 01:45:06
|
There are probably more reasons, but this is the first one that comes to mind. |
|
|
|
VcSaJen
|
2026-01-28 01:47:16
|
I wish image codecs were inside a hidden app upgradeable from Play Store, like WebView. |
|
|
|
whatsurname
|
2026-01-28 01:51:40
|
AFAIK there's a mainline module for video codecs, I'm not sure about image codecs though |
|
|
|
HCrikki
|
2026-01-28 05:15:47
|
post 2024/android11, play system updates can update codecs iinm. i think thats how they they brought dav1d to older android (more efficient decoder overriding the messy one they had before). |
|
|
|
jonnyawsom3
|
2026-01-28 05:26:18
|
Damn, I'm on Android 10 ๐ |
|
|
RaveSteel
|
2026-01-28 05:31:55
|
At the time JXL will be included in mainline android and delivered to phones you'll probably have bought a new device lol |
|
|
|
HCrikki
|
2026-01-28 05:32:51
|
there might be activity in unreleased upcoming releases of aosp (post 16qpr2) and lineage (23.2). not sure what to think of it |
|
2026-01-28 05:33:42
|
for old phones, best would be using apps and a webview that include the jxl support. patched webview should make it usable with apps/games displaying jxl images |
|
|
|
VcSaJen
|
2026-01-28 05:41:05
|
EPUB aside, I wonder if android E-book readers would be able to open other formats with jxl inside of them?
I tested on PC with e-book reader browser extensions with *.fb2 (on Chrome Canary and Waterfox), half of readers don't recognize jxl images, half of them display jxl just fine. |
|
|
|
jonnyawsom3
|
2026-01-28 05:41:31
|
I've just not seen a phone with anything I want yet, Apple tempted me with JXL support but the walled garden wouldn't fit with the rest of my devices. I think I can push this phone for another year, then maybe one of the Android based vendors will have picked it up |
|
|
|
HCrikki
|
2026-01-28 05:59:32
|
on codec updating methods, maybe itd be simpler to ask someone from the android video and image codecs team |
|
2026-01-28 07:31:47
|
seems firefox purged the libjxl integration and replaced it with jxl-rs (for upcoming 149.0a1 nightly, meant to go stable in late march) |
|
|
|
AccessViolation_
|
2026-01-28 07:35:41
|
woahh |
|
2026-01-28 07:35:51
|
so Firefox is still in the race! I wonder who's going to ship it on stable first |
|
|
MSLP
|
2026-01-28 07:40:20
|
My bet is on chrome, as Firefox may have to fight some regressions on msrv-1.90, and chrome was already past rustc-1.90 |
|
|
|
HCrikki
|
2026-01-28 07:41:02
|
defo chromium, its in 145 beta. not guaranteed enabled by default though even if its in stable, origin trials still needed |
|
|
|
veluca
|
2026-01-28 07:41:11
|
I would not read much in the timing of "first version" vs timing of "shipped enabled by default" |
|
2026-01-28 07:41:51
|
but the first behind-a-flag in stable will def be Chrome |
|
2026-01-28 07:41:55
|
that should be in 2 weeks |
|
|
|
MSLP
|
2026-01-28 07:45:00
|
Now that those two are somewhat settled I'm wondering what will the story on MS Edge be |
|
|
|
HCrikki
|
2026-01-28 07:50:07
|
derivatives may need their adoption delayed for 1-2 release cycles to untangle whatever they had before. (build for compile and flag for building only relevant for derivatives) and flag for use (user-facing, overridable with edge origin trial) |
|
2026-01-28 07:51:06
|
very reasonable since theyll still ship it, just with 1-2 extra months' worth of extra upstream polish.
some derivatives use not stable or extended but the lts branch of chromium that is even less frequently updated btw (ie jumping from 138 to 144) |
|
|
|
AccessViolation_
|
2026-01-28 07:51:57
|
oh yeah that's basically what I meant |
|
|
|
MSLP
|
2026-01-28 07:52:37
|
You think that was the reason MS Edge dev requested compile-disable flag for jxl in chromium?
I've read some opinion that they may not be shipping anytime soon |
|
|
|
HCrikki
|
2026-01-28 08:06:24
|
imo people misread that but its likely to have at least once cycle's worth of delay at least. |
|
|
|
MSLP
|
2026-01-28 08:11:35
|
At this point even 6 cycles (half of year) wouldn't be so bad, as long as they ship it eventually |
|
|
hjanuschka
|
2026-01-29 01:10:25
|
they explicitly asked for compile flags, to not compile the new jxl approach - guess it will take them a while |
|
|
|
VcSaJen
|
2026-01-29 03:20:30
|
MS' legal team should give it a green light first. It's taken years for AVIF, but AFAIK jxl's situation is much clearer, so it should be quicker.
As a positive, after this process they might ship it by default in the OS |
|
|
|
username
|
2026-01-29 03:24:17
|
Microsoft gating JXL makes almost no sense IMO. with AVIF it kinda made sense because it AFAIK makes uses of the AV1 decoder in the browser which Microsoft had switched out with their own system for video codecs which broke AVIF support |
|
2026-01-29 03:24:58
|
JXL doesn't have any kind of barrier like this |
|
|
|
whatsurname
|
2026-01-29 03:36:19
|
https://toot.cafe/@slightlyoff/109899372183448386
We never know what the licensing things are |
|
|
|
VcSaJen
|
2026-01-29 03:36:54
|
MS was burned too many times. They'll research any and all codecs before adding them. The speed depends on legal situation, which was worse for AVIF (hence the long time).
> which Microsoft had switched out with their own system for video codecs which broke AVIF support
That's not the whole story. AVIF was in Insider version of Edge for a year (maybe more) before it was added in release version. |
|
|
|
MSLP
|
2026-01-29 05:44:11
|
Microsoft JXL extension is already shipping from MS Store, and JXL was available (feature-gated) in MS Edge before, which makes me worry legal reasons may not be the only cause - they already should have it worked out |
|
|
|
whatsurname
|
2026-01-29 05:51:49
|
AV1 video extension was released in 2018, yet Edge didn't support AV1 until 2024 |
|
|
|
username
|
2026-01-29 05:52:28
|
question: does the WebP support in Chromium Microsoft Edge require the WebP extension from the Microsoft store? IIRC it doesn't |
|
|
|
whatsurname
|
2026-01-29 05:55:37
|
Image formats supported by Windows are pretty much irrelevant to formats supported by Edge |
|
|
|
username
|
2026-01-29 05:59:27
|
yeah I assumed since AFAIK it's just the Media Foundation they hooked into Chromium Edge and not the Windows Imaging Component system |
|
|
Cacodemon345
|
2026-01-29 06:25:31
|
WIC hasn't been hooked up to the WinUI Images app either. |
|
|
|
VcSaJen
|
2026-01-29 07:32:24
|
They likely were just waiting for browser support% before integrating it into OS. |
|
|
|
whatsurname
|
2026-01-29 03:12:19
|
I tried the latest nightly, and apparently they forgot to enable simd as well
https://bugzilla.mozilla.org/show_bug.cgi?id=2013142 |
|
2026-01-29 03:44:21
|
Discussion about requirements for shipping JXL on Firefox:
https://groups.google.com/a/mozilla.org/g/dev-platform/c/JMM5Nhdj6mc
I think it's fair to ask for the same performance as libjxl |
|
|
spider-mario
|
2026-01-29 03:52:21
|
~~maybe we shouldnโt have made libjxl quite as fast as it is~~ |
|
|
|
whatsurname
|
2026-01-29 03:57:11
|
Well it doesn't need to be as fast as libjxl completely, I think browsers mostly care about single thread performance |
|
|
|
HCrikki
|
2026-01-29 04:02:25
|
libs are already fast, its the integrations that needed to be worked on. as long as they dont block commits, itll improve faster than they cna move goalposts |
|
2026-01-29 04:04:29
|
some odd images here and there load absurdly slow on ff (like 50x slower than expectable) but lightning fast on chromium so its not some issue with jxl-rs itself when properly built. maybe simd should eliminate such edge cases already |
|
|
|
jonnyawsom3
|
2026-01-29 04:04:38
|
It only does a single thread right now anyway |
|
|
|
whatsurname
|
2026-01-29 04:08:30
|
Yeah that's because they didn't enable simd
With simd it's still 2-3x slower than the old libjxl implementation though |
|
|
|
HCrikki
|
2026-01-29 04:15:16
|
any way to automate benching the integration? there's jxl-perfhistory for checking jx-rs' performance over commits but nothing for browsers (if just to test for deviations between current and peak attainable perf) |
|
2026-01-29 04:45:03
|
on jxl use allowed in epub 3.4 spec documents, its now done |
|
|
TheBigBadBoy - ๐ธ๐
|
2026-01-29 05:17:51
|
indeed ๐
https://www.w3.org/TR/epub-34/#sec-core-media-types |
|
2026-01-29 05:19:05
|
3.4 is still a working draft tho |
|
|
|
jonnyawsom3
|
2026-01-29 05:50:32
|
It's now in Chrome Early Stable, so a few percent will get this update before full rollout in 2 weeks |
|
|
|
HCrikki
|
2026-01-29 05:51:05
|
disabled by default, needs user to enable in about:flags or origin trial active ? |
|
|
|
jonnyawsom3
|
2026-01-29 05:55:56
|
Built by default, but flag is disabled by default. Origin trial requires Helmut/Veluca to file a request <https://chromestatus.com/feature/5114042131808256> |
|
|
|
veluca
|
2026-01-29 08:37:21
|
(fwiw I would not mind y'all doing some benchmarks for me :P) |
|
2026-01-29 08:37:45
|
(either of jxl-rs itself or of the integration) |
|
|
|
hjanuschka
|
2026-01-29 09:23:09
|
going to file a origin trial |
|
|
|
veluca
|
2026-01-29 09:29:51
|
I would wait ๐ |
|
|
|
username
|
2026-01-29 09:39:12
|
might be a bit too early? we don't have progressive decoding yet and people might also be evaluating speed which we would be a little hampered by since there's no multithreading yet as well. |
|
|
|
hjanuschka
|
2026-01-29 09:42:53
|
not sending it for API-Owners review, just filled out the paperwork fields |
|
|
|
jonnyawsom3
|
2026-01-29 09:44:18
|
Yeah not yet, especially since we know The Guardian fails to load images until jxl-rs v0.3, which is only in Canary for now |
|
|
|
veluca
|
2026-01-29 09:48:06
|
wait also in v0.3? |
|
2026-01-29 09:48:18
|
I thought it was fixed in 0.3, and the issue was in 0.2.x |
|
|
|
jonnyawsom3
|
2026-01-29 09:48:59
|
Yeah that's what I mean sorry, broken *until* v0.3, so it's fixed now but only in Canary |
|
|
|
veluca
|
2026-01-29 09:50:04
|
ok good ๐คฃ |
|
|
|
HCrikki
|
2026-01-29 10:26:48
|
for chrome's origin trials you can specific the versions you want it tested for - namely ones with 0.3.0 or newer |
|
|
|
jonnyawsom3
|
2026-01-29 10:43:59
|
Well we probably still want progressive decoding before putting it into the wild |
|
|
|
whatsurname
|
2026-01-30 01:29:10
|
Is an origin trial possible though? They tried to do one for AVIF but gave up because you need to manipulate the accept header and the origin trial state is not known by then.
A finch experiment is probably more feasible.
The AVIF CL: https://crrev.com/c/2145570 |
|
2026-01-30 06:22:45
|
Did a little more testing with https://random-stuff.jakearchibald.com/apps/img-decode-bench/?demo=fox.jxl on x64 |
|
|
|
monad
|
2026-01-30 07:37:51
|
Everyone thought it was Jim Bankowski, but it turns out Jake Archibald is the final boss for JPEG XL. |
|
|
|
veluca
|
2026-01-30 07:38:03
|
I don't believe the chrome libjxl v0.7 numbers ๐ |
|
|
|
whatsurname
|
2026-01-30 08:25:49
|
It's from https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/1081632/ if you want to test yourself |
|
|
|
hjanuschka
|
2026-01-30 08:26:40
|
as in so many topics, i am not an expert in origin trials, but i got told there is a way that an origin trial can be enabled via response header in html, that then puts the feature flag on for sub requests.
however, guess, when it failed on avif, it will faile the same on jxl |
|
2026-01-30 08:28:54
|
can we do a channel/thread (god i hate discord) or so - with a concrete TODO list what is needed, who will do what part, to get this done? rn it is like a elephant in the room |
|
2026-01-30 08:29:29
|
and get a common understanding what variation of decoding will be "progressive" for endusers in chrome |
|
2026-01-30 08:30:24
|
i think the faster we progress with that the more realistic it will to move on, or other way around, i am afraid the longer it takes, the harder it will to justify the on-by-default |
|
2026-01-30 08:30:52
|
and it smells like we are not soooo far away, the finishing line is in sight already (atleast that is what i tell myself everyday) |
|
2026-01-30 08:31:02
|
/almost-rant-offf |
|
|
|
VcSaJen
|
2026-01-30 09:46:00
|
My results. |
|
|
|
whatsurname
|
2026-01-30 10:10:08
|
It seems Thorium is using libjxl v0.10.3 |
|
|
|
jonnyawsom3
|
2026-01-30 10:14:32
|
I wonder what gave such a speedup |
|
|
|
_wb_
|
2026-01-30 10:30:40
|
it would be good to know
1) which ones are using MT and which ones are doing single-core (jxl-rs always single-core, but maybe waterfox does MT?)
2) which highway targets are compiled in and what compiler settings were used
3) how much of this measured time is spent in libjxl/jxl-rs itself vs in glue code / stuff done outside, like e.g. colorspace conversions or pixel buffer copying/reformatting |
|
|
|
AccessViolation_
|
2026-01-30 10:35:27
|
we have the `criterion` benchmarking library in `jxl-rs/jxl_cli` at least. I haven't tested it out though but criterion is *really* nice |
|
2026-01-30 10:36:07
|
gonna give that a go and see which parts are actually benchmarked |
|
|
|
jonnyawsom3
|
2026-01-30 10:36:10
|
Waterfox is fully threaded Main libjxl |
|
|
|
whatsurname
|
2026-01-30 11:26:08
|
Actually Firefox was multithreaded too, that explains why it's faster than Chromium's libjxl implementation |
|
2026-01-30 11:51:41
|
Fixed, also tested against cli |
|
|
|
veluca
|
2026-01-30 11:52:40
|
I am surprised that jxl-rs and libjxl chromium are so close |
|
2026-01-30 11:55:35
|
what's your CPU? |
|
|
|
whatsurname
|
2026-01-30 11:56:12
|
i5-7300HQ |
|
|
|
veluca
|
2026-01-30 11:57:25
|
mh, feels like a potential bug in libjxl 0.7, but maybe not |
|
2026-01-30 11:58:22
|
shouldn't be slower than jxl-rs on my phone (which has no SIMD for some fairly expensive parts) |
|
|
|
jonnyawsom3
|
2026-01-30 11:59:40
|
It does seem a bit weird the results are near-identical |
|
|
|
HCrikki
|
2026-01-30 12:01:10
|
on waterfox, i think its built on firefox ESR (140.7) so whatever it did didnt depend on newer FF versions - cleanly backportable? |
|
|
|
VcSaJen
|
2026-01-30 12:04:19
|
Mine is i5-10400F, Windows 10 |
|
|
|
whatsurname
|
2026-01-30 12:17:00
|
djxl v0.7 is 35% faster, so I guess something went wrong on the Chromium integration |
|
|
|
HCrikki
|
2026-01-30 01:09:30
|
seems Brave nightly now builds the jxl support starting 1.88.81 (based on 145), with users able to enable decoding in about:flags |
|
|
|
whatsurname
|
2026-01-30 01:16:41
|
The build flag is enabled by default, I assume most Chromium forks (except Edge) won't bother to disable it |
|
|
adap
|
2026-01-31 12:38:18
|
sorry for dumb question but why is jxl-rs so slow wasn't the whole point of it to be faster than libjxl |
|
|
|
username
|
2026-01-31 12:41:39
|
the point was to have a full decoder in Rust from the official team that's either on par *or* better then libjxl |
|
2026-01-31 12:45:52
|
Mozilla said they wouldn't support JXL unless there was a official decoder in Rust |
|
|
|
jonnyawsom3
|
2026-01-31 01:06:50
|
Slow in what way? It's not multithreaded yet, but setting libjxl to 1 thread too they're pretty much on-par |
|
|
|
adap
|
2026-01-31 01:08:34
|
I was under the impression that this was because they thought it'd be faster and more secure if it was made in rust |
|
2026-01-31 01:10:24
|
I see how come it isn't multithreaded yet? Has it not been implemented on the github yet or just the browser? |
|
|
|
jonnyawsom3
|
2026-01-31 01:11:49
|
Not on GitHub yet, there's only so many devs and conformance came before performance. Currently progressive is the next goal, as browsers generally only use 1 thread per image anyway |
|
|
|
monad
|
2026-01-31 01:30:15
|
Rather, performance has been considered from the outset, that's part of why it wasn't just built on jxl-oxide. Things just take time. |
|
|
|
whatsurname
|
2026-01-31 01:42:52
|
I thought they mostly care about single thread, but I'm not sure now since Firefox did use full threads for libjxl |
|
2026-01-31 01:56:54
|
I just realized libavif uses 512x512 as the default minimum tile size, so in practice Chromium will usually use 1 thread for AVIFs <= 512x512, and 2 threads for larger ones |
|
|
|
_wb_
|
2026-01-31 09:04:23
|
No, the _speed_ of libjxl was fine, the reason why Firefox and Chrome want a Rust implementation is _security_. The whole point is to use a memory-safe language instead of C++, since historically buffer overflows etc have often caused vulnerabilities. |
|
2026-01-31 09:07:53
|
It's a valid point, just somewhat strange that for jpeg, webp, avif it was considered fine to add thousands of lines of C++ code to the browser, but somewhere just after adding avif, it became completely unacceptable. |
|
|
|
veluca
|
2026-01-31 09:12:07
|
timing checks out ๐ |
|
2026-01-31 09:12:59
|
and it's not like they aren't trying to get rid of the C(++) jpeg/webp/png/avif/... ๐ |
|
2026-01-31 09:13:12
|
(in particular in Chrome now png is Rust) |
|
|
|
_wb_
|
2026-01-31 09:15:04
|
I suppose ultimately the goal is to rewrite the whole browser in Rust |
|
2026-01-31 09:16:56
|
does feel a bit unfair though to compare a C++ plus hand-written asm avif decoder with jxl-rs |
|
2026-01-31 09:19:22
|
Then again, there is no _fundamental_ reason why a Rust implementation should be any slower than the best hand-written asm. That's in the end just a question of compiler quality. |
|
|
|
whatsurname
|
2026-01-31 09:19:32
|
The AVIF decoder in Chromium is rust + asm though |
|
|
|
_wb_
|
2026-01-31 09:20:01
|
ah is it? I thought it was dav1d? |
|
|
|
whatsurname
|
2026-01-31 09:21:12
|
dav1d is C + asm, the container decoder is in Rust, so no C++ involved |
|
|
|
_wb_
|
2026-01-31 09:22:26
|
oh, right, I was talking about the payload decoder, that's the thing that influences speed more than the wrapper stuff |
|
2026-01-31 09:26:36
|
I don't think C and asm are considered _better_ than C++ in terms of security |
|
|
|
veluca
|
2026-01-31 09:36:25
|
(they are not) |
|
2026-01-31 09:36:44
|
and security people don't like the ASM either ๐ |
|
|
|
whatsurname
|
2026-01-31 09:37:22
|
Yeah but they need to support AV1 anyway
The good thing about AVIF is you get it for (almost) free when you need to support AV1, the bad thing is libaom + dav1d are pretty heavy when you only care about images |
|
|
|
veluca
|
2026-01-31 09:37:34
|
but doing things like inline ASM that doesn't access memory is fine |
|
|
|
0xC0000054
|
2026-01-31 10:01:14
|
Out of curiosity what would 'not accessing memory' be, just manipulating registers? I have used x86 ASM when reverse engineering games and writing memory patches to mod them, but I am not very proficient in it. |
|
|
|
veluca
|
2026-01-31 10:01:34
|
yeah for example |
|
2026-01-31 10:02:11
|
things like https://github.com/libjxl/jxl-rs/blob/main/jxl_simd/src/aarch64/neon.rs#L456 |
|
2026-01-31 10:02:57
|
(or even asm that *does* access memory, as long as the memory access can be shown to be safe, I guess) |
|
|
|
VcSaJen
|
2026-01-31 08:03:24
|
Double Commander now supports JPEG XL:
https://github.com/doublecmd/doublecmd/wiki/Changes-in-version-1.2.0 |
|
|
Demiurge
|
2026-02-01 10:04:50
|
Official is such a weird word for them to use. So if someone else were to come along and suddenly release a very good jxl codec that met all the criteria they want, they wouldn't accept it because it's a different author? What pettiness is that? |
|
2026-02-01 10:09:02
|
Or maybe they're using that language to specifically and deliberately exclude jxl-oxide for some reason I never understood |
|
2026-02-01 10:12:04
|
Since if jxl-rs has a similar interface , work on browser integration could begin immediately and the libraries can be swapped out later when it makes sense |
|
|
|
jonnyawsom3
|
2026-02-01 10:17:47
|
Browser integration is already finished, and it was because they want a guarantee of long term support, not a repo made by a single person |
|
|
|
Demiurge
|
2026-02-01 10:28:19
|
There are never any guarantees regardless, realistically speaking. Are they purchasing a contract? |
|
|
|
veluca
|
2026-02-01 11:04:43
|
finished is such a strong word |
|
|
|
jonnyawsom3
|
2026-02-01 11:06:05
|
Browser side is pretty much done AFAIK, just calling into jxl-rs for the next render. The library itself still has a while to go though |
|
|
|
veluca
|
2026-02-01 11:09:06
|
integrating progressive properly, and dealing better with animations (and possibly CMYK) are still nontrivial TODOs |
|
|
|
Demiurge
|
2026-02-02 04:25:12
|
We are talking about free open source code provided as-is without explicit or implied warranties or guarantees of any kind. Not even "fitness for a particular purpose." So the words "officially supported" seem kinda absurd |
|
2026-02-02 04:26:15
|
Free code is free code. |
|
2026-02-02 04:27:12
|
Regardless if it comes from Google, facebook, some student at uni, aliens, the NSA, or some random kid from another country. |
|
|
|
ignaloidas
|
2026-02-02 04:33:17
|
on one hand - absolutely yes, on another hand - whether there's more than "one guy" certainly matters for chosing dependencies for larger projects anyways |
|
|
|
whatsurname
|
2026-02-02 04:56:51
|
Tbf neither Chromium nor Firefox explicitly said it has to be "official", all theyโre asking for is memory-safe, performant, and long-term maintenance.
Having an official implementation do increase confidence though |
|
|
|
Demiurge
|
2026-02-02 06:24:13
|
It looks like the Chrome team set aside some devs to work on jxl-rs as well |
|
2026-02-02 06:24:32
|
And contribute patches upstream |
|
|
|
veluca
|
2026-02-02 07:49:05
|
uh, no? |
|
|
|
whatsurname
|
2026-02-02 08:00:47
|
You meant @ hjanuschka ? He's an external contributor |
|
|
|
hjanuschka
|
2026-02-02 08:24:39
|
i am doing my best to invest as much time as possible, but yes, i am not contractually bound to anything!! dobby is a free elf! but this whole journey went way too far, quitting is not an option anymore anyway ๐
talking with a few folks, if my company and/or others can step in, i am having a huge interest from my employer, as we'd save tons of โฌ's if we could use jxl (sadly that would require closing the loop, and having it at akamai) |
|
2026-02-02 08:25:54
|
and as soon as the adoption rate, reaches a critical mass, i guess the "maintaince" topic is not a big deal anymore! |
|
2026-02-02 08:27:35
|
large corps contribute for free as soon as it is business critical (atleast where i am at).
as soon as my mgmt sees we can save money, we'd be allowed (forced ๐) to work on it! |
|
|
lonjil
|
2026-02-02 08:58:06
|
Just because something is in the license doesn't mean it's absolute. The jxl team at google have affirmed repeatedly that they will be maintaining it. |
|
|
|
veluca
|
2026-02-02 10:23:16
|
let's say that it might make sense to say "we don't want to legally promise, but we promise" ๐ |
|
|
|
spider-mario
|
2026-02-02 11:41:42
|
โwe promise weโll put in the effort; we canโt promise anything with 100% certainty as to the end resultโ |
|
|
|
hjanuschka
|
2026-02-02 11:58:23
|
i know pdf has not yet formally standardized it but who cares ๐
https://www.januschka.com/pdfium-jxl.html here is a sample PDF with JXL files and how they'd render in pdfium |
|
2026-02-02 11:58:44
|
not sure if keep or kill ๐ but was easier than thought! pdfium had rust based PNG already : |
|
2026-02-02 11:58:57
|
sure thing, no animations, but thats good ๐ |
|
|
|
lonjil
|
2026-02-02 01:09:21
|
nice :) |
|
|
|
hjanuschka
|
2026-02-02 01:20:33
|
ok now trying to figure out how the spec is made in pdf, and who does it ๐ - any help appreciated |
|
|
Quackdoc
|
2026-02-02 01:39:54
|
animations in a pdf... yeah I'm not exactly heartbroken about this loss lol |
|
|
|
hjanuschka
|
2026-02-02 01:40:17
|
hahahah |
|
2026-02-02 01:40:26
|
theo. PDF could do it, i mean it can run doom! |
|
2026-02-02 01:40:36
|
but i am not pursuing another round of animation madness |
|
|
|
AccessViolation_
|
2026-02-02 01:42:10
|
if you don't like animations in PDF, I'm guessing it's because your printer isn't fast enough |
|
2026-02-02 01:43:10
|
get yourself a nice 60 pages per second model |
|
|
|
RaveSteel
|
2026-02-02 01:44:24
|
https://www.youtube.com/watch?v=oEqvYXYI56s |
|
|
|
AccessViolation_
|
2026-02-02 01:44:53
|
oh my god XD |
|
|
|
hjanuschka
|
2026-02-02 01:53:26
|
oh god, do not trigger me!!! ๐ |
|
|
Exorcist
|
2026-02-02 02:30:42
|
When Mozilla say "official decoder", it means "Google pay us money" |
|
|
|
VcSaJen
|
2026-02-02 02:48:29
|
AFAIK both Firefox integration and jxl-rs are not 100% ready yet, so complaining about Mozilla's attitude towards JPEG XL is premature. |
|
|
|
lonjil
|
2026-02-02 03:42:00
|
Eh? That doesn't make any sense. |
|
|
|
HCrikki
|
2026-02-02 06:38:24
|
dicom-related https://aws.amazon.com/about-aws/whats-new/2026/01/aws-healthimaging-adds-jpeg-xl/ |
|
|
|
AccessViolation_
|
2026-02-02 06:44:06
|
ah that's a shame |
|
|
|
MSLP
|
2026-02-02 06:45:24
|
And do you know how does cloudinary image cdn compare to akamai image cdn? I gueess akamai cdn can serve other things than images so it's kinda comparing apples to oranges. But in that case why jxl couldn't be served as other "raw files", with recoding via "in house" service? |
|
|
|
Demiurge
|
2026-02-02 08:04:07
|
He's not from the Chrome team? |
|
|
|
jonnyawsom3
|
|
|
A homosapien
|
2026-02-02 08:17:52
|
Doing it for the love of the game <a:CatYes:806636752952754186> |
|
|
|
hjanuschka
|
2026-02-03 07:45:04
|
we have one backend image format, and use akamai's image-manager product to server in dynamic format, depending on end-user device, location, app, image itself (sometimes avif, sometimes webp), we also use resizing, and smart cropping (finding persons and stuff).
we cannot really (in an economical way) 'if' out this thing and do a JXL dance - i wont get the internal resources in house - but i am in contact with a few akmai folks trying to somehow;idk how; make it happen! |
|
2026-02-03 07:45:35
|
and yes i am not with google, just here, because i thought "o well this will be done in a day - lets do it" - hahahahah that was in november, and i have no such deep background then most of you here, i am just a guy with a hammer ๐จ |
|
2026-02-03 07:47:15
|
(but, long term, i really see the benefit for my employer, and fellow competitors) |
|
|
|
MSLP
|
2026-02-03 06:01:50
|
Judging by amount of work you managed to get done in such short time period you're the guy with a hammer, sledgehammer, excavator and 20 years of experience ๐
I think many people here have no background at all, eg. me, I just stumbled across jon's FLIF years ago then some years later learned that JPEG XL is its final successor.
Anyway the whole "with google" tends to be weird here, since here more than everywhere people seem to know the distnction between Google Research Zurich (aka #teamveluca) and other branches of Google, especially the Google Chromium Team.
Thank you for your contributions to the ecosystem. |
|
|
|
veluca
|
2026-02-03 06:31:07
|
> #teamveluca
this made me laugh ๐ |
|
|
|
hjanuschka
|
2026-02-03 06:43:12
|
and its actually veluca reviewing all the crap i sent to him ๐ |
|
2026-02-03 06:43:35
|
and the heavy lift is jxl-rs, the chromium part was (lets put animations aside) a piece of cake |
|
2026-02-03 06:43:55
|
yet i love - being part of it! - and its amazing how fast things can go if you just-do(tm) |
|
|
|
_wb_
|
2026-02-03 06:57:40
|
"just do it" is a trademark of one of our customers |
|
2026-02-03 06:58:37
|
but yeah generally the best way to get things done is by just doing them, lol that sounds rather trivial if you put it like that ๐ |
|
|
|
hjanuschka
|
2026-02-03 08:26:38
|
not sure how this at your companies, but here in my corp and the corps we work with, we are specialised in doing things just to not do the things required todo ๐ |
|
2026-02-03 08:26:52
|
(to find arguments why we have certain folks/positions around) |
|
2026-02-03 08:26:56
|
compared to opensource, "i just want this to work" /rantoff |
|
|
|
AccessViolation_
|
2026-02-03 08:27:11
|
completely unrelated, do you know how the dithering of VarDCT images will be handled?
the behavior of libjxl is to dither VarDCT because the color data is f32, which needs to be quantized to the display bit depth. since it dithers at the image pixel level, it's visible when you zoom in. does chromium do it like this too, or does it request a higher bit depth from jxl-rs and dither it natively at the frame buffer/gpu level? |
|
|
|
hjanuschka
|
2026-02-03 08:28:00
|
need to pass this to <@179701849576833024> |
|
|
|
veluca
|
2026-02-03 08:28:48
|
atm Chromium uses u8 for sdr images |
|
|
|
AccessViolation_
|
2026-02-03 08:30:29
|
hm, does chromium have the necessary parts to hook into so this could be done natively by chrome in the future? for example, I seem to remember that CSS gradients are dithered too, but that could be inaccessible to the image pipeline |
|
2026-02-03 08:31:13
|
(not a request, just asking to get an idea of the chance this will change in the future. I suck at communicating, sorry if I sound needy) |
|
|
|
jonnyawsom3
|
2026-02-03 08:32:18
|
The way libjxl works is it'll dither if the file bitdepth is higher than the requested output bitdepth, so lossless 10bit also gets dithered for 8bit displays
Odds are we'll just port the blue noise dithering we put into libjxl recently, but we thought we'd wait until the rest of jxl-rs is a bit more complete to avoid speed regressions this early into support |
|
|
|
veluca
|
2026-02-03 08:33:40
|
actually maybe that's not true |
|
2026-02-03 08:34:01
|
<@623776984987729940> do you remember how we choose f16? do we choose f16 for high bit depth too? |
|
2026-02-03 08:34:41
|
because if so, we could just assume that Chrome takes care of it (or make Chrome take care of it) in the rendering path to SDR -- would look much much nicer if downsampling... |
|
|
|
hjanuschka
|
2026-02-03 08:35:11
|
i think we did, and realized chromes pipelines keep care of it |
|
|
|
_wb_
|
2026-02-03 08:53:01
|
I'm too familiar with things like Kanban boards on Jira and quarterly planning meetings and prioritization/alignment meetings between teams etc etc which are all essentially ways to talk about in the future doing stuff โ or not, or maybe, or as a P2 that might become a P1 if you can find the right person to convince but only the P0 stuff ever gets done anyway โ instead of actually doing stuff. [/rant] |
|
|
|
hjanuschka
|
2026-02-03 08:54:35
|
feel you ๐ - and oss is kinda like my mental health programm, i pick what i want, and push it aslong as i want |
|
|
|
_wb_
|
2026-02-03 08:55:34
|
Doesn't Chrome usually do downsampling on the GPU in whatever cheapest way the GPU can do it, which I expect will usually be some cheap bicubic filter without any dithering? |
|
|
|
veluca
|
2026-02-03 08:56:01
|
not sure how it gets done in practice, never looked at that part of the code tbh |
|
|
|
_wb_
|
2026-02-03 09:01:21
|
I mean, if we can get the downscaling in general to improve, that would be nice, but I suspect there will be perf pushback. You can have animated transitions and whatnot that can mean you need a different downscale (or whatever other transform css allows) every single frame, so I think they're going to want to keep doing something cheap (which means not gamma-corrected downscaling but just doing it in display space, no fancy filters, no dithering) |
|
|
|
veluca
|
2026-02-03 09:02:31
|
blue noise dithering with a fixed map (or a couple of fixed maps) ought to be almost free on GPU |
|
|
|
_wb_
|
2026-02-03 09:15:50
|
I may be just speculating but I think they're using 8-bit yuv420 texture buffers when the image is 420, 8-bit RGBA when it isn't and then use native GPU primitives to do affine transformations with those. |
|
2026-02-03 09:16:20
|
(in the SDR case) |
|
|
|
cioute
|
2026-02-04 09:19:45
|
maybe already knowed but Fossify gallery updated and now you can zoom jxl, avif and webp on android at decent level
but jpeg and png zooms faster and clearly
for me this is big news because other image formats (not jpeg and not png) became quite usable as files on devices |
|
|
|
Quackdoc
|
|
|
hjanuschka
|
2026-02-04 11:15:15
|
my terminal can now render JXL! |
|
2026-02-05 12:10:28
|
ghostty next! |
|
2026-02-05 12:11:22
|
|
|
2026-02-05 12:11:41
|
(except the hair, this is pretty realistic footage!; and i quit smoking years ago!) |
|
|
|
Quackdoc
|
2026-02-05 12:29:52
|
Kitty is nice, waiting for the day cosmic terminal starts supporting that stuff |
|
|
|
hjanuschka
|
2026-02-05 12:30:41
|
ghostty ๐ |
|
|
|
whatsurname
|
2026-02-07 02:58:48
|
Tested the image in https://github.com/libjxl/jxl-rs/issues/636 with Firefox since it now supports animation, and it did pretty well (loading instantly and using a sane amount of memory).
However, Chrome somehow gets worse.
On 7657, memory usage will steadily grow to 3 GB and stay there.
On 7674, memory usage will go all the way to 6 GB and drop back to 3 GB after all data is received. |
|
|
|
hjanuschka
|
2026-02-07 05:55:25
|
cc <@179701849576833024> |
|
2026-02-07 05:56:18
|
how much does it end up with in FF? |
|
|
|
veluca
|
2026-02-07 05:57:32
|
Smells like this got decoded twice? I'll need to check |
|
2026-02-07 05:58:09
|
Although since we'll most likely rewrite the animation logic I am not sure we should worry about it right now |
|
|
intelfx
|
2026-02-07 07:18:28
|
soooo.
pursuant to the last discussion (https://discord.com/channels/794206087879852103/794206087879852106/1463751243103997953), copyparty _is_ fully jxl-aware now |
|
|
|
adap
|
2026-02-08 12:11:25
|
hope ff is working on hdr jxl too |
|
|
|
whatsurname
|
2026-02-08 02:37:46
|
Memory? Around 200-400 MB.
I also noticed Chrome's CPU usage falls to < 5% once the memory usage is back to 3 GB, while it's always 100% (single core) for Firefox.
I guess Chrome decodes all frames in advance and Firefox decodes them on demand. |
|
|
screwball
|
2026-02-08 03:11:05
|
Blender 5.1 is getting AVIF
Hopefully they also add JXL
I was trying to do it myself months ago but Iโm super busy now
Someone should beat me to it
At LEAST get lossy in there because it uses floating point |
|
|
|
username
|
2026-02-08 03:43:28
|
It's probably just going to be tonemapped to SDR. Firefox probably isn't going to get full HDR output support for still images until years in the future |
|
2026-02-08 03:44:19
|
for their AVIF support are they going to make use of the depth channel that AVIF supports? could be a indicator of if they will make use of JXL's depth channel in the future |
|
|
|
VcSaJen
|
2026-02-08 05:50:25
|
Support for renders or for textures? |
|
|
|
username
|
2026-02-08 05:52:10
|
for renders. I wouldn't know what cases it could be useful for textures unless it's something you are overlaying onto the screen maybe |
|
|
|
jonnyawsom3
|
2026-02-08 06:13:21
|
I saw that a few weeks ago. I wanted to ask them if they'd try doing JXL in tandem since they know what they're doing, but I very much doubt anyone's going to do it without incentive. 3 PRs have already been rejected from going stale |
|
2026-02-08 06:15:11
|
AVIF has a depth channel? |
|
|
|
adap
|
2026-02-08 07:48:31
|
Damn thatโs the whole reason I want jxl |
|
|
|
HCrikki
|
2026-02-11 12:58:35
|
chrome 145 stable rolling in and jpegxl is apparently in origin trial ? |
|
|
|
username
|
2026-02-11 01:03:11
|
it's not really ready for an origin trial |
|
2026-02-11 01:04:32
|
the info/form for a origin trial was filled out just to have it done but as for the actual trialing part it really isn't ready in some aspects tbh |
|
2026-02-11 01:05:15
|
er well I half forgot exactly what an origin trial is |
|
2026-02-11 01:05:35
|
but ill say that there's currently no progressive decoding and no multithreading yet |
|
|
|
HCrikki
|
2026-02-11 01:05:52
|
isnt it meant to prepare for wider availability with a limited number of participating sites? specific chrome versions could be required, as in the ones including a minimum version/commit of jxl-rs |
|
|
|
whatsurname
|
2026-02-11 02:26:45
|
The current implementation does not support running an origin trial anyway
But origin trials aren't the only way to experiment, 1% rollout is another option |
|
2026-02-11 02:29:57
|
Even then it won't be 145 because it's on jxl-rs 0.2.2 |
|
|
|
jonnyawsom3
|
2026-02-11 03:46:16
|
Probably after progressive loading is in a release |
|
2026-02-11 03:46:22
|
Maybe... Ish |
|
|
|
adap
|
2026-02-11 04:55:22
|
origin trial? |
|
2026-02-11 04:55:32
|
whats that |
|
|
|
HCrikki
|
2026-02-11 04:59:51
|
a way for browsers to forcefully activate a specific flag (for a predetermined list of websites), without needing millions of chrome users to manually enable it themselves |
|
2026-02-11 05:01:50
|
itd be a serious challenge to have even just 10000 users manually enabling the flag if they even knew it existed |
|
|
|
adap
|
2026-02-11 05:09:25
|
oh sounds cool but what's the point of having it for certain websites if none of them have jxl images |
|
|
|
whatsurname
|
2026-02-11 05:10:00
|
The websites need to apply first |
|
|
|
adap
|
2026-02-11 05:11:45
|
ah okay |
|
2026-02-11 05:12:05
|
im guessing the jpeg xl site will be first lol |
|
|
|
jonnyawsom3
|
2026-02-11 05:17:32
|
The jpegxl.info site is a community one hosted on Github, so I'm not sure we even could |
|
|
|
HCrikki
|
2026-02-11 05:22:08
|
some types of sites are suitable to provide feedback about the performance/server/userfacing impact difference. for example social networks, news sites, image hosts, CDNs - either way they should be big and active enough a difference could be quantifiable |
|
|
|
whatsurname
|
2026-02-11 05:22:08
|
It can be done with <meta> tag |
|
|
|
hjanuschka
|
2026-02-12 08:58:43
|
https://tenor.com/view/jumanji-robinwilliams-what-year-is-it-gif-21118575 |
|
2026-02-12 08:58:48
|
145 is stable ๐ |
|
2026-02-12 08:58:57
|
crazy, how fast time flies! |
|
|
|
username
|
2026-02-12 09:00:48
|
I'm still waiting for 146! (it's the version that forks of Chromium will switch to off of 144) |
|
2026-02-12 09:02:18
|
I wonder if progressive decoding will make it in before then ๐ค |
|
|
|
whatsurname
|
2026-02-12 10:59:23
|
146 has branched from main, so it would be harder to merge to |
|
|
|
5peak
|
2026-02-12 11:11:09
|
R3L04D3D:// SGI:// CRAYz:// time_t now! |
|
|
|
_wb_
|
2026-02-12 01:11:30
|
https://aws.amazon.com/about-aws/whats-new/2026/01/aws-healthimaging-adds-jpeg-xl/ |
|
2026-02-12 01:17:38
|
https://w3c.github.io/pm-wg/minutes/2026-01-29.html#38dc |
|
|
|
veluca
|
2026-02-12 05:08:44
|
https://wpt.fyi/interop-2026 |
|
2026-02-12 05:08:57
|
(and https://github.com/web-platform-tests/interop-jpegxl) |
|
|
|
whatsurname
|
2026-02-12 05:16:09
|
Investigation, not unexpected, still good |
|
|
|
veluca
|
2026-02-12 05:16:37
|
I'll take it as a win ๐ |
|
|
|
whatsurname
|
2026-02-12 05:18:33
|
Definitely an impressive step towards the goal |
|
|
|
VcSaJen
|
2026-02-12 06:05:50
|
Hopefully this means Safari will take steps towards progressive JXL |
|
|
|
hjanuschka
|
2026-02-12 08:13:15
|
that is a huge win!! |
|
|
|
HCrikki
|
2026-02-13 01:41:57
|
unrelated but Brave quickly moved jxl support through beta and now its apparently in stable 1.87.186 based on v145 (user needs to enable it in about:flags)
same for Cromite |
|
|
|
adap
|
2026-02-13 02:50:34
|
what ig they normally lag behind base chrome? |
|
|
|
whatsurname
|
2026-02-13 03:17:06
|
It's just their regular 4-week release schedule, same as Chromium |
|
|
Meow
|
2026-02-13 09:16:42
|
Meanwhile JXL thumbnails are still broken on macOS 26.3 |
|
|
|
hjanuschka
|
2026-02-13 10:06:59
|
following the interop -> https://github.com/web-platform-tests/wpt/pull/57771 ๐ getting somewhere! (WIP!) |
|
|
Jabster28
|
2026-02-13 11:22:28
|
cool, is there a way contributors can help with this? anything else that needs doing? or is it mostly waiting now? |
|
|
|
hjanuschka
|
2026-02-13 02:58:49
|
I donโt really know ๐ Just talking about it, getting the ball rolling! Trying to make people aware of JXL and nudge their partners to support it too.
i try to make it happen that chrome will be 100% passing all these tests, and then lets hope when it's in WPT other vendors follow |
|
|
KKT
|
2026-02-13 09:15:55
|
Yes, first thing I checked. |
|
2026-02-13 09:24:14
|
Keep filing those bug reports. Only 10 other similar onesโฆ |
|
|
|
adap
|
2026-02-13 10:32:14
|
where do you even report that stuff |
|
|
|
hjanuschka
|
2026-02-13 11:15:29
|
https://developer.apple.com/bug-reporting/ |
|
2026-02-13 11:15:38
|
have fun, i still have issues open from iphoneOS2.5 ๐ |
|
2026-02-13 11:15:55
|
and they just closed one years later from ios3 with "cannot reproduce please provide details" ๐ |
|
|
derberg๐
|
2026-02-14 12:25:17
|
Are they public somewhere? |
|
|
|
username
|
2026-02-14 02:26:10
|
a fork of FreeImage (a library for handling multiple image formats) called FreeImage Re(surrected) now has JXL support: https://github.com/agruzdev/FreeImageRe/releases/tag/v4.1.0 |
|
|
|
whatsurname
|
2026-02-14 09:35:46
|
Edge 145 is out without JXL support, which is not unexpected as they explicitly ask for a build flag |
|
|
|
hjanuschka
|
2026-02-14 08:57:28
|
sir i have no clou how radar works, i doubt its public! |
|
2026-02-14 08:57:53
|
wonder if they use "their" jxl implementation, and (i guess) libjxl, or they use the upstream jxl-rs one |
|
|
|
derberg๐
|
2026-02-14 09:09:15
|
Was my way to also probe a bit if you could share a few, heh (โ then maybe in <#806898911091753051> if it is long)
(also I think informal language is fine in this community I think, in case you are not just jokingly using sir) |
|
|
|
whatsurname
|
2026-02-15 03:42:19
|
I don't think they'll use a different implementation, it's probably something else they're evaluating |
|
|
|
Demiurge
|
2026-02-15 06:06:40
|
|
|
2026-02-15 06:06:41
|
Holy cow lol, the amount of shade this guy is getting on reddit. From what I can tell, this actually looks pretty cool and I hope the guy is not discouraged by all the criticism he's getting on reddit. |
|
|
|
VcSaJen
|
2026-02-15 06:33:43
|
That's not criticism, that's just being obtuse. It's a shame that redditors are like that.
I don't have a reddit account. Did you send encouragement as a root-level comment? |
|
|
NovaZone
|
2026-02-15 07:20:31
|
So basically jxl "lossless" jpg/jpeg transcoding with a file type indexer? |
|
|
|
Demiurge
|
2026-02-15 07:27:34
|
You think I have a reddit account? No lol |
|
2026-02-15 07:30:11
|
I barely even have a discord |
|
|
|
Jabster28
|
2026-02-15 08:38:06
|
it seriously reads like that has a problem with software... existing? as if making something niche is a crime |
|
2026-02-15 08:38:18
|
maybe he's an avif fan or something ๐ |
|
2026-02-15 08:40:05
|
ah yeah, he's one of the mods on r/AV1. surely that's a conflict of interest |
|
|
|
adap
|
2026-02-15 08:45:04
|
jeez looking at this guys comment history |
|
2026-02-15 08:45:19
|
bro is insufferable |
|
2026-02-15 08:48:06
|
epitomy of "well actually" |
|
|
|
Jabster28
|
2026-02-15 08:50:26
|
i kinda wanna argue w him but a) i doubt he'll change his mind and b) the comment's too deep that idk if people are even reading it |
|
|
|
VcSaJen
|
2026-02-15 08:50:59
|
Yeah arguing is not helpful to the dev |
|
|
|
adap
|
2026-02-15 08:51:02
|
just downvote him bros chronically online he'll be thinkg about it for weeks |
|
|
|
whatsurname
|
2026-02-15 09:24:12
|
Idk, that looks like an ad to me. Limited features (only lossless JPEG transcoding), lackluster UI, + AI-generated icon/intro.
It might be cool as a toy project, but claiming it's the go-to choice on Mac? Nah |
|
|
|
monad
|
2026-02-15 09:31:41
|
gottem |
|
|
|
VcSaJen
|
2026-02-15 09:42:36
|
> toy project
Can you afford to say that when lossless transcode is basically never there? I know only of cjxl, Image Toolbox (NOT the default; buried under tons of menus to access it) and XL Converter. That's it. |
|
|
|
AccessViolation_
|
2026-02-15 09:47:46
|
seriously, anyone engaging in this manner does *not* make a good moderator, it's a little concerning. if I was part of the r/AV1 mod team I'd have a serious chat with them about their behavior as a mod
though I guess this was in a different community, but still |
|
|
|
VcSaJen
|
2026-02-15 09:48:15
|
Reddit comment claims that XnView MP also supports it... But it does pixel encode by default, and I couldn't find separate transcode mode even after searching all the menus (there's only lossless rotation and mirroring, no jxl). |
|
|
|
Demiurge
|
2026-02-15 09:48:26
|
Yeah, it's an ad, but it's for software that automates trancoding and makes it easier to use jxl from what I can see. It makes sense if it has limited features since it specializes in lossless and verifiable transformations only. |
|
2026-02-15 09:48:53
|
Since its pretty new it's understandable if it has a limited and conservative scope of features. |
|
|
|
monad
|
2026-02-15 10:02:03
|
they're actually a mod? lol, definitely reads like one. typical chronically online psychopathy. whatever, it's a nothing burger. |
|
|
|
RaveSteel
|
2026-02-21 06:22:42
|
https://github.com/Tom94/tev/releases/tag/v2.9.0
tev now also supports opening 1.7 DNGs with JXL payload |
|
|
|
jonnyawsom3
|
2026-02-21 06:34:21
|
Yes but no. It doesn't map color to the normal DNG, looks like it just merges the CFA planes, and for the JXL it just loads the internal image instead of handling it as a RAW file |
|
|
|
RaveSteel
|
2026-02-21 06:36:01
|
I cannot compare the DNGs in another program as nothing I have supports it yet. But the DNGs look about as I would expect them to look โ at least for the ones I captured |
|
2026-02-21 06:36:35
|
It looks more like what I would expect, than exporting the JXL with exiftool |
|
|
|
jonnyawsom3
|
2026-02-21 06:36:54
|
Maybe it only supports Linear DNG instead of CFA DNG? |
|
|
|
RaveSteel
|
2026-02-21 06:37:02
|
could be |
|
2026-02-21 06:37:24
|
Most 1.7 DNGs (at this time) are linear after all I'd assume |
|
2026-02-21 06:37:41
|
You could open a ticket, the dev is very responsive |
|
|
|
jonnyawsom3
|
2026-02-21 06:38:29
|
Irfanview, while slow due to running singlethreaded, does work |
|
|
|
RaveSteel
|
2026-02-21 06:39:00
|
Does Irfanview actually load the raw data? |
|
|
|
jonnyawsom3
|
2026-02-21 06:39:45
|
With multiple options for processing |
|
|
|
RaveSteel
|
2026-02-21 06:39:52
|
cool |
|
2026-02-21 06:40:36
|
I converted a DNG with tinydng with the same result as yours |
|
|
|
jonnyawsom3
|
2026-02-21 06:56:28
|
Another thing I noticed is that it's always decoding lossy JXLs as float, even when the original bitdepth was only 8, causing normalization to break and a lot of banding from libjxl not dithering the output and clamping to the original range |
|
|
|
_wb_
|
2026-02-21 07:09:46
|
DNG is not just a raster image, it's also a bunch of filters/operations. To me it looks quite intimidating, basically whatever Lightroom does is the de facto spec and if you want to implement it you have to figure out what Lightroom does. Or at least that is how I assume things are. |
|
|
|
RaveSteel
|
2026-02-21 07:16:48
|
the Adobe DNG SDK enables software to properly decode all these various DNGs, but the license situation is unclear, so no FOSS viewer or editor has implemented it. And Adobe has not responded to questions regarding this issue AFAIK |
|
2026-02-21 07:22:04
|
Rawtherapee seems to have added the DNG SDK 5 days ago, including DNG 1.7 support
https://github.com/RawTherapee/RawTherapee/commit/d4a5af933e76763faa4c20002d7545e26cde29af#diff-9c7e2335051bb7c51dfd6811162e3786075a41297c5296678b5564c4d2dd1cb3R22 |
|
|
|
jonnyawsom3
|
2026-02-21 09:01:52
|
Last I heard someone emailed Eric Chan (The main Adobe employee we know works on JXL support) and they said the licencing was fine for whatever |
|
|
|
RaveSteel
|
2026-02-21 09:03:43
|
Oh? Do you have a link? Or can you tell me where this exchange was documented? |
|
2026-02-21 09:03:50
|
Would love to have a look myself |
|
|
Vlad (Kuzmin) Erium
|
2026-02-23 03:22:26
|
Eric is not a lawer and even not from legal department of an Adobe.
License for sure is permissive for proprietary code bases. But distribution as a part of open-source projects is questionable.
For example user must load DNG SDK from Adobe, and loading it it signing agreement. |
|
2026-02-23 03:24:59
|
DNG license is from pre-opensource era. And that makes it a bit hard to use.
For example 1.7.1 use old as mammoth sh*t jxl and to use a newest you need patch a DNG SDK code. That already create some confusion. |
|
2026-02-23 03:26:17
|
XMP SDK included in DNG SDK is newer branch from public Adobe XMP SDK. |
|
|
|
RaveSteel
|
2026-02-23 05:22:56
|
tev (on master) now supports CFA DNGs, linear JXL DNGs and CFA JXL DNGs
https://github.com/Tom94/tev/pull/418 |
|
|
|
_wb_
|
2026-02-26 01:23:18
|
https://www.adoptapet.com/ is averaging 86k new jxl encodes per day recently, i.e. producing one jxl per second |
|
|
|
RaveSteel
|
2026-02-26 02:18:53
|
https://ptgui.com/versionhistory.html |
|
2026-02-26 02:19:11
|
```
TIFF output can now also be compressed with JPEG XL compression. This is not widely supported yet, with the exception of Pano2VR 8 beta. PTGui can also read back TIFF files compressed with JPEG XL. JPEG XL is lossless at 100% quality, and at lower quality it is lossy but filesize is greatly reduced. This is a good option when transferring multi gigapixel panoramas to Pano2VR.
``` |
|
|
|
jonnyawsom3
|
|
|
spider-mario
|
2026-02-26 02:42:47
|
oh, also DNG |
|
|
|
jonnyawsom3
|
2026-02-26 02:47:46
|
Multi-gigapixel panoramas would be a good progressive decode use case, could change images near-instantly |
|
|
|
RaveSteel
|
2026-02-26 02:58:01
|
Most large panoramas on the web use tile based services to serve lots of JPEG tiles as the are needed, so this would be mostly great for the better quality JXL delivers at similar filesizes |
|
2026-02-26 02:58:13
|
The website even has such a service in use for their panorama gallery |
|
2026-02-26 02:58:37
|
https://ptgui.com/gallery |
|
|
|
jonnyawsom3
|
2026-02-26 03:01:06
|
Good point |
|
|
|
RaveSteel
|
2026-02-26 03:01:55
|
If only libvips or imagemagick supported JXL in TIFF |
|
2026-02-26 03:02:08
|
at least for libvips there is an open issue regarding this |
|
|
|
spider-mario
|
2026-02-26 03:49:05
|
and Pano2VR and the like can also generate static sites that behave in that way: https://sami.photo/pano/golzernsee/
(I used PTGui to stitch and export the panoramas as one โbigโ image each, then Pano2VR to export them as an HTML directory that links them together) |
|
2026-02-26 03:49:19
|
(if you use the Network inspector in Chrome, you can see the requests for the various tiles) |
|
2026-02-26 03:51:00
|
ugh, I meant to include a tile URL but Discord automatically _replaces_ it with the preview |
|
2026-02-26 03:51:24
|
`https://sami.photo/pano/golzernsee/tiles/node2/cf_2/l_3/c_2/tile_2.jpg` |
|
2026-02-26 03:51:26
|
there we go |
|
|
|
_wb_
|
2026-02-26 04:31:30
|
These are currently the top-10 jxl-producing sites using Cloudinary, not by traffic but by number of jxl encodes. These 10 customers together produced 18.8 million new jxl files (958 GB) in January 2026: adoptapet.com, aritzia.com, asos.com, fractureme.com, furniturerow.com, gunbroker.com, seasaltcornwall.com, shopmonkey.io, swarovski.com, vividseats.com |
|
|
|
username
|
2026-02-27 05:40:01
|
would anyone be willing to try making and submitting JXL support to [PhotoRec](https://www.cgsecurity.org/wiki/PhotoRec)?
The page describing how to add a new format to their codebase is here: https://www.cgsecurity.org/wiki/Developers#Adding_a_new_file_format_to_PhotoRec |
|
2026-02-27 05:57:36
|
"adding support" in this context would be file signature/header detection and not decoding |
|
|
|
_wb_
|
2026-02-27 02:13:32
|
I know jxl payloads have been added to GeoTIFF and jxl itself can also be used directly in GDAL (https://gdal.org/en/stable/drivers/raster/jpegxl.html), but does anyone know anyone actually using it? I can't seem to find any blogpost or whatever of a geospatial application talking about switching to jxl... |
|
|
|
Quackdoc
|
2026-02-27 07:28:57
|
JXL works perfectly almost on brave on my phone |
|
|
Mine18
|
2026-02-28 09:25:17
|
how has traffic changed since chrome has added jxl, or has it not changed much since it's not default? |
|
|
|
_wb_
|
2026-02-28 09:38:45
|
I can check but generally the % of people who change flags is almost zero |
|
|
|
HCrikki
|
2026-02-28 09:46:19
|
thats why origin trials get used to force-activate flags for specific domains, regardless of what you think of them |
|
|
|
Mine18
|
2026-02-28 09:58:16
|
origin trials? can websites force some flags on/off? |
|
|
|
jonnyawsom3
|
|
|
AccessViolation_
|
2026-02-28 10:11:05
|
You have died of dysentery |
|
|
|
_wb_
|
2026-02-28 10:23:02
|
Just did a query. Currently 0.0208% of Chrome desktop image requests we see, and 0.0253% of Chrome Mobile image requests have the jxl support flag enabled. |
|
2026-02-28 10:23:51
|
Also 94.694% of Chrome Mobile iOS image requests, for comparison. |
|
2026-02-28 10:25:54
|
(probably most of those 5.3% remaining one on Chrome Mobile iOS do actually support jxl but the request is not coming from an img tag or css background-image but from a request made in javascript, which will cause Accept: image/jxl to be missing) |
|
|
|
HCrikki
|
2026-02-28 10:29:02
|
OTs can be limited to specific browser versions, like ones shipping jxl-rs 0.3 or newer. it doesnt have to be about developping the library but checking impact on servers and page loads |
|
|
|
jonnyawsom3
|
2026-02-28 10:31:21
|
I'm not sure if the plan was to get progressive LfGlobal working before the next jxl-rs release, but there's definitely a lot to look forward to |
|
|
|
awxkee
|
2026-02-28 12:24:05
|
Chrome on iOS is essentially Safari since Apple forbids to ship any other engine except WebKit |
|
2026-02-28 12:24:24
|
All other browsers on iOS are just a different UI on top of Safari |
|
|
|
_wb_
|
2026-02-28 01:36:22
|
|
|
2026-02-28 01:36:37
|
Does this table look correct? |
|
|
|
username
|
2026-02-28 01:38:27
|
at a quick glance it seems to be correct but I haven't looked any deeper |
|
|
|
_wb_
|
2026-02-28 01:39:29
|
Writing a new blog post and considering to make some point about the order between wider ecosystem adoption and browser adoption and how Chrome dragging its feet may ultimately be a good thing for end-users, actually, since interoperability will be better. |
|
|
|
RaveSteel
|
2026-02-28 01:42:04
|
The year of JPEG XL |
|
|
|
_wb_
|
2026-02-28 01:56:03
|
"2026, the year of JPEG XL" is the WIP title of this blog post ๐ |
|
|
|
RaveSteel
|
2026-02-28 01:57:01
|
nice <:megapog:816773962884972565> |
|
|
|
spider-mario
|
2026-02-28 02:22:14
|
The year of ~~the Linux~~ JPEG XL ~~desktop~~ |
|
|
|
jonnyawsom3
|
2026-02-28 02:58:38
|
I think it's a double sided issue. On one hand, browser support last means users won't complain about a lack of support. On the other hand, if browsers were first and users were complaining, adoption outside the web could've been even faster |
|
|
|
Quackdoc
|
2026-02-28 03:01:11
|
I just wish we had better android support but it is what it is |
|
|
|
whatsurname
|
2026-02-28 03:02:09
|
It's hard to determine the spec finalization date for WebP since lossless, alpha and animation were added later.
Windows support is also a little complicated due to the discrepancy between WIC and the Photos app. |
|
|
|
_wb_
|
2026-02-28 03:24:11
|
I took the finalization date for webp as the date when lossless and alpha were added. That means Chrome support was added before the spec was finalized. |
|
2026-02-28 03:27:37
|
Yes, not sure what would be a fair date to say each of these formats got "Windows support". It depends on what you count as support. If the criterion is "works in typical Windows applications like Office", then maybe none of the modern formats are actually fully supported. |
|
|
|
whatsurname
|
2026-02-28 03:30:17
|
It was still a draft on Nov 2011 though, the lossless bitstream was finalized with libwebp 0.2.0 (Aug 2012) |
|
2026-02-28 03:34:07
|
Or use "initial release" instead of "spec finalization" and choose Sept 2010, which makes Chrome support after that |
|
|
|
_wb_
|
2026-02-28 03:54:22
|
Ah right. Aug 2012 is better. |
|
|
|
whatsurname
|
2026-02-28 03:55:11
|
Doesn't Office just use WIC? Just checked I can insert them in Word with corresponding image extensions installed (though for some reason the .jxl file extension wasn't registered so I had to choose \*.\*) |
|
|
|
0xC0000054
|
2026-02-28 03:59:34
|
I would expect that it does. |
|
|
|
_wb_
|
2026-02-28 04:00:27
|
I have no clue, I haven't used Windows since 1998. I see many people complaining that webp doesn't work but probably in most cases it can actually be made to work. |
|
|
|
jonnyawsom3
|
2026-02-28 04:38:02
|
I feel like that should give WebP a red negative timespan. Implementing something that's actively changing is... A decision |
|
|
|
_wb_
|
2026-02-28 04:42:01
|
Yes, it caused significant complications. For many years the only way to tell what "Accept: image/webp" actually meant (alpha? animation?) was to parse UA strings and infer it from the browser version, which is _not_ how content negotiation is supposed to work. |
|
2026-02-28 04:42:58
|
(we will probably be in a similar situation with animated jxl, unfortunately) |
|
|
|
jonnyawsom3
|
2026-02-28 04:57:05
|
Thankfully both libjxl and jxl-rs already handle animations, and it's still behind a flag for Chrome and Firefox, so IIRC it's only Safari that's lacking it |
|
|
|
whatsurname
|
2026-02-28 05:00:30
|
Well you didn't need to guess what that meant because Chrome wasn't sending it /s
https://groups.google.com/a/webmproject.org/g/webp-discuss/c/ytMBnZoOAKo/m/FEbw34t4v3cJ |
|
|
|
_wb_
|
2026-02-28 05:09:40
|
Lol yes. But even when they were sending it, for quite a while it was not guaranteed that alpha and animation would work |
|
|
|
username
|
2026-03-03 02:12:21
|
the Firefox repo recently merged in the patch here: https://bugzilla.mozilla.org/show_bug.cgi?id=1709814
Commit here: https://github.com/mozilla-firefox/firefox/commit/5dccc269fa45
**However!** it seems to **always** output as sRGB which is wrong and different from how other image formats are handled ๐ซค |
|
2026-03-03 02:19:14
|
er well I guess the rendering intent is always getting set to `Perceptual` at the moment as well though there is a patch posted for that: https://bugzilla.mozilla.org/show_bug.cgi?id=2020281 |
|
2026-03-03 02:20:24
|
maybe it's *just* the rendering intent being handled wrong which is causing the P3 test to look wrong since it's supposed to be `Relative Colorimetric` but idk it really seems like the code is always outputting as sRGB but I could be wrong ๐คท |
|
|
|
adap
|
2026-03-03 05:43:00
|
last time i checked jpeg xl test page on firefox it was only the jxl image that had support for wcg but now it's the opposite |
|
2026-03-03 05:43:04
|
๐ง |
|
|
|
username
|
2026-03-03 05:47:42
|
it's because there wasn't any proper color management before and your browser is likely outputting as sRGB which means you shouldn't see the logo in any image |
|
|
|
adap
|
2026-03-03 05:48:23
|
oh are you using windows acm? |
|
|
|
username
|
2026-03-03 05:48:53
|
nope just a good ol color/ICC profile |
|
2026-03-03 05:49:09
|
i've never tested Windows ACM before |
|
|
|
adap
|
2026-03-03 05:50:27
|
Think it's on by default i have it off because it causes issues in hdr |
|
|
|
username
|
2026-03-03 05:54:38
|
I'm not on Windows 11 so it doesn't exist for me |
|
|
Smegas
|
2026-03-03 10:15:50
|
Opera Developer now is on chromiun 145. Jxl is under flag. Test page work well |
|
|
dogelition
|
2026-03-03 11:08:11
|
the only way to get wide gamut output with that in firefox is to enable legacy icc color management i think? unless firefox added explicit support for it recently
not entirely sure if firefox actually accepts the fake icc profiles generated by acm though, i remember that the ones generated by the hdr calibration app were just garbage
and with hdr/acm enabled you're getting some broken colors on the web anyway: https://bugzilla.mozilla.org/show_bug.cgi?id=1900520 |
|
|
|
username
|
2026-03-04 07:18:46
|
oh nice a bug and patch got posted for this: https://bugzilla.mozilla.org/show_bug.cgi?id=2020626 |
|
|
Cy
|
2026-03-07 10:20:45
|
Hey, I was messing around with the ATProto API and discovered that BlueSky supports JXL Image attachments if you use the API and not the App. |
|
|
|
jonnyawsom3
|
2026-03-07 10:21:32
|
Oh yeah, the web client has accepted JXL for quite a while, but it gets converted to a JPEG |
|
|
|
username
|
2026-03-07 10:24:46
|
BlueSky's image handling system/backend is horrendously awful and is likely wasting copious amounts of server storage space, processing power, etc all while making images lower quality at the same time. they should genuinely throw out almost the entire thing and start over again or at the very least overhaul/rework their handling. |
|
2026-03-07 10:30:59
|
their system is as follows (more or less):
1. decode user uploaded image/file to pixels.
2. encode pixels to quality "100" 4:4:4 YUV JPEG restricted to a max res of 2000x2000.
3. these JPEGs then get sent through [imgproxy](https://imgproxy.net/) at what seems like almost completely default settings (medium quality non-progressive JPEG) for display on the website. |
|
|
|
Cy
|
2026-03-07 10:40:02
|
You can skip the conversion on upload if you use the API. That won't fix the imgproxy step tho. |
|
|
|
username
|
2026-03-07 10:41:31
|
oh huh does using the API directly skip the second step I listed compared to the web interface? |
|