|
dogelition
|
2026-02-10 05:50:17
|
and it's not even a drop-in replacement for av1 avif because of the lack of 12 bit support |
|
|
HCrikki
|
2026-02-10 06:58:57
|
100% sure MS was onboard because only days after the reveal there was a *veto* that overrided the voting process entirely, some ms fella dissed that and ms' jxl extension was made public |
|
|
jonnyawsom3
|
2026-02-10 07:00:18
|
Still weird they limited it to Windows 11 |
|
|
|
HCrikki
|
2026-02-10 07:01:26
|
it could still be changed anytime, from what i saw its a completely arbitrary string in the store page/installer windows just enforces (not even the dll) |
|
|
ox
|
2026-02-10 08:42:07
|
No idea. That's interesting background that you discovered. To be honest, I should have avoided citating that speculative claim. The details may perhaps never be known publicly. Corps of this size manage narratives. |
|
2026-02-10 08:46:36
|
What I would like to know if whether this can be seen as a definite move or not. From guts estimate I'd assume it definite.
Next I'd love to understand what that means for my work. So far, I used AVIF for most pixel art in browser. |
|
|
Demiurge
|
2026-02-10 08:49:24
|
The narrative matters a lot to people who have a big ego, and people tend to have very big egos wherever there's lots of money. |
|
2026-02-10 08:53:17
|
For pixel art webp has a very mature and optimized lossless encoder. |
|
|
|
HCrikki
|
2026-02-10 08:55:08
|
avif's lossless is inefficient compared to webp lossless (done by jyrki iinm) and can lose even to png |
|
|
|
Demiurge
|
2026-02-10 08:55:44
|
The lossless libjxl encoder is pretty good but not as optimized or mature as webp yet. In the future it's expected jxl will beat webp for everything. But as of right now, the current version of libjxl often loses to lossless webp at 8-bit and below. |
|
|
|
ox
|
2026-02-10 08:56:44
|
I tried both. AVIF, and WebP. AVIF often did better for photos. WebP often did better for drawings. I do love highly optimized formats. But after 35 years of IT, I also care a lot about standard and tool support. If PDF gains JXL, it's an argument for JXL for me. On the other hand, AVIF so far seemed to be most impressive for video - but I did not investigate deep there. |
|
|
|
HCrikki
|
2026-02-10 08:56:52
|
something about avif's algos requiring a minimum of data/detail discarding before they can compress as expected or they malfunction |
|
|
|
Demiurge
|
2026-02-10 08:57:30
|
avif is not recommended for pixel art. Only for lossy cartoons basically, or photographs. |
|
|
username
|
2026-02-10 08:57:36
|
AVIF generally is not a very versatile format |
|
|
|
ox
|
2026-02-10 08:57:48
|
My primary use is large Enterprise Architecture graphs with comprehensive symbols/drawings. |
|
|
|
Demiurge
|
2026-02-10 08:58:30
|
For pixel graphics with 8 bit color lossless webp is best in class or perhaps tied with jxl |
|
|
|
username
|
2026-02-10 08:59:12
|
WebP also has "near lossless" mode |
|
|
|
Demiurge
|
2026-02-10 08:59:36
|
Remember to only use lossless webp. Lossy webp is useless. Utterly and completely useless |
|
|
|
ox
|
2026-02-10 09:00:44
|
Yeah, I often compare with https://squoosh.app - and it's mostly photographs where AVIF outstands there. I did not have great luck with huge pixel graphics with AVIF, from my memory. I think when reaching 10k+ pixels in one dimension it started taking hours to encode. But my notebook ain't the latest. Not sure if it was 10k pixel or 30k pixel. Currently working on other stuff. |
|
|
|
Demiurge
|
2026-02-10 09:00:54
|
Near-lossless uses the same codec as lossless so I think it's probably good too |
|
2026-02-10 09:01:28
|
avif is good with most graphics but not pixel graphics. |
|
2026-02-10 09:01:59
|
Anything with a small amount of colors should be webp or jxl |
|
2026-02-10 09:02:06
|
Or even PNG |
|
|
|
username
|
2026-02-10 09:02:08
|
Squoosh is really nice to use although it has a really old version of libjxl for JXL encoding |
|
|
|
ox
|
2026-02-10 09:02:23
|
Yeah, I only use WebP lossless. And AVIF only lossy for photographs - with the Squoosh default settings mostly. |
|
2026-02-10 09:04:32
|
Good to know. Thanks for the hint. For very large images I could not use Squoosh. Neither for WebP nor PNG nor AVIF, from my memory. I should test again. For huge images things seem getting messy. Interesting actually, as one could argue it's just 4x a smaller image. But that's not how it mostly behaves for me. At some sizes the encode times and open times seem expanding exponentially. |
|
|
|
Demiurge
|
2026-02-10 09:04:35
|
jxl is versatile enough to eventually become the "universal" format for all types of image data but the current encoder software is still an early proof of concept and does not have the same specialized optimizations for specific image types that older more mature encoders have. Most of the optimizations assume it will be compressing a photograph-like image |
|
2026-02-10 09:05:07
|
This is not a limitation in the format itself but only the current level of optimization in the encoder |
|
|
A homosapien
|
2026-02-10 09:05:22
|
And JXL's algorithms are tuned for higher qualities. |
|
|
|
username
|
2026-02-10 09:05:51
|
an annoying downside to AVIF is you can't see a single pixel of an image until it's 100% downloaded (unless you encode it with a very specific tool in a very specific way) unlike almost every other format such as BMP, GIF, JPEG, PNG, WebP, and JXL |
|
2026-02-10 09:06:30
|
for local viewing it isn't an issue but when trying to view stuff over the internet it's painful |
|
|
Mine18
|
2026-02-10 09:07:04
|
apparently julio figured out a psuedo progressive loading for avif |
|
|
|
Demiurge
|
2026-02-10 09:07:30
|
Does the heif container not allow chunks to be decoded if the image has multiple chunks? |
|
2026-02-10 09:07:41
|
No streaming? |
|
2026-02-10 09:08:30
|
I heard of an animation hack where the first frame is really rough and subsequent frames add more details on top |
|
|
|
Mine18
|
2026-02-10 09:08:55
|
<@297955493698076672> can you demonstrate your findings |
|
|
|
username
|
2026-02-10 09:09:10
|
hopefully something like this can be added to encoders as something that's on by default and doesn't require dancing around with a library API in an annoying way otherwise this won't get used in the wild very often |
|
|
|
ox
|
2026-02-10 09:09:29
|
I understand that concern. Though the progressive ain't really a big deal to me. I tend to think nowadays there's bandwith excess. And I don't really spend time on websites with images. It's mostly my IT architecture work where I'd just love to build massive graphs with 10k+ nodes and comprehensive symbols and imagery, and not let them take huge size. |
|
|
juliobbv
|
2026-02-10 09:09:46
|
I'm still working on the feature 😄 |
|
2026-02-10 09:09:55
|
but expect something in March |
|
|
|
Demiurge
|
2026-02-10 09:10:16
|
Is it animation based? |
|
|
|
juliobbv
|
2026-02-10 09:10:47
|
keep in mind it'll be intra+inter frames based |
|
|
|
ox
|
2026-02-10 09:10:51
|
So, my main concern is SVG size with embedded whatever image format, and load time of it, and render size, if sharing large images for non-browser use. |
|
|
|
juliobbv
|
2026-02-10 09:11:17
|
because that's how you leverage "building up" an image in AV1 |
|
2026-02-10 09:11:43
|
it won't be as expressive as JXL, and it's not meant to be |
|
|
|
Demiurge
|
2026-02-10 09:12:01
|
So the intra image is rough and blurry and the inter frames add progressive refinement |
|
|
|
juliobbv
|
2026-02-10 09:12:08
|
correct |
|
|
|
Demiurge
|
2026-02-10 09:12:50
|
That's still a pretty powerful tool as long as you don't lose a lot of efficiency |
|
|
|
juliobbv
|
2026-02-10 09:13:21
|
yeah, it'll a sizable challenge, but we'll see |
|
|
|
ox
|
2026-02-10 09:13:41
|
I've seen more and more AV1 videos popping up with very impressive size for their quality. I think they use AVIF, if not mistaken. … Is there similar using JXL for video? |
|
|
|
username
|
2026-02-10 09:14:55
|
animated AVIFs are just AV1 video streams inside of a AVIF container. JXL supports animation but not in the same way a full video codec like AV1 does |
|
2026-02-10 09:16:24
|
I remember hearing that at some point apparently animated AVIFs functioned similar to how animated GIFs, WebPs, and JXLs do but then it got changed to just be full video streams at some point relatively late on |
|
|
|
juliobbv
|
2026-02-10 09:17:14
|
yeah, there's no need to keep animated AVIFs all-intra really |
|
2026-02-10 09:17:34
|
the decoder overhead (binary and compute complexity) to support inter frame tools isn't that big with dav1d |
|
|
|
ox
|
2026-02-10 09:19:47
|
Oh. I had mistakenly thought that uses AVIF key frames. I sometimes use that AOMedia AVIF thing to reencode videos for sharing on Discord, to beat the 10MB size limit in free use. It did do impressive compression, but I never checked what it uses under the hood. 😄 |
|
|
|
juliobbv
|
2026-02-10 09:21:00
|
there are some techniques to exploit some redundancy across frames, but JXL is first and foremost an image codec its tool set is geared toward that |
|
|
|
username
|
2026-02-10 09:22:02
|
AFAIK currently libjxl doesn't really use or take advantage of the coding tools that exist in the JXL format for animation |
|
2026-02-10 09:23:07
|
the JXL format supports doing blending and such between frames but the current encoder just doesn't really attempt to use any of that at the moment |
|
|
|
ox
|
2026-02-10 09:23:20
|
That's honestly the first animation I ever saw based on JXL. |
|
|
|
HCrikki
|
2026-02-10 09:26:01
|
jxl does true animation conversions better than avif (from what i gather, losslessly with guaranteed smaller filesize like with jpg and png).
avif requires abandoning the gif image and going back to the original animation or video if those still exist and compressing that. even ancient divx compresses video better than gif on an aside |
|
|
|
ox
|
2026-02-10 09:27:04
|
Uh, it does actually share the base - if "AI" ain't hallucinating. |
|
|
|
dogelition
|
2026-02-10 09:30:43
|
an avif still image is (more or less) just an av1 keyframe
an animated avif (or an av1 video) can just be a sequence of av1 keyframes, but to actually make use of the video codec stuff you add inter frames |
|
|
|
ox
|
2026-02-10 09:31:38
|
I should have mentioned that this post had made me aware of the move of Chrome and PDF to JXL adoption: https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=87078&viewfull=1#post87078
... great forum ... best general resource on compression discussions I came across so far. |
|
|
|
juliobbv
|
2026-02-10 09:57:46
|
Gemini often tends to be wrong about anything video or image codec related unfortunately |
|
|
adap
|
2026-02-10 10:23:20
|
and everything else pretty much |
|
2026-02-10 10:23:57
|
or it's atleast not consistent |
|
2026-02-10 10:24:05
|
which I doubt will ever be fixed |
|
2026-02-10 10:25:21
|
This is why I love JXL it seemingly does everything |
|
2026-02-10 10:25:36
|
besides video obviously |
|
2026-02-10 10:26:09
|
It's really the only option when it come to hdr lossless too |
|
|
|
A homosapien
|
2026-02-10 10:27:47
|
I forgot there's no real modern option for HDR lossless. Good to know JXL will fulfill that niche. <:pancakexl:1283670260209156128> |
|
|
|
adap
|
2026-02-10 10:28:41
|
Yeah not that I'd use webp for normal lossless anyway lmao |
|
|
|
A homosapien
|
2026-02-10 10:30:38
|
WebP's lossless mode is quite good actually. |
|
2026-02-10 10:31:01
|
It's made by one of the JXL devs. |
|
|
|
adap
|
2026-02-10 10:32:06
|
Yeah that's why I mentioned it. Ik it's good for lossless i just really don't like webp |
|
2026-02-10 10:32:23
|
for no good reason really |
|
2026-02-10 10:32:55
|
maybe just sick of being forced to use it sometimes against my will |
|
|
Orum
|
2026-02-10 10:48:41
|
if not for the limitations... but yeah, for 8-bit sRGB content it's not bad |
|
2026-02-10 10:49:01
|
the encder can't match cjxl in speed though |
|
|
Quackdoc
|
2026-02-10 11:40:10
|
don't use ai |
|
2026-02-10 11:40:55
|
exr and tiff: am I a joke to you
me: yes. |
|
|
|
ox
|
2026-02-10 11:42:51
|
I guess some in 1975 said "don't use compilers". |
|
2026-02-10 11:43:15
|
I see AI just as "a tool". |
|
|
|
Quackdoc
|
2026-02-10 11:43:31
|
lol, at least compilers were remotely accurate |
|
2026-02-10 11:43:39
|
Using AI now is like pissing into the wind. |
|
|
|
ox
|
2026-02-10 11:46:18
|
Aight. Yeah, I've made such experiences as well. |
|
|
|
dogelition
|
2026-02-10 11:54:15
|
the answer is actually correct, but only because it kinda ignores the actual wording of the question |
|
2026-02-10 11:54:34
|
that model does suck though and often makes weird mistakes |
|
2026-02-10 11:55:03
|
if you are going to ask ai at least use a good model, e.g. https://aistudio.google.com/prompts/new_chat?model=gemini-3-pro-preview |
|
|
|
veluca
|
2026-02-11 03:32:35
|
Isn't the webp lossless encoder usually faster than cjxl? |
|
|
|
jonnyawsom3
|
2026-02-11 03:43:04
|
Depends on the settings, naturally |
|
|
Exorcist
|
2026-02-11 04:49:22
|
The encoder in Squoosh is very outdated, and WASM is far slower than native code
- https://github.com/GoogleChromeLabs/squoosh/blob/dev/codecs/avif/Makefile#L6
- https://aomedia.org/blog%20posts/Libaom-3_12_0-Now-Available-from-Codec-Working-Group/ |
|
|
|
jonnyawsom3
|
2026-02-11 04:54:47
|
Squoosh is running on v0.6, we're on v0.12 |
|
|
VcSaJen
|
2026-02-11 05:10:27
|
Translation of PR skeak:
Lossless = Lossless
Visually lossless = Lossy
Lossy = Failed Lossy
The very concept of "lossy" is disregarding imperceptible information. If you can notice artifacts, then lossy encoding have failed. I guess for authoring videos "near lossless" makes *a bit* of sense, considering lossless videos are impractical, so you have to settle for the next best thing, but for audio and still images it's just pure nonsense. |
|
|
NovaZone
|
2026-02-11 05:12:22
|
I prefer the term "visually transparent" |
|
|
whatsurname
|
2026-02-11 05:13:42
|
Nah WebP's near lossless mode has way higher quality than the typical visually lossless |
|
|
|
NovaZone
|
2026-02-11 05:14:58
|
Ie: don't even put lossless in the same term as lossy kek |
|
|
|
Exorcist
|
2026-02-11 05:15:58
|
in JXL, this has a better name: lossy modular |
|
|
|
NovaZone
|
2026-02-11 05:16:18
|
Sure that works |
|
|
|
VcSaJen
|
2026-02-11 05:16:31
|
When you are in the situation where you need more quality than what's perceptible by eye, why not just use full lossless to begin with? |
|
2026-02-11 05:17:17
|
Unless your images are frames of the video or something |
|
|
|
NovaZone
|
2026-02-11 05:17:26
|
Kinda the goal of all encoders no? To be visually transparent to the original |
|
|
|
VcSaJen
|
|
|
NovaZone
|
2026-02-11 05:18:40
|
At least with av1 that's always the goal, smaller filesize with lossy white being visually transparent |
|
|
|
whatsurname
|
2026-02-11 05:19:47
|
Visually lossless is only imperceptible at certain distance |
|
|
|
VcSaJen
|
2026-02-11 05:20:36
|
So it's still should be called "lossy", just "lossy" for other circumstances. |
|
|
|
NovaZone
|
2026-02-11 05:20:48
|
Debatable, have had some avif/jxl encodes that are visually transparent up to 8x zoom |
|
2026-02-11 05:21:23
|
No1 needs to be that close, ever kek |
|
2026-02-11 05:22:10
|
Yea there's levels to lossy depending on what is required |
|
2026-02-11 05:23:18
|
For archival it's always visually transparent, for web rtc/cdn it can be any degree of lossy based on the needs, etc |
|
|
|
Exorcist
|
2026-02-11 05:23:36
|
Lossless
Lossy
Lossful🤣 |
|
|
|
NovaZone
|
2026-02-11 05:24:13
|
That specifically is why I say transparent 😂 |
|
2026-02-11 05:26:16
|
Visually lossless to me sounds like normal viewing circumstances (which most encoders can do, there will be artifacts/errors at even 1.5x zoom or a paused frame), visually transparent involves stuff like this |
|
2026-02-11 05:27:26
|
Ie: at unreasonable distances it's imperceivable to the original, thus visually transparent |
|
2026-02-11 05:29:52
|
Easiest way to hit that ofc is jxl jpeg "lossless" transcode |
|
2026-02-11 05:30:49
|
Not bit exact like traditional lossless but within such a stupidly small margin of error it's visually transparent at 20xish zoom |
|
|
|
jonnyawsom3
|
2026-02-11 05:35:41
|
I generally target mine to be fine at 2x zoom or not distracting in a 1:1 flicker test, being on 1080p means I already zoom in pretty often on 4K images, so it gives wiggle room for lower res images too... Well, the rare times I do use lossy at least, pretty much always do lossless if I can get the size and speed good enough |
|
|
|
NovaZone
|
2026-02-11 05:36:39
|
Yea that's pretty much the standard imo |
|
2026-02-11 05:37:11
|
I go further just cause I'm trying to see if the encoder is working like it should |
|
|
|
jonnyawsom3
|
2026-02-11 05:40:44
|
In libjxl's case it definitely isn't, but we know what's wrong... Just not how to fix it yet |
|
|
|
VcSaJen
|
2026-02-11 05:49:49
|
What's the status of animation on current libjxl? Does it do GIF-like frame diff, or does it put full frames for every frame? |
|
|
Meow
|
2026-02-11 05:55:26
|
Tested some before and the usages are quite limited |
|
|
|
jonnyawsom3
|
2026-02-11 06:10:11
|
It just encodes whatever it's given. If the GIF/APNG uses frame diff, it'll use it. If they're all solid frames, it'll encode the solid frames |
|
|
|
Exorcist
|
|
|
Orum
|
2026-02-11 07:46:00
|
maybe on a single core system, but there aren't many of those around any more (at least that would be encoding images, anyway) |
|
|
|
whatsurname
|
2026-02-11 08:43:12
|
It depends on whether it can match WebP's size at lower efforts, the speed quickly drops from e9 to e10 |
|
|
|
jonnyawsom3
|
2026-02-11 09:15:35
|
What about it? |
|
2026-02-11 09:17:47
|
I mean... That *is* the highest level we expose without extra flags, I'd expect it to be the slowest |
|
|
|
Demiurge
|
2026-02-11 09:28:09
|
Honestly I would rather talent like yours be messing around with jxl encoders rather than avif. In the long term, jxl has a lot more untapped potential. |
|
2026-02-11 09:29:00
|
The RDO you've done for avif is impressive |
|
2026-02-11 09:29:41
|
Reminds me of the x264 rdo |
|
|
|
whatsurname
|
2026-02-11 09:33:36
|
WebP z9 isn't that much slower than the default setting, though the size reduction isn't significant either.
For some images JXL only beats WebP with e10 and the time it takes doesn't feel worth it. |
|
|
|
A homosapien
|
2026-02-11 09:55:31
|
z9 *is* much slower than the default though |
|
|
|
whatsurname
|
2026-02-11 09:59:16
|
Yes, but not that much compared to e10, even z9 usually not feels worthy |
|
|
|
A homosapien
|
2026-02-11 10:01:30
|
```
default lossless (z6) - Time to encode picture: 0.479s
lossless cruncher (z9) - Time to encode picture: 11.401s
```
Around 20x slower. Around the small ballpark as JXL I think |
|
2026-02-11 10:02:13
|
At least for smaller images |
|
|
|
ox
|
2026-02-11 10:17:18
|
I see. I had also tried latest build. It was a half a year ago. At that time huge images were incredibly slow with AVIF. |
|
|
DZgas Ж
|
2026-02-11 04:57:53
|
it's already close |
|
2026-02-11 05:16:50
|
literally "lol just decode it" |
|
|
monad
|
2026-02-11 05:17:17
|
very nice |
|
|
|
username
|
2026-02-11 05:34:56
|
I wonder if it would be worth adding that as an extra level to this? https://github.com/libjxl/libjxl/pull/4062 |
|
|
nicosemp
|
2026-02-11 05:38:26
|
I was recently made aware of this native method to check for supported mime types, instead of the base64 JPEG XL image suggested earlier:
```js
ImageDecoder.isTypeSupported('image/jxl');
```
The only downside seems to be Safari missing support for it, but I can easily skip Safari by looking at the userAgent. So the final logic would be `isSafari || isJxlSupported`. Any reason why this wouldn't work, or weird edge cases I'm not aware of? |
|
|
|
username
|
2026-02-11 05:40:27
|
should probably make it check for the version of WebKit/Safari that added support for JXL so that older clients don't get sent JXLs |
|
|
|
DZgas Ж
|
2026-02-11 05:41:22
|
This is an interesting option, but I decided to disable all possible decoding protection completely. I removed all flags, all checksums, everything.
Unfortunately, the format can't withstand a single bit of data Shifting—it's completely dead. BUT I don't beleve how much damage it can withstand compared to WEBP and AVIF. I just don't understand why no one emphasized this. In fact, I used to think that it couldn't withstand anything serious, that it died quickly and instantly. But that's completely false. It's no less resilient than regular JPEG. Why doesn't anyone just make an absolute decoding flag? I don't understand. |
|
2026-02-11 05:43:00
|
I'm doing a demonstration test right now, I'll just gun shoot in file with thousands, hundreds of thousands..., well, I'm interested myself |
|
2026-02-11 05:52:49
|
|
|
2026-02-11 05:53:27
|
https://tenor.com/view/enclave-fallout1-fallout2-fallout3-fallout4-gif-25785951 |
|
|
|
nicosemp
|
2026-02-11 06:07:53
|
true, so for Safari it's probably best to keep the `Image.src` method |
|
|
|
DZgas Ж
|
2026-02-11 06:08:33
|
the head is important |
|
|
|
jonnyawsom3
|
2026-02-11 06:23:57
|
Don't suppose you could upload the binary? |
|
|
|
DZgas Ж
|
2026-02-11 06:24:40
|
decoder? |
|
|
|
jonnyawsom3
|
2026-02-11 06:24:56
|
Yeah, djxl |
|
|
|
monad
|
2026-02-11 06:25:25
|
you mean dzgasxl |
|
|
|
DZgas Ж
|
2026-02-11 06:26:26
|
Well, I haven't compiled it yet. Right now I'm working directly through the libjxl API.
But I'll probably compile djxl a little later today, with since it's Just Decode. |
|
2026-02-11 06:30:48
|
Now I have a rough map of which places can't be broken (green) and which can (white) inside a Jpeg xl file |
|
2026-02-11 06:32:38
|
the very end of the file suddenly turned out to be very important |
|
|
|
monad
|
2026-02-11 06:33:46
|
a useful overlay when bit editing |
|
|
|
DZgas Ж
|
2026-02-11 06:35:18
|
Well, to create such an accurate mask, you would have to decode the JPEG XL several million times, so here is only an approximate map using binary search |
|
|
|
jonnyawsom3
|
2026-02-11 06:44:16
|
Ah right, I forgot |
|
|
|
DZgas Ж
|
2026-02-11 06:51:15
|
so dead |
|
2026-02-11 06:53:57
|
So, the conclusion is that you can recover your damaged jpeg xl file if it is damaged anywhere of any size, with a 78% chance. |
|
|
|
VcSaJen
|
2026-02-11 06:54:47
|
<#805007255061790730> potential |
|
|
|
DZgas Ж
|
2026-02-11 06:55:44
|
dzgas released a jpeg xl decoder specifically for <#805007255061790730> <:megapog:816773962884972565> |
|
|
_wb_
|
2026-02-11 07:30:27
|
I'm curious what this looks like if you do it for lossless images or lossy modular |
|
|
|
DZgas Ж
|
2026-02-11 07:32:14
|
<:Thonk:805904896879493180> |
|
2026-02-11 07:35:28
|
your interest is satisfied |
|
2026-02-11 07:37:07
|
It would be better if the group size were reduced. The important thing here is that, due to the lack of a "head," the chance of death is much lower. Although the data loss seems to be higher. |
|
|
|
_wb_
|
2026-02-11 07:37:09
|
wait I see entire groups disappear and none getting corrupted, that means you still have some error detection left |
|
|
|
DZgas Ж
|
2026-02-11 07:41:23
|
It's more of a side effect. Somewhere in the code responsible for position control, there's code that causes an empty buffer aka NULL, for the entire image due to some position corruption. The "Dead" message actually means that a completely black image was returned. Yes, that's something I didn't find, and I didn't even understand it. And in general, You 😜 should have implemented a djxl decoder that would return the decoding without skipping due to an error. I want to note that no decoding occurs; some error occurs somewhere, which almost immediately returns a blank image. But there are blocks here, yes, and they are empty. |
|
2026-02-11 07:42:12
|
In my case, it's clearly better than nothing. |
|
2026-02-11 07:51:55
|
great |
|
2026-02-11 07:54:06
|
<@238552565619359744>
Here's djxl.exe, which decodes broken and damaged jpeg xl files.
It also contains libjxl.dll, but maybe someone else needs it.
(I couldn't unbind some dependencies, and I don't care why.) |
|
2026-02-11 07:57:38
|
🤙 releasing the world's first JPEG XL decoder that can decode damaged JPEG XL files, even if bits, bytes, or chunks are damaged |
|
2026-02-11 08:02:36
|
|
|
2026-02-11 08:16:40
|
oh yea |
|
2026-02-11 08:17:52
|
zlib fix |
|
2026-02-11 08:47:59
|
oh wait |
|
2026-02-11 08:49:30
|
It is absolutely possible to decode a file with hard Byte Shift (You can even delete half of the entire file from the middle). In my decoder, use --allow_partial_files lool, but not for Head. |
|
2026-02-11 08:53:30
|
<:This:805404376658739230> Now I'm happy |
|
2026-02-11 09:04:19
|
this test.jxl is a small file, -q 10, I took it for byte-by-byte analysis. Here are all its byte, every pixel. Blacks can't be touched, decoding doesn't happen, whites can be lost. In such a small file, almost important is the head of the structures. |
|
2026-02-11 09:11:17
|
well why not |
|
2026-02-11 09:13:54
|
wow, is patch |
|
2026-02-11 09:15:11
|
If cut the image file from the end, the blurred version will be on a transparent color, along with other structures that were in the head |
|
2026-02-11 09:16:48
|
in some cases, whole words are completely restored because they are reference pieces |
|
2026-02-11 09:20:07
|
A standard JXL file is 300 KB q90. It can almost always be recovered if the head is not damaged. I checked every byte in this file, and absolutely everything white if damaged - can be recovered; every pixel is a byte. |
|
|
|
monad
|
2026-02-11 09:50:21
|
amazing, and beautiful |
|
|
AccessViolation_
|
2026-02-11 09:59:10
|
this is the second time you've tricked me into thinking I temporarily had slow internet |
|
2026-02-11 11:01:42
|
I just looked back to see what this is that you've been working on, that's so cool |
|
|
|
Orum
|
2026-02-11 11:09:16
|
define "recovered" |
|
|
|
cioute
|
2026-02-12 05:37:29
|
so, where to move from Discord? |
|
|
TheBigBadBoy - 𝙸𝚛
|
2026-02-12 05:53:00
|
nowhere, age-checking is only used for adult/NSFW
there is none of that in this server, so there's no reason why this server should migrate |
|
|
|
VcSaJen
|
2026-02-12 06:03:46
|
https://github.com/libjxl/libjxl/discussions |
|
|
|
Orum
|
2026-02-13 03:45:57
|
so I noticed jxlinfo does some interesting stuff when reporting color space info: `Color space: RGB, D65, Rec.2100 primaries, 709 transfer function, rendering intent: Relative` |
|
2026-02-13 03:47:24
|
it's not wrong, per se, but 2100 uses 2020 primaries, and since this is a SDR image, it's probably a better idea to call it Rec.2020 primaries; also 709 used the 1886 transfer function, so it's probably better to call it that instead of 709 |
|
|
Tirr
|
2026-02-13 03:57:58
|
like, it says sRGB primaries where it's actually bt709 |
|
2026-02-13 03:58:54
|
iirc it uses the term as defined in jxl spec |
|
|
|
Orum
|
2026-02-13 04:00:21
|
IIRC those are the same too, but yeah, it should use the correct term |
|
2026-02-13 04:00:44
|
it's very idiosyncratic as it is now |
|
|
|
whatsurname
|
2026-02-13 04:29:06
|
Define "the correct term"
Because bt709 is the correct one for transfer function if you look at h.273 |
|
|
|
Orum
|
2026-02-13 04:40:54
|
you mean because it's listed under the "informative remarks" on page 7? |
|
2026-02-13 04:41:13
|
those are just examples that use it, not the definition of what it is |
|
|
|
whatsurname
|
2026-02-13 05:17:04
|
Wdym not the definition of what it is? The definition of it is just a function, it's called by where it's defined. And that function is defined in bt709 |
|
|
|
Orum
|
2026-02-13 05:39:25
|
709 defines the gamma relative to a reference, but never actually defines the reference; 1886 actually defines this reference |
|
|
3DJ
|
2026-02-13 06:14:17
|
Would/could that be lossless?
and what would be needed to get that working?
If currently we could just encode a 2-frame video, maybe a viewer like sView would be able to intepret them as left and right 🤔 |
|
2026-02-13 06:17:55
|
Interesting, so are you saying we could just specify the hypothetical 2-frame video as stereoscopic with some 3D metadata?
Have any standards be considered for JXL?
With ffmpeg I can do something like this for MKV so that even YouTube can treat video as 3D
```bat
ffmpeg.exe -i "INPUT.mp4" -c copy -map 0 -bsf:v "h264_metadata=sample_aspect_ratio=1/2" -metadata:s:v:0 stereo_mode=left_right "OUTPUT.mkv"
``` |
|
2026-02-13 10:59:31
|
also, which part isn't currently done? encoding views as separate frames, marking them as left/right or both? |
|
2026-02-13 01:08:36
|
wait, where *do* I even find ffmpeg.exe with JXL support? |
|
|
RaveSteel
|
2026-02-13 01:34:29
|
you just need to specify manually |
|
2026-02-13 01:34:53
|
`-c:v libjxl`
libjxl_anim if you are going via image2pipe and it is an animation |
|
|
|
jonnyawsom3
|
2026-02-13 06:14:07
|
AFAIK there's no definition for 3D content in JXL *yet*, but there are a lot of different ways to do it.
You could store the left and right as interleaved channels, referencing each other or using frames and blend modes to take advantage of the redundancy between them. You could even do a 'merged' main image, with a difference layer/channels to reconstruct the left and the right
So the good news is, there's plenty of potential, the bad news is nothing has been defined for it so far
(Extra channels also have specified types, like kDepth or kThermal, so k3Diff or something could probably be added too) |
|
|
|
3DJ
|
2026-02-13 06:23:22
|
I think the ffmpeg I used just wasn't built with `--enable-libjxl`? |
|
2026-02-13 06:24:41
|
how would I try each method?
I'm particularly interested in the latter because viewers like sView (which already supports JXL and side by side 3D images) could probably work with it out-of-the-box |
|
|
|
ignaloidas
|
2026-02-13 08:08:34
|
can be lossless, needs a bit of work on the encoder to build frames in a proper way (e.g. for animated images it doesn't re-use any data between the frames unless the input such as APNG/GIF does that) |
|
2026-02-13 08:09:57
|
utilizing the data from the first one for the second one - you can encode the views as separate frames and mark them with the current libjxl api but it won't utilize redundancies between them for encoding |
|
|
|
AccessViolation_
|
2026-02-15 10:50:29
|
I've found an interesting use case for the edge-preserving filter.
In lossy modular without squeeze, lower qualities reduce the amount of colors, which means gradients get more color banding. But you can force setting the EPF to 1, to blur these gradients, removing a lot of the banding.
left to right:
`source.png | m1-q20-e10-g3-E4-I100-R0-epf0.jxl | m1-q20-e10-g3-E4-I100-R0-epf1.jxl`
`88.6 KB | 21.9 kB | 22.3 kB` |
|
|
|
monad
|
2026-02-15 07:24:00
|
actually looks decent, but the lines are less distinct and I wonder if that's more important at viewing distance |
|
|
|
AccessViolation_
|
2026-02-15 09:11:03
|
in an ideal world, those would be splines <:Stonks:806137886726553651> |
|
|
Kaguya
|
2026-02-16 09:37:13
|
how do i fix this error
```
cjxl -d 0 -e 9 東方猫鍵盤.jpg 東方猫鍵盤.jxl
JPEG XL encoder v0.12.0 b2edc77 [_AVX2_,SSE4,SSE2] {Clang 19.1.5}
Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0).
Encoding [JPEG, lossless transcode, effort: 9]
JPEG bitstream reconstruction data could not be created. Possibly there is too much tail data.
Try using --allow_jpeg_reconstruction 0, to losslessly recompress the JPEG image data without bitstream reconstruction data.
EncodeImageJXL() failed.
cjxl -d 0 -e 9 --allow_jpeg_reconstruction 0 東方猫鍵盤.jpg 東方猫鍵盤.jxl
JPEG XL encoder v0.12.0 b2edc77 [_AVX2_,SSE4,SSE2] {Clang 19.1.5}
Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0).
Encoding [JPEG, lossless transcode, effort: 9]
JxlEncoderProcessOutput failed.
EncodeImageJXL() failed.
``` |
|
2026-02-16 09:38:04
|
|
|
2026-02-16 09:47:39
|
i do have similar error with this too yesterday
https://gofile.io/d/lepnHW |
|
2026-02-16 09:48:32
|
`cjxl -d 0 -e 9 瞠.jpg 瞠.jxl` & `cjxl -d 0 -e 9 --allow_jpeg_reconstruction 0 瞠.jpg 瞠.jxl` |
|
|
|
RaveSteel
|
2026-02-16 09:59:08
|
libjxl does not support CMYK (and YCCK?) yet |
|
|
|
_wb_
|
2026-02-16 10:14:13
|
it does, you can create CMYK jxl files with libjxl. I'm not sure if there's any easy way to do that at the moment but the API certainly does support it.
But jxl does not support lossless jpeg recompression for CMYK images; in fact there is no way to use the DCT on the K channel since VarDCT mode is hardcoded for 3 color components. |
|
|
|
username
|
2026-02-16 04:05:43
|
hey uh what in the world is going on with the tests here? https://github.com/web-platform-tests/wpt/tree/master/jpegxl |
|
2026-02-16 04:06:14
|
I can almost never get identical output to the "reference" images |
|
2026-02-16 04:07:10
|
~~I was only able to get identical output by using a random multi-year old copy of djxl/libjxl on the lossless test (the lossy one still came up different...)~~ EDIT: I guess this was wrong'ish? |
|
2026-02-16 04:10:16
|
before doing any testing I had originally thought this might have been due to the dithering added to libjxl but no it seems like there is something else going on here and I don't know what it is |
|
|
|
_wb_
|
2026-02-16 04:28:23
|
what kind of differences do you get? |
|
|
|
username
|
2026-02-16 04:38:50
|
for lossless this is a XOR mask of the difference |
|
2026-02-16 04:43:00
|
for lossy this is the XOR mask (it very very slightly changes if I decode it through a different way) |
|
2026-02-16 04:43:29
|
is there a better way to show this? |
|
2026-02-16 04:45:19
|
I feel like something changed in libjxl? Safari used to pass every one of the 5 tests but now only passes 2 |
|
2026-02-16 04:45:40
|
test run on Safari from late 2023: https://wpt.fyi/results/jpegxl?run_id=6201021686087680 |
|
2026-02-16 04:46:55
|
test run from 2024 (same results today): https://wpt.fyi/results/jpegxl?run_id=5128419331538944 |
|
2026-02-16 04:49:02
|
here's a download to the files themselves (JXLs and "reference" decode PNGs): https://download-directory.github.io/?url=https%3A%2F%2Fgithub.com%2Fweb-platform-tests%2Fwpt%2Ftree%2Fmaster%2Fjpegxl |
|
2026-02-17 01:50:41
|
help with this would be appreciated since I'm not sure exactly what I should be looking at or looking for. also I assume this might cause confusion or troubles for the WPT once/if other browsers besides Safari start getting tested |
|
|
Traneptora
|
2026-02-17 09:24:00
|
https://github.com/BtbN/FFmpeg-Builds/releases |
|
|
|
jonnyawsom3
|
2026-02-18 02:33:51
|
Had a thought about lossy quality for dark images. VarDCT already stores the image as f32 to treat different bitdepths the same, but what if the 0-1 range was rescaled to the used range in the image for the encoding heuristics. Then dark images would look normal to the encoder and bright images would retain highlight details |
|
|
|
monad
|
2026-02-18 03:35:53
|
what is this solving |
|
2026-02-18 03:40:23
|
In my mind there is already a quality knob in target distance, and the perceptual model should receive accurate information to decide whether to discard information. |
|
|
|
jonnyawsom3
|
2026-02-18 03:46:59
|
That's my point though, distance 1 on a light image isn't the same quality as on a dark image. It assumes dark = not visually perceptive even when the entire image is dark |
|
|
|
monad
|
2026-02-18 04:25:27
|
the claim is the encoder is relatively underperforming on dark images/the perceptual model is incorrect about such images? |
|
|
|
_wb_
|
2026-02-18 07:08:28
|
Well it is true that adaptation is not taken into account. If you look at a dark image in a dark room and there's nothing brighter than the image anywhere, you will see way more detail than if you look at that same image when there's also bright stuff on screen and/or if the room is bright. |
|
2026-02-18 07:12:33
|
It could make the assumption that the image is the only thing that produces light, instead of basically assuming that even if the image is very dark, there will also be other stuff on screen that uses the rest of the nominal range |
|
|
|
monad
|
2026-02-18 08:05:54
|
yes, makes sense that the encoder does not know the actual viewing environment by default. it seems this fact is not what's being criticized as images with some "light" part are apparently expressed expectedly. |
|
2026-02-18 08:14:37
|
maybe the semantics are not precisely aligned, but if you were displaying your images in a dark room, you should still be able to select a target q to mitigate perceived distortion to your required threshold |
|
|
lonjil
|
2026-02-18 10:37:49
|
adaptation happens even if only a few degrees around the center of your vision are dark. IME it's quite noticeable (at least on the last commit I tested) that dark areas are visibly more quantized than light areas, within an image, in a bright viewing environment. |
|
|
|
monad
|
2026-02-18 11:31:41
|
yes, I'm much more inclined to agree with something like that description which I recall you've commented on in the past. |
|
|
|
Demiurge
|
2026-02-20 01:54:37
|
It's common in a lot of video codecs for darks to get crushed and ugly. |
|
2026-02-20 02:02:47
|
The absolute difference between 100 and 103 is +3 just like the difference between 1 and 4. But one is a +3% relative difference and one is a +300% relative difference. Our eyes care more about the relative distortion, but a lot of bad encoders seem to care more about the absolute values. |
|
2026-02-20 02:04:02
|
Dark gradients tend to look awful on youtube and a lot of video coders have that issue |
|
2026-02-20 02:04:43
|
Haven't really noticed it on still image codecs like libjpeg |
|
2026-02-20 02:06:10
|
But libjxl definitely has the crushed darks issue last I checked too. |
|
2026-02-20 02:10:05
|
libjxl makes improvements in other areas though, so it's sometimes harder to notice the softer looking artifacts. |
|
|
|
adap
|
2026-02-20 04:28:15
|
our eyes are more sensitive to bright things right and a lot of encoders prioritized brighter details from what i remember |
|
2026-02-20 04:29:13
|
saw that in a tom scott video a while back lol |
|
|
|
jonnyawsom3
|
2026-02-20 04:33:27
|
Yeah, but when there *isn't* anything bright, all that's left is the bitcrushed blacks |
|
|
|
adap
|
2026-02-20 04:35:12
|
simply raise blacks it's a flawless strategy |
|
2026-02-20 04:35:21
|
<:5Head:736600409329893406> |
|
|
|
jonnyawsom3
|
2026-02-20 04:35:40
|
That's basically what I'm suggesting |
|
|
|
adap
|
2026-02-20 04:54:14
|
surely there's a way to transform video so that when it's encoded it looks like normal again (to a certain degree) |
|
2026-02-20 04:56:25
|
might just make the video lower quality though in the case of something like youtube since there's probably a upper limit to file size and transforming it beforehand would make the encode bigger |
|
|
|
Demiurge
|
2026-02-20 06:07:54
|
In dark areas, the same "absolute" change in luminosity becomes a much more massive "relative" change. So our eyes are actually a lot more sensitive to small absolute changes in the dark. Like I said, a +3 difference can either be the difference of 1 and 4 in a dark area, or the difference between 100 and 103 in a brighter area. It's much easier to see a dark pixel became +300% brighter compared to an already-bright pixel becoming only +3% brighter, so in that sense our eyes are more sensitive in the dark because of how our eyes work... |
|
2026-02-20 06:10:07
|
That's why pixels are often gamma encoded, giving more bits to darker values and less to brighter values. |
|
|
|
adap
|
2026-02-20 06:16:11
|
oh right yeah that makes since |
|
2026-02-20 06:16:17
|
I had it the opposite way around |
|
|
|
Demiurge
|
2026-02-20 06:19:12
|
Having crisp and sharp details in the dark shadows really helps photographs pop with depth. So I hope libjxl gets better at not over-blurring shadows. |
|
2026-02-20 06:31:24
|
Keep in mind that despite these flaws, libjxl is already one of the best codecs for lossy photograph-type images and for most lossless graphics. And it will only improve as jxl encoders get smarter and better. |
|
|
|
Exorcist
|
2026-02-20 06:32:06
|
Basically, this is the logic of `aq mode` in x264 |
|
|
|
Demiurge
|
2026-02-20 06:32:35
|
Adaptive quantization, yeah |
|
2026-02-20 06:33:01
|
It's a very important low-hanging fruit for all video/image codecs |
|
2026-02-20 06:49:39
|
https://people.xiph.org/~xiphmont/demo/theora/demo9.html |
|
2026-02-20 06:49:56
|
It would be cool to have demos like this for libjxl |
|
2026-02-20 06:50:43
|
It's too bad theora was abandoned as soon as vp8 became available. Theora seemed like a pretty well designed codec. |
|
|
|
whatsurname
|
2026-02-20 09:05:08
|
It seems something went wrong on the Safari side (used a wrong gamma?)
I get all 5 tests passed locally with both Chrome and Firefox |
|
2026-02-20 01:43:44
|
The old Firefox passed 3/5 tests (2 alpha tests are expected to fail) so it's not like a libjxl issue |
|
|
|
Kaguya
|
2026-02-21 01:43:59
|
why does this file end up becoming larger than .png using `cjxl -d 0 -e 9`
<https://booth.pximg.net/6eb02e72-bd85-4cc4-af7b-c3061763073e/i/3811922/51bdf4e8-6328-409d-ad3d-c13ce9fa3383.png> |
|
2026-02-21 01:50:21
|
|
|
|
|
Meow
|
2026-02-21 01:53:16
|
Default cjxl gives me over 1 MB |
|
2026-02-21 01:55:51
|
seems the original PNG uses index |
|
|
|
Kaguya
|
2026-02-21 01:59:43
|
I used nightly build |
|
|
|
Meow
|
2026-02-21 01:59:56
|
`-d 0 -e 10 -E 4 -I 100 -g 3 --patches=0 --brotli_effort=11` outputs 918,381 bytes and took 36 seconds |
|
|
|
RaveSteel
|
2026-02-21 02:05:23
|
e9 with P0 and I100 gave me 837.1 KiB |
|
|
|
Meow
|
2026-02-21 02:05:53
|
I used the release version of libjxl 0.11.2 however |
|
|
|
Kaguya
|
2026-02-21 02:09:59
|
I usually just use `-d 0 -e 9`. I didn't know I could go further. Is it ok to use this parameters for mathematically losslessly converting every files
`-E 4 -I 100 -g 3 --patches=0 -P 0` |
|
|
|
jonnyawsom3
|
2026-02-21 02:11:32
|
Every image is different, so there's usually different settings for each type of file |
|
2026-02-21 02:11:46
|
In this case it's what I mentioned last night https://discord.com/channels/794206087879852103/804324493420920833/1474487555121746155 |
|
|
|
RaveSteel
|
2026-02-21 02:12:15
|
the predictor (chosen with -P) gives different ressults depending on predictor AND image, so you generally do not want to always use P0.
g3 often gives the best results, but not always
For this image I got a smaller result than the original by using `-e 7 -I 100 -g 0 -E 4 -P 15` -> 964.9kb with 11.2 / 953.3kb with current main |
|
|
|
jonnyawsom3
|
2026-02-21 02:13:44
|
I'm curious... What if you try `cjxl -d 0 -P 15 -e 10 --patches 0` |
|
2026-02-21 02:14:18
|
That should enable the global pallete, and trying all predictors *might* be better than none |
|
|
|
RaveSteel
|
2026-02-21 02:18:58
|
I forget, e10 uses P14 by default, right? and e11 tries everything? |
|
2026-02-21 02:21:01
|
910.9 KiB, worse than e9 with I100 and P0 at 837,1 KiB |
|
2026-02-21 02:22:26
|
The image only has 243 colours btw |
|
|
|
jonnyawsom3
|
2026-02-21 02:22:29
|
Right, so on one hand I was wrong, on the other hand I was right. Low color tends to do best with LZ77 only instead of predictors, but we're not checking color count currently so I can't just tell it to |
|
2026-02-21 02:23:20
|
e10 uses P15 |
|
|
|
RaveSteel
|
2026-02-21 02:23:51
|
Ah ok, I just wondered because your suggestion specified P15 and e10 |
|
|
|
jonnyawsom3
|
2026-02-21 02:24:34
|
Yeah, I was gonna say e9 but thought global pallete might help |
|
2026-02-21 02:26:13
|
There is an idea for modular bit-packing, or using a squeeze step or two to increase the effective bitdepth so the predictors and MA tree has more context |
|
|
|
Exorcist
|
2026-02-21 02:26:51
|
After zoom in your image, I find it is dithered |
|
|
|
jonnyawsom3
|
2026-02-21 02:27:14
|
Yeah, that's because it's indexed |
|
|
|
Kaguya
|
2026-02-21 03:38:00
|
heres another [dithered image](<https://booth.pximg.net/6eb02e72-bd85-4cc4-af7b-c3061763073e/i/4398580/d4b02513-6eb0-4dde-ad6c-d0229fd4b03a.png>), though im not sure if its indexed. How can i know if its an indexed image? this time i got smaller file size
oh nevermind, i guess just by looking and zooming on it is enough |
|
|
|
monad
|
2026-02-21 08:00:32
|
If you use those parameters on other kinds of content you will have very poor performance (both density and speed). |
|
2026-02-21 08:06:53
|
If you didn't care about encode/decode speed and want something generally denser than e9, then e10 is safe. or if you want something generally denser than e10, Meow's parameters are close to best all-around. Or if you want to keep speed more comparable to e9 with mostly denser performance, you can do something like d0e8E11g2 with few surprises. |
|
2026-02-21 08:12:56
|
Also consider that I100 comes with a significant speed penalty for not much density improvement. For the image in question, probably P0I1 is almost as dense but much faster. |
|
|
|
Meow
|
2026-02-22 06:32:43
|
I got it as my software told |
|
|
|
jonnyawsom3
|
2026-02-23 06:21:26
|
Noticed this on a PR... |
|
2026-02-23 06:22:16
|
Which leads to this repo... <https://github.com/imazen/libjxl> |
|
2026-02-23 06:22:51
|
Which hosts this site, which is just AI slop that falls on the first image <https://imazen.github.io/libjxl/>
XYB is only used for lossy, for modular it makes lossless *not* |
|
|
|
NovaZone
|
2026-02-23 06:28:57
|
Does libjxl not have an ai contribution policy? |
|
|
|
jonnyawsom3
|
2026-02-23 06:29:37
|
Nope, but that was also just a commit on their own repo referencing an existing PR |
|
|
|
NovaZone
|
2026-02-23 06:30:20
|
Might be a good time to add one then |
|
2026-02-23 06:31:08
|
As iirc lads weir noticing a surge of llm contribs on mainline av1 as well |
|
|
|
Tirr
|
2026-02-23 06:33:54
|
I think currently it's something like "will accept if the patch seems reasonable enough", not an explicit policy though |
|
|
|
NovaZone
|
2026-02-23 06:35:34
|
Mpv's https://github.com/mpv-player/mpv/blob/master/DOCS/contribute.md#ai-assisted-contributions |
|
2026-02-23 06:37:40
|
Tldr it's fine, just understand what ur doing or Linus will have words 🤣 |
|
|
|
username
|
2026-02-23 06:39:24
|
LLM generated/assisted code has already made it's way into both libjxl and jxl-rs from others btw |
|
|
|
Exorcist
|
2026-02-23 06:44:09
|
When I need to overview codebase, I will directly ask LLM, not read LLM-generated documents |
|
|
|
jonnyawsom3
|
2026-02-23 07:17:08
|
jxl-rs and libjxl both require reviews on PRs anyway, so for now it's just been "Is it good and does it look sensible" |
|
|
|
veluca
|
2026-02-23 07:23:09
|
I wrote some llm-generated code myself 😛 |
|
2026-02-23 07:23:26
|
of course I check it very closely |
|
|
|
VcSaJen
|
2026-02-23 07:37:29
|
GenAI is basically the same as machine translation. All pitfalls and stuff are the same. |
|
|
|
_wb_
|
2026-02-23 07:51:51
|
and then the AI writes rage blogposts about its PR not getting accepted, like what happened recently in matplotlib iirc |
|
2026-02-23 07:53:46
|
any PR has to be reviewed carefully, whoever or whatever wrote it, and you need CI including conformance testing to continuously make sure nothing is broken |
|
|
|
AccessViolation_
|
2026-02-24 02:54:18
|
There are two additional MA-tree properties that I think would have been interesting: `col % N` and `row % N`.
Similarly to how we've talked about how you can use patches to extract out repeating textures, like for screenshots of SNES games, this could allow the encoder to create a sub-trees for sections of the image that it can reuse at set pixel intervals.
for this image:
```
if x % 8 < 1
yes: (part of grate)
no: if x % 8 > 7
yes: (part of grate)
no: (part of hole)
(similar logic again, this time for the horizontal lines)
``` |
|
2026-02-24 02:56:51
|
compared to the other properties this would need an additional parameter to be signaled though, the `N` |
|
2026-02-24 03:00:17
|
I'm assuming these don't exist, though the list in the paper was ellipsized, so I'm not sure |
|
2026-02-24 03:05:13
|
I also realized that we can create hidden channels that exist only to guide the MA tree. for example if you want some node or subtree to apply for a certain area but you can't do that quite right with intra-channel properties, just create a new channel, give the area in question a certain value in that channel, and use a `PrevChannel` property in the main image's channel's MA tree! who needs fast decode times! |
|
2026-02-24 03:15:40
|
another thing this could have been good for: source images that use ordered dithering |
|
|
|
Orum
|
2026-02-24 10:41:19
|
<@238552565619359744> Does this affect speed for decode, encode, or both? https://github.com/libjxl/libjxl/pull/4635 |
|
|
|
jonnyawsom3
|
2026-02-24 10:43:19
|
That was encode speed, decode should be roughly the same if not faster |
|
|
|
Orum
|
2026-02-24 10:46:45
|
also when you say lossless vs lossy, do you really mean modular vs VarDCT, or is it strictly lossless vs lossy? |
|
|
|
jonnyawsom3
|
2026-02-24 11:57:14
|
Lossless vs lossy, lossy Modular forces full buffering anyway |
|
|
|
Orum
|
2026-02-25 12:16:17
|
ahh okay |
|
|
|
3DJ
|
2026-02-27 08:50:27
|
https://is.potatoe.ca/notes/aj7u6yit632p9kyp |
|
|
Jarek Duda
|
2026-02-28 07:09:35
|
waiting for JPEG XXL |
|
|
|
jonnyawsom3
|
2026-02-28 07:22:15
|
That might turn into faster decoding level 4 if I get round to it, huffman only lossless encodes |
|
|
|
monad
|
2026-02-28 07:29:33
|
JPEG ЖL |
|
|
|
adap
|
2026-02-28 09:52:47
|
i thought xl didn't use huffman |
|
|
|
lonjil
|
2026-02-28 09:57:00
|
It usually doesn't, but it's available. |
|
|
|
AccessViolation_
|
2026-03-01 09:33:52
|
JXL supports Huffman coding and rANS. Huffman will probably be used a lot by hardware encoders e.g. in digital cameras, because Huffman coding is a lot easier to implement in hardware than rANS |
|
2026-03-01 09:35:52
|
Once those images become common, it'll be interesting to see if someone can create a tool that transforms Huffman JXLs into rANS JXLs. which should be lossless with respect to the pixel data, while making the file smaller |
|
|
|
username
|
2026-03-01 09:37:50
|
maybe would make sense to include as apart of this? https://github.com/libjxl/libjxl/issues/871 |
|
|
|
jonnyawsom3
|
2026-03-01 09:55:01
|
Huffman or LZ77 and rANS or prefix coding |
|
|
|
ignaloidas
|
2026-03-01 10:46:31
|
You can use LZ77 with rANS as well IIRC |
|
|
|
jonnyawsom3
|
2026-03-01 10:47:38
|
Yeah, that's why I split it into two 'or's |
|
|
|
ignaloidas
|
2026-03-01 10:52:34
|
ok, the wording is a bit confusing then I guess, from what I understand it's one of rANS or prefix(huffman) code, with optional LZ77 |
|
|
|
_wb_
|
2026-03-02 06:32:38
|
It's (ANS or prefix) with optional lz77 |
|
|
|
Orum
|
2026-03-02 07:15:55
|
god I misread that at first as ASN and had 1000-yard-stare flashbacks <:NotLikeThis:805132742819053610> |
|
|
|
dogelition
|
2026-03-02 11:46:28
|
https://project-zero.issues.chromium.org/issues/463335147 🤔 |
|
2026-03-02 11:48:45
|
another one https://project-zero.issues.chromium.org/issues/464250765 |
|
2026-03-02 11:49:20
|
(shoutouts to <https://x.com/ProjectZeroBugs>) |
|
|
|
jonnyawsom3
|
2026-03-02 11:50:34
|
Wow, it's almost like Adobe didn't put any thought into the JXL integration at all <:ugly:805106754668068868> |
|
|
|
Mine18
|
2026-03-02 03:10:34
|
but they're the biggest supporter of JXL! no way they would half-ass the implementation! |
|
|
|
username
|
2026-03-02 03:31:44
|
they seemingly did sadly |
|
|
|
jonnyawsom3
|
2026-03-02 03:32:06
|
Enthusiasm and understanding are two very different things |
|
|
|
username
|
2026-03-02 03:33:06
|
IIRC the DNG integration forcefully does low resolution tiling and also doesn't take advantage of the CFA channel support in JXL |
|
|
|
AccessViolation_
|
2026-03-02 03:37:22
|
exhibit A: me |
|
|
|
username
|
2026-03-02 03:37:40
|
so despite JXL having format level groups with multithreading and such, DNG decided you get DNG container level tiling of multiple small JXL bitstreams AFAIK |
|
|
|
jonnyawsom3
|
2026-03-02 03:38:18
|
Doesn't use the dedicated kCFA channel that was specifically added to the spec for bayer images, tiles at 768 x 768 so it only uses a 7th of a LF block but also requires at least 9 groups of HF/lossless so 1 thread per-tile doesn't make sense |
|
|
|
username
|
2026-03-02 03:41:00
|
I presume they just added JXL as a alternative bitstream to JPEG and didn't make any design decisions to take advantage of what JXL has over JPEG format design wise |
|
|
|
jonnyawsom3
|
2026-03-02 03:47:20
|
Oh wait, it's worse than I remembered https://discord.com/channels/794206087879852103/805176455658733570/1259094540082741338 |
|
2026-03-02 03:49:57
|
Bayer
```[SubIFD] SamplesPerPixel : 1
[SubIFD] TileWidth : 672
[SubIFD] TileLength : 752```
Linear
```[SubIFD] SamplesPerPixel : 3
[SubIFD] TileWidth : 400
[SubIFD] TileLength : 432``` |
|
2026-03-02 03:56:15
|
So they *did* change tile sizes... But not to anything that matches JXL group sizes, and for lossless they also used faster decoding 4, which got an overhaul since v0.11 |
|
|
|
username
|
2026-03-02 03:57:45
|
how much of this is changeable in a backwards compatible way with DNG? like I assume the tile size for the encoder could be turned up right? |
|
2026-03-02 03:59:33
|
400x432 is so small.. doesn't JXL also have features that go across groups which I assume this DNG level tiling doesn't allow for? |
|
|
|
jonnyawsom3
|
2026-03-02 04:01:30
|
TinyDNG already encodes it as a single tile, and lets you pick distance and effort levels (Unfortunately not faster decoding, and the dev stopped updating it 😔) |
|
|
|
username
|
2026-03-02 04:03:41
|
ah so DNG is flexible enough to allow for that at least, good to know. maybe in the future Adobe can change their tile size to not be so tiny if someone manages to get them to know it's an issue |
|
|
|
jonnyawsom3
|
2026-03-02 04:06:22
|
Apple do better with 2016 x 2016 tiles, but still odd they didn't do 2048 to match the LF size |
|
|
|
username
|
2026-03-02 04:10:11
|
they probably don't even know what the different internal resolutions are for different parts of the JXL bitstream but even then it is really odd they didn't go with 2048 since it's a power of 2 |
|
2026-03-02 04:13:06
|
2016 was probably derived from something weird because it seems like such an arbitrary number |
|
2026-03-02 04:17:57
|
I feel like I've arrived at "2016" as a number in the past when trying to scale some other number with bad math |
|
|
|
Demiurge
|
2026-03-03 05:07:25
|
Mega ultra derp |
|
2026-03-03 05:09:00
|
Does anyone know of a way to extract compressed payloads from TIFF files without decoding to pixels? |
|
2026-03-03 05:09:49
|
Like for example, extracting JPEG blobs into JFIF files without recompression or decoding |
|
2026-03-03 05:10:51
|
Can exiftool do that? |
|
|
|
_wb_
|
2026-03-03 06:49:24
|
TIFF supports striping, tiling, planar, etc, so you may have many blobs |
|
|
|
Demiurge
|
2026-03-03 07:48:05
|
Yes, but... can exiftool or some other tool do it? |
|
|
|
RaveSteel
|
|
|
Demiurge
|
2026-03-03 07:49:14
|
Sometimes JPEG data is written to TIFF files without the JPEG header so a legal header has to be reconstructed |
|
|
|
RaveSteel
|
2026-03-03 07:50:09
|
I tried my hand at vibecoding something a few weeks ago, have at it if you want to. it does almost work fine |
|
|
|
Demiurge
|
2026-03-03 07:50:18
|
I'm surprised that there isn’t a way to "extract" a jpeg from a tiff without bit fiddling |
|
2026-03-03 07:50:56
|
You would think that would be common enough for there to be more tools |
|
2026-03-03 07:52:05
|
I know there are tools to do it with PDF |
|
2026-03-03 07:52:25
|
Probably TIFF is just less common than PDF |
|
|
|
_wb_
|
2026-03-03 08:53:02
|
also PDF only embeds full images, while TIFF can chunk it up in various ways where the chunks are independent so you can't just recombine them by stream concatenation, it requires decode to DCT coeffs and re-encode. |
|
|
|
jonnyawsom3
|
2026-03-06 03:20:59
|
What was the rationale behind Gaborish being an encode time sharpen and a decode time blur? Doesn't encoding already remove high frequency detail and blur the image?
I ask because running some tests I'm noticing the sharpen introduces ringing into the image, causing higher bpp while the blur smooths out detail at the same time. It might be because the encoder and decoder kernels are out of sync, but I would've thought a decode-time sharpen would bring back more detail instead |
|
|
|
monad
|
2026-03-06 03:57:34
|
Well, it is precisely to mitigate harsh encoding artifacts, right? |
|
|
|
Exorcist
|
2026-03-06 03:57:58
|
MDCT has math proof
Gaborish has no math proof yet |
|
|
|
monad
|
2026-03-06 03:58:37
|
Gaborish has Jyrki magic, it is good enough. |
|
|
|
_wb_
|
2026-03-06 04:42:10
|
DCT blurs when high freq is quantized, but since blocks are independent, blockiness can be visible. Gaborish acts like deblocking by smoothing also across block boundaries. |
|
2026-03-06 04:43:40
|
But yes, I think the encode side gaborish should be changed to better approximate the inverse of the decode side gaborish. |
|
|
|
username
|
2026-03-06 04:54:02
|
wasn't this done already sorta? https://github.com/libjxl/libjxl/pull/3586
unless you mean changes beyond the per channel weights |
|
2026-03-06 04:55:29
|
wait I just realized that the code comment in that PR suggests reducing the weight by a very slight amount to reduce ringing |
|
2026-03-06 04:55:47
|
<@238552565619359744> maybe something to try? |
|
2026-03-06 04:56:25
|
```CPP
// Changing the weight here to 0.99f would help to reduce ringing in
// generation loss.
``` |
|
|
|
jonnyawsom3
|
2026-03-06 06:17:19
|
Made a branch with the weights reduced and the encode-side sharpening reverted to the original kernel from years ago when generation loss was much better. Should help the alignment with the decoder |
|
|
|
username
|
2026-03-06 06:25:07
|
I looked at the branch and are you sure you didn't set the weights a bit too low? I mean I guess that will be revealed in testing but still |
|
2026-03-06 06:28:45
|
Also what exactly are we targeting here? lower generation loss or lower ringing? I know that they aren't necessarily mutually exclusive but I'm just wondering what the focus is atm |
|
2026-03-06 06:29:39
|
my suggestion(s) was/are mostly just about the ringing that was mentioned |
|
|
|
jonnyawsom3
|
2026-03-06 06:31:26
|
Think I had too many tabs open and got some numbers mixed up, I'll nudge them back to just 0.99 for all. Vague idea was that we want less sharpening on the chroma to avoid worse quantization artifacts (The blue blotches) |
|
2026-03-06 06:37:29
|
I think the ringing was causing the generation loss, adding sharp lines that then got sharpened recursively until the DCT turned it into a solid pattern |
|
|
|
username
|
2026-03-06 07:02:14
|
I mean you could still mess with doing that but I would recommend doing so with a way smaller change, aka changing a number further down the float since they can be way longer |
|
|
|
Demiurge
|
2026-03-07 05:33:53
|
The decode side is precisely defined in the spec right? |
|
2026-03-07 05:37:22
|
Also I don't agree with this. Quantizing the high frequency coefficients doesn't necessarily cause blurring, it can also cause ringing instead. DCT was designed so that you can reduce the precision without causing blurring... it's used because it's good at preserving texture without blurring. The only reason why it's blurring so much in libjxl is not because of quantization but because it's rounding it down to zero (obliteration) instead of shaping/distributing the quantization error fairly. |
|
2026-03-07 05:40:13
|
In other words libjxl is misusing DCT without taking advantage of its unique strength, which is why libjxl often produces better looking results when you disable DCT... |
|
2026-03-07 05:41:20
|
I think this is because libjxl was tuned to avoid ringing artifacts which are punished severely by the metrics it was tuned for |
|
2026-03-07 05:44:50
|
Those metrics prefer blurring, even if the blurring is severe and obliterative, and they are very sensitive to ringing artifacts, even if the ringing artifacts are hard to notice because of activity masking (strong texture in the original image making artifacts harder to notice) |
|
|
|
Exorcist
|
2026-03-07 06:02:13
|
I have said, need math proof<:monkaMega:809252622900789269> |
|
2026-03-07 06:02:51
|
DCT MDCT jpeg2png, they all have math theory |
|
|
awxkee
|
2026-03-07 01:24:27
|
DCT-II is designed to concentrate the most significant energy into the very first bins. It has additional properties of symmetry and relation to FFT but it doesn't define quantization, blurring or any other processing terms. |
|
|
|
Demiurge
|
2026-03-07 03:08:18
|
The way DCT works allows you to use a coarse quantization for the higher frequency spectrum and still preserve the overall texture and appearance of the original at the expense of some additional ringing or noise that extends to the block boundaries... The reason it's the most favored image compression technique for photographic content is because of how good it is at preserving grit and texture without blurring. There's a difference between coarse rounding/quantizing and what libjxl is doing, which is less rounding/approximating and more zeroing/obliterating |
|
|
|
jonnyawsom3
|
2026-03-07 03:12:13
|
I realised another thing, Blue Yellow difference is stored as B-Y (BlueDiff - Luminance), so assuming it correctly takes into account yellow being 'brighter' than blue, the range would almost entirely be negative, making the 0 rounding even worse |
|
|
|
_wb_
|
2026-03-07 03:14:00
|
HF coefficients are always signed, and I don't think libjxl makes the zero bucket _that_ large when quantizing... |
|
|
|
Demiurge
|
2026-03-07 03:16:19
|
Metrics used to tune libjxl are very sensitive to certain artifacts like ringing and macroblocking but also completely indifferent to the complete and total loss of details and features in low contrast regions |
|
|
|
jonnyawsom3
|
2026-03-07 03:21:33
|
Fun fact, the different DCT types in libjxl used to have smoothing and noise values assigned to them, but they were removed in v0.9 |
|
|
|
Demiurge
|
2026-03-07 03:21:39
|
I think the metrics would probably severely punish the addition of high frequency distortion compared to the complete removal of high frequency energy |
|
2026-03-07 03:24:34
|
And overfitting for the metrics would have gradually led to not even bothering to approximate and preserve some of the details if the metrics will unfairly punish the inaccurate approximation worse than the complete removal and smoothing of it |
|
|
|
jonnyawsom3
|
2026-03-07 03:28:53
|
Maybe I'm going insane, I can't find them now... It was a few months ago since I last looked at it so maybe I misremembered |
|
2026-03-07 03:30:16
|
This was the main culprit for quality regressions, other than the B quantization which affects every version of libjxl https://github.com/libjxl/libjxl/pull/2836 |
|
|
|
Demiurge
|
2026-03-07 03:58:40
|
That commit has not been reverted yet? Is there a pull request reverting the changes? |
|
|
|
jonnyawsom3
|
2026-03-07 04:01:18
|
No, because there's 3 years of changes built on top of it |
|
2026-03-07 04:22:21
|
Results vary. It's around 0.5% smaller, looks either equal or slightly better. Definitely less ringing and ver slightly more accurate colors though, so might as well make a PR |
|
|
|
monad
|
2026-03-07 06:37:06
|
Can you attach the benchmarks? |
|
|
|
Exorcist
|
2026-03-09 10:25:42
|
DCT is smoother than DFT by arranging the signal to even symmetry (also make it real number output)
MDCT is smoother than DCT by adding 50% overlap window (and math trick to not duplicate the coefficients)
So, Gaborish (sharpen when encode, blur when decode) is questionable, it adds more high frequency
> https://www.commsp.ee.ic.ac.uk/~tania/teaching/DIP%202014/DCT%20other.pdf
> https://speechprocessingbook.aalto.fi/Transmission/MDCT.html
> https://www.comp.nus.edu.sg/~wangye/papers/1.Audio_and_Music_Analysis_and_Retrieval/2000_DFT,_DCT,_MDCT,_DST_and_Signal_Fourier_Spectrum_Analysis.pdf |
|
|
|
awxkee
|
2026-03-09 11:11:29
|
AFAIK the main advantages of MDCT are it's based on DCT-IV which means it's self-inverse, has odd symmetry and "overlapping" is more important for audio as you'll hear "clicks" between block boundaries when blocks are changing. And as far as I know those properties aren't super useful for images since image blocks are assumed to have even symmetry and blocking artifacts aren't absolutely important, since images are mostly LF content so it's possible to make smooth transition between blocks "by design" |
|
2026-03-09 11:13:13
|
If anyone by chance needs to run DCT-II, DCT-III, or DCT-IV in O(NlogN) for arbitrary sized DCT https://github.com/awxkee/pxdct 🙂 |
|
|
|
Demiurge
|
2026-03-09 11:36:34
|
Yet it made encode both significantly slower and uglier... |
|
|
|
jonnyawsom3
|
2026-03-09 11:43:51
|
Then make a PR |
|
2026-03-09 11:44:52
|
Because I'm not spending a month untangling 3 years of integration |
|
|
|
Demiurge
|
2026-03-10 02:03:28
|
Vibe-revert 😹 |
|
|
Jyrki Alakuijala
|
2026-03-10 01:10:16
|
MDCT is more or less useless, every sample is entropy coded twice (after transforms) |
|
|
|
AccessViolation_
|
2026-03-10 10:12:43
|
It's fair to say that JPEG XL ['follows' (Wikidata property P155)](<https://www.wikidata.org/wiki/Property:P155>) JPEG right? |
|
2026-03-10 10:14:31
|
> immediately prior item in a series of which the subject is a part, preferably use as qualifier of P179 [if the subject has replaced the preceding item, e.g. political offices, use "replaces" (P1365)] |
|
2026-03-10 10:15:43
|
I think it's correct in terms of scope of both formats, and this was also expressed in the paper, but I don't know if JPEG the organization agrees |
|
|
|
username
|
2026-03-10 10:16:29
|
"*immediately* prior" |
|
|
|
AccessViolation_
|
2026-03-10 10:17:20
|
yeah, I'm not sure about that, but in terms of the scope of both formats I think it works? |
|
2026-03-10 10:17:34
|
I suppose you could say JPEG 2000 should be in between them |
|
2026-03-10 10:17:41
|
but probably not any other JPEG formats |
|
2026-03-10 10:18:20
|
what do you think? JPEG -> JPEG 2000 -> JPEG XL? |
|
|
|
username
|
2026-03-10 10:21:27
|
IMO maybe this is something better just left unfilled |
|
|
|
AccessViolation_
|
2026-03-10 10:22:50
|
hm, why? |
|
|
|
username
|
2026-03-10 10:23:40
|
I mean it just *seems* like something that doesn't have an exact clear cut answer i guess |
|
|
|
AccessViolation_
|
2026-03-10 10:30:30
|
hmm okay, I'll remove it for now, see if others have input. it can always be re-added later |
|
|
CrushedAsian255
|
2026-03-11 06:05:56
|
JPEG XR maybe? |
|
|
|
_wb_
|
2026-03-11 06:46:45
|
I do think it makes sense to have a sequence JPEG, JPEG 2000 (aka JP2), JPEG XR, JPEG XT, JPEG XL, which is the chronological sequence of general-purpose image coding systems created by the JPEG committee. |
|
|
|
AccessViolation_
|
2026-03-11 02:14:06
|
Perfect, thank you |
|
|
|
Jyrki Alakuijala
|
2026-03-11 02:25:24
|
I'd like to have a serious discussion about JPEG XL progression in browsers |
|
2026-03-11 02:26:46
|
my original design principle was that during the progression only new image information appears, no such experiences/details are rendered that later go away during the progression -- this was to make the progression as tolerable as possible for sensitive individuals and also reduce the visual/sensory load for the rest of us |
|
2026-03-11 02:28:03
|
with this principle, the only (originally) supported subresolution was 8x8, and that resolution was with high color accuracy (unlike jpeg1 which allows/promotes lower bit representations for 8x8 dc progression) so that no banding artefacts exist even temporarily |
|
2026-03-11 02:29:34
|
during the development of JPEG XL a "progressive dc" feature has been added, which by default allows for all kinds of resolutions to be represented, possibly down to 2048x2048 (a single dc group) being represented by a single pixel |
|
2026-03-11 02:32:09
|
I'd like to maintain the default viewing progression in a way that after the first rendering the subsequent updates would be nearly unnoticeable at 4k and better resolutions -- we demonstrated what this looks like in https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html |
|
2026-03-11 02:34:41
|
Also, I'd like to buffer the first update to the time when the whole DC field is available, so that the first rendering of the photograph does not show some 2048x2048 areas (DC tiles) being refined first, and there would be no up-to-down or other refinements of these -- the first rendering is strictly when all of 8x8 has been received, and only then the DC is shown (as opposed to JPEG1 that would render from top to bottom usually during the streaming) |
|
2026-03-11 02:36:45
|
The only exposure to the user about the internal structure of the JPEG XL format would be the 256x256 AC tiles, which only add visual features to the (somewhat predictable, modulo patches/layers/splines/etc.) blurred DC rendering |
|
2026-03-11 02:37:30
|
my main motivation here is to not to make the experience worse than it is with other formats by creating visual stress to users |
|
2026-03-11 02:38:26
|
Apple -- a company that is quite thoughtful about user experience -- is completely staying away from progressive renderings in Safari, and I suspect that it is from similar concerns |
|
2026-03-11 02:39:12
|
but I believe we can make progression to work in a way where it gives an illusion of 6x faster loading times without creating visual stress |
|
2026-03-11 02:39:26
|
and possibly win Apple over in doing that 🙂 |
|
|
|
jonnyawsom3
|
2026-03-11 02:39:58
|
A while ago I proposed extending the existing (but unused) progressive level API https://discord.com/channels/794206087879852103/1464417869470371912/1465246205964714076
Then the default could still be 'smooth' detail refinement, but a flag could be added to browsers to let the user choose 'full' progressiveness in rural or poorly connected areas. Even allowing to disable progressiveness entirely for sensitive users/usecases |
|
2026-03-11 02:41:59
|
In the message I linked, you'd want the default to be FullFrame, but I could still pick Pass for when I'm travelling on mobile data, ect |
|
|
|
Jyrki Alakuijala
|
2026-03-11 02:42:43
|
in practice most users don't know how to configure a browser, but 99 % will use it with default settings |
|
2026-03-11 02:44:05
|
browsers do estimate the bandwidth of the connection so they could use such an API automatically, but there is a cognitive cost to varying rendering behaviour from day to day |
|
2026-03-11 02:44:51
|
it is good to look at the videos b, c and d on Moritz's blog post |
|
2026-03-11 02:45:00
|
d is the Apple case |
|
2026-03-11 02:45:45
|
the advantage in d is faster rendering, but the disadvantage is that things change (but it is limited how much they change, usually 2-3 pixels at most) |
|
|
|
jonnyawsom3
|
2026-03-11 02:45:57
|
Yeah, but then the option is there for those who need it. I think most here would agree, it would be a big shame if JPEG XL's extensive progressiveness was hidden by default or not accessible. |
|
|
|
Jyrki Alakuijala
|
2026-03-11 02:46:48
|
my thinking is that people don't care about what features JPEG XL has, they care if they get tired when using their computer |
|
2026-03-11 02:47:14
|
if people learn that it flickers, then they will buy Apple who turns it off altogether so that users get their peace |
|
2026-03-11 02:51:15
|
if there is a special flag, it will be 0.005 % of the people who will experiment with it, it is in general not worth it to do -- it might be a good idea to modulate the behaviour by low speed connections, but I'm not so sure about that -- exposing the users to the existance of the 2048x2048 dc groups, seems weird -- rendering dc-tile at a time, will make the progression a huge visual flash show |
|
2026-03-11 02:52:17
|
of course many images are today smaller than 2 M pixels (like facebook supposedly resamples to 2M), but people's own photos would be affected |
|
|
|
jonnyawsom3
|
2026-03-11 02:52:36
|
Currently DC doesn't render tile-by-tile, only complete passes of LF are rendered |
|
|
|
Jyrki Alakuijala
|
2026-03-11 02:52:53
|
good |
|
2026-03-11 02:53:48
|
something like rendering 8x8 in normal conditions and if low speed is detected automatically in the browser then dropping to 16x16 or 32x32 might be good (perhaps additionally modulated with flags related to users' visual preferences) |
|
2026-03-11 02:54:31
|
ideally it shouldn't be 2048x2048 (or even 64x64) pixels ever |
|
2026-03-11 02:55:19
|
also, it shouldn't be rectangular pixels even if modular would enable that (like 32x16) etc. as that will be a new visual experience, additional visual stress |
|
2026-03-11 02:56:18
|
but I think it is best to start with 8x8 only, that way 'progressive dc' and default dc will have the same visual behaviour and people would not learn that JPEG XL progressive flashes at viewing time |
|
2026-03-11 02:56:40
|
at least not more than usual JPEG1 |
|
2026-03-11 03:01:35
|
like there is a --force-prefers-reduced-motion flag in chromium that would turn progression off if it flashes |
|
|
|
jonnyawsom3
|
2026-03-11 03:03:46
|
As far as I'm aware, browsers already limit progressive loading to minimum intervals and load times, so I think it would already adapt to network speed. If you're at home on a decent connection, it loads the final pass. On a train in the countryside, you get a 1:16 preview to keep reading the site with
There's also the case of progressive lossless. It has no LF, and files are generally orders of magnitude larger, so I think the lower squeeze steps make a lot of sense there
'Easiest' way would be testing it while it's behind a flag, see what the default behaviour and user experience is, then adjust it according to feedback |
|
|
|
Jyrki Alakuijala
|
2026-03-11 03:10:14
|
with minimum intervals and load times you will get the occasional 2048x2048 pixeled image, also I believe that only the 8x8 subresolution image is properly blurred, i.e., doesn't introduce new artificial edges from the pixel grid (and likely only within the VarDCT use?) |
|
2026-03-11 03:11:54
|
progressive lossless -- When JPEG XL is correctly used in the web use case, I believe VarDCT will be used for photographs, and photographs are quite a bit more common and slower to load than the occasional graphics |
|
|
|
Exorcist
|
2026-03-11 03:13:18
|
> Apple -- a company that is quite thoughtful about user experience -- is completely staying away from progressive renderings in Safari, and I suspect that it is from similar concerns
I think they are just lazy |
|
|
|
Jyrki Alakuijala
|
2026-03-11 03:13:20
|
I am not a great believer in adjusting web things based on feedback, for example the green martians rendering and 8x8 full blocks didn't get much feedback, people didn't know that it could be improved |
|
|
|
jonnyawsom3
|
2026-03-11 03:13:28
|
When you say 2048x2048, you mean 1:2048 so 1 pixel is scaled up to fit a DC block?
Either decoding already skips it, or it decodes so quickly that I can't see it. When testing I notice 1:32, 1:16, 1:8, HF groups |
|
|
|
Jyrki Alakuijala
|
2026-03-11 03:17:25
|
yes |
|
2026-03-11 03:18:43
|
I suspect the 1:8 dc groups are interpolated properly with axis-non-separable filtering and the rest are just very big pixels |
|
2026-03-11 03:19:01
|
didn't watch jxl-rs on that, but in libjxl the 1:8 is beautifully interpolated |
|
2026-03-11 03:19:19
|
but 1:16 and 1:32 are likely not |
|
2026-03-11 03:19:34
|
the same for intermediate rectangular sizes |
|
2026-03-11 03:20:13
|
my thinking is that even if you show a blocky mess for 50 ms during the loading, it will grab some attention by movement detection "algorithms" in the human eye |
|
|
|
_wb_
|
2026-03-11 03:21:24
|
I think it would make sense to add css properties to control the way progressive rendering is done (so authors can indicate their preference), with a way to override it based on end-user preference (like "prefers reduced motion"). |
|
|
|
Jyrki Alakuijala
|
2026-03-11 03:21:55
|
Jobs was quite keen on getting usability details right and JPEG1 progressions were ugly before Moritz fixed them for libjpeg-turbo |
|
|
|
_wb_
|
2026-03-11 03:22:48
|
As things are now, authors tend to manually control it when they use some placeholder image that then gets replaced, or any other custom image loading mechanism. This of course doesn't give end-users any control. |
|
|
|
Jyrki Alakuijala
|
2026-03-11 03:23:37
|
every 10 years the internet gets 10x faster, so eventually this need will go away |
|
2026-03-11 03:24:13
|
I think we are beyond the point already where the users need to pay a cognitive price for the speed |
|
|
|
_wb_
|
2026-03-11 03:24:13
|
I'm not sure, the internet gets faster but the stdev of speed also grows |
|
2026-03-11 03:25:55
|
anyway, I do think the 1:16 and 1:32 previews jxl-rs produces now are beautiful too, and we need them if we want to make these manual placeholders go fully away |
|
|
|
Jyrki Alakuijala
|
2026-03-11 03:26:55
|
do we turn the 16/32 off when there is normal internet speed so they don't accidentally render |
|
|
|
jonnyawsom3
|
2026-03-11 03:27:20
|
The last thing I want is JXL's progressive loading to be inaccessible to those who need it. Be it via CSSS, browser flag, launch option or otherwise, I think we shouldn't cut out a feature from the people who need it most.
Not to mention, the Internet isn't just blog posts and ads. Photography sites, art boorus, scientific CDNs all handle very large files that could even be lossless. If you're waiting for the file you just clicked on to load, seeing it do so is preferable to nothing for the first 50% |
|
|
|
Jyrki Alakuijala
|
2026-03-11 03:27:22
|
say above 1 mbps |
|
|
|
_wb_
|
2026-03-11 03:28:55
|
if web devs still feel the need to use LQIP even when progressive JPEG already exists for a long time, clearly we have to do better than progressive JPEG. With only 1:8 previews the first preview is not earlier than in progressive JPEG, since even though JXL is smaller than JPEG, it has more stuff in the DC sections than JPEG does (the adaptive quant, CfL etc are also in DC groups) so it takes a bit longer until DC is available. |
|