JPEG XL

Info

rules 57
github 35276
reddit 647

JPEG XL

tools 4225
website 1655
adoption 20712
nomacs 7
UI 11
chrome 34
image-compression-forum 0

General chat

welcome 3810
introduce-yourself 291
color 1414
photography 3435
other-codecs 23765
on-topic 24923
off-topic 22701

Voice Channels

General 2147

Archived

bot-spam 4380

libjxl

gggol
2025-11-23 07:07:44
This is the one that Eye of Gnome couldn't view.
2025-11-23 07:14:30
The image is best compressed losslessly. This is the lossless compression of the original.
AccessViolation_
2025-11-23 08:28:58
thoughts on a minor modification to `jxl_cli` that would name the resulting binary `jxl-cli` (hyphen instead of underscore) when `cargo install`ed? it feels more appropriate. if yes, I can make the change
2025-11-23 08:29:52
it'd just be a change in `Cargo.toml` without actually changing the names of any packages
jonnyawsom3
2025-11-23 08:33:07
Could just make it jxl-rs to match the library name, or djxl-rs to match libjxl and prep for future encoding. I'm no expert
AccessViolation_
2025-11-23 08:39:01
yeah, sounds good to me too
2025-11-23 08:53:46
I guess that'd be a more contentious decision. replacing the underscore probably less so. a hyphen is much more common in cli tools so it'd be nice to match what people probably expect
2025-11-23 08:56:02
I also personally don't mind `jxl-cli` instead of `jxl-rs`, especially if it intends to become the reference implementation, superseding libjxl/cjxl
veluca
2025-11-25 10:20:25
djxl-rs?
monad
2025-11-25 11:02:08
djxl
Tirr
2025-11-25 11:06:09
I'd prefer `jxl -d` or something, not a strong opinion though
2025-11-25 11:07:27
(jxl-oxide has `jxl-oxide -d` for decode and `jxl-oxide -I` for info)
RaveSteel
2025-11-25 07:37:43
Tomorrow is libjxl v0.11.1's first anniversary🥳
Meow
 RaveSteel Tomorrow is libjxl v0.11.1's first anniversary🥳
2025-11-26 02:38:48
I don't know if this is a good news
AccessViolation_
2025-11-27 06:31:20
is it intended that libjxl dithers output for normal recompressed JPEGs (that are 8 bpc to begin with)?
jonnyawsom3
 AccessViolation_ is it intended that libjxl dithers output for normal recompressed JPEGs (that are 8 bpc to begin with)?
2025-11-27 06:35:20
https://discord.com/channels/794206087879852103/794206170445119489/1442562907488391320
AccessViolation_
2025-11-27 06:37:26
right, 12 bit, but don't JPEG encoders receive 8 bit inputs?
2025-11-27 06:39:39
never mind, jpegli
spider-mario
2025-11-27 06:48:15
even then, 8-bit -> (higher-precision processing) -> 8-bit should still, in principle, be redithered after the processing
AccessViolation_
2025-11-27 06:51:53
hmm, I get why that probably works in principle, but I think in practice people might wonder why their losslessly transcoded JPEG now looks noisy, where parts that were previously a flat color now have a sort of grain
2025-11-27 06:52:42
the effect is probably less obvious if your image viewers blurs pixels when zooming in, I should say I explicitly disabled that in EOG
spider-mario
2025-11-27 06:52:42
is it that noticeable?
AccessViolation_
 spider-mario is it that noticeable?
2025-11-27 06:55:12
spider-mario
2025-11-27 06:57:58
ah, right, the grid pattern kind of gives it away
AccessViolation_
2025-11-27 07:00:59
it's very noticeable in that one above, but when "blur images when zoomed in" is enabled they look close enough. of course the dithered one looks a bit better since the blur gradient will be smoother :)
lonjil
 AccessViolation_ hmm, I get why that probably works in principle, but I think in practice people might wonder why their losslessly transcoded JPEG now looks noisy, where parts that were previously a flat color now have a sort of grain
2025-11-27 07:01:24
a good image viewer should get the pixels in at least f16 from libjxl and then dither at whatever scale the image is being displayed at, so that the dither doesn't get bigger with zooming
AccessViolation_
2025-11-27 07:02:03
yeah I agree
jonnyawsom3
 AccessViolation_
2025-11-27 07:08:07
Use modern djxl
AccessViolation_
2025-11-27 07:08:42
I'm not sure why it's not doing blue noise dithering, it did before... maybe I downgraded and don't remember
2025-11-27 07:09:03
ah no that'd be because it's using the old one in EOG I suppose
monad
2025-11-28 04:19:38
EOG sucky
Demiurge
 AccessViolation_ is it intended that libjxl dithers output for normal recompressed JPEGs (that are 8 bpc to begin with)?
2025-11-28 11:26:57
Yes. 8 bit output should always be redithered. Even if the source is 8 bit. After being converted to JPEG it's no longer an image of 8-bit pixel data. It's in DCT representation and it has to be converted back to actual pixels. And if you're only using 8 bit output, then dither is definitely necessary if you don't want ugly banding artifacts.
AccessViolation_
2025-11-28 04:26:57
I was mainly thinking that in terms of appearance, the dithered output is far from lossless with respect to the original JPEG, but you could make the argument that it's wrong to display the original JPEG in 8 bit too, though presumably not according to the JPEG spec
lonjil
2025-11-28 04:59:02
the jpeg spec is really lose with what the output should be
jonnyawsom3
2025-11-29 09:36:12
Took another look at the 0.12 tracking issue <https://github.com/libjxl/libjxl/issues/4376> Seems like the only major things are the progressive noise bug https://github.com/libjxl/libjxl/issues/4368 and the JPEGLI PRs
A homosapien
2025-11-29 09:56:52
Hopefully we can get a release in by Christmas