JPEG XL

In case it's useful, I built https://random-stuff.jakearchibald.com/apps/partial-img-decode/ to view partial renderings in the browser. Although it doesn't seem like the JXL implementations support any kind of progressive rendering

username

	Jake Archibald In case it's useful, I built https://random-stuff.jakearchibald.com/apps/partial-img-decode/ to view partial renderings in the browser. Although it doesn't seem like the JXL implementations support any kind of progressive rendering
2025-10-03 01:12:39	there's a few other sites that do this. for example: - https://google.github.io/attention-center/ (uses and requires native browser support) - https://jxl-oxide.tirr.dev/demo/index.html (uses jxl-oxide compiled to WASM)

Jake Archibald

2025-10-03 01:13:07	<@794205442175402004> nah, it still seems like ~63k is still the first good render
	username there's a few other sites that do this. for example: - https://google.github.io/attention-center/ (uses and requires native browser support) - https://jxl-oxide.tirr.dev/demo/index.html (uses jxl-oxide compiled to WASM)
2025-10-03 01:16:20	Nice. I guess the benefit of mine is it work with any image format. But it's nice to have the WASM version for other browsers. It also matched what I was seeing on the command line. Thanks!
2025-10-03 01:17:26	I'm kinda surprised that JPEG significantly beats JXL to a representative first pass

_wb_

	Jake Archibald <@794205442175402004> nah, it still seems like ~63k is still the first good render
2025-10-03 01:36:14	hm, there should be a way to use a modular DC frame where you should get blurry previews after 1kb or less, at least when using a decoder that will show a partially decoded DC frame
2025-10-03 01:39:40	but it might be tricky to make it work, libjxl decode certainly doesn't do that, and it could be that libjxl encode doesn't produce very progressive bitstreams anymore, e.g. with the changes that were made for chunked encoding

Tirr

2025-10-03 01:40:09

it's `--progressive_dc 1`

_wb_

2025-10-03 01:42:31

that 63kb is probably the entire LF data, which in case of non-LF-frame encoding also includes HF metadata (block selection, adaptive quantization, etc), which is why regular JPEG can beat JXL: there is no HF metadata in case of JPEG, and also typical progressive scan scripts will skip the least significant bits of the DC in the first pass.

Jake Archibald

2025-10-03 01:57:05	Is `--progressive_dc` still a thing, or something that was removed?
2025-10-03 01:57:32	I guess I should try the output from Squoosh since it's on a much older version

lonjil

	Jake Archibald Is `--progressive_dc` still a thing, or something that was removed?
2025-10-03 02:21:00	it's still there
2025-10-03 02:21:41	``` --progressive_dc=num_dc_frames Progressive-DC setting. Valid values are: -1, 0, 1, 2. ```

Jake Archibald

2025-10-03 02:23:05

Cool, I'll try that

AccessViolation_

	veluca it's probably far from optimal (in fact I have known a probably-better splitting rule for a few years at this point)
2025-10-03 03:43:27	I'm curious what that other splitting rule is 👀

veluca

2025-10-03 04:03:36	Read my PhD thesis 😛
2025-10-03 04:03:57	(you can do dynamic programming to find multiple splits on a property at once)

CrushedAsian255

	veluca Read my PhD thesis 😛
2025-10-03 04:14:47	is it public?

veluca

2025-10-03 04:22:49

Yup

AccessViolation_

2025-10-03 04:23:54	I've found your page on google scholar
2025-10-03 04:24:24	it's probably one of these 40 publications on compression :)
2025-10-03 04:28:45	wait is it the one in italian lol
2025-10-03 04:31:30	that's fine I'll just implement libjxl's splitting method first and see how that fares xD

CrushedAsian255

	AccessViolation_ that's fine I'll just implement libjxl's splitting method first and see how that fares xD
2025-10-03 04:37:13	Splitting method as in working out the optimal sizes of VarDCT?

AccessViolation_

2025-10-03 04:52:12

no, splitting as in creating a good decision node in the MA tree

jonnyawsom3

	lonjil I don't recall the name of it, but there's an option called something like "downsample". I believe jf you set this to 8, you should get just the LF components of each DCT block.
2025-10-03 04:54:06	That just resizes the entire image internally, only used for ultra low quality or internally for the DC

lonjil

	That just resizes the entire image internally, only used for ultra low quality or internally for the DC
2025-10-03 04:55:23	There's a djxl option. It doesn't downsample, patches are still full resolution.

jonnyawsom3

	veluca ah, I wonder if this is streaming encoding doing weird things
2025-10-03 04:56:27	And yep, even with `-p`, images weren't progressive due to chunked. I made a few PRs in v0.12 to temporarily work around it and enable progressive DC too, but made an issue to track a more permanent fix and assigned you to it IIRC
	lonjil There's a djxl option. It doesn't downsample, patches are still full resolution.
2025-10-03 04:57:06	Oh you meant with djxl, that's just `-s 8`

veluca

	AccessViolation_ wait is it the one in italian lol
2025-10-03 04:59:35	No no

jonnyawsom3

	And yep, even with `-p`, images weren't progressive due to chunked. I made a few PRs in v0.12 to temporarily work around it and enable progressive DC too, but made an issue to track a more permanent fix and assigned you to it IIRC
2025-10-03 05:06:49	https://github.com/libjxl/libjxl/issues/4328
	lonjil I wonder if this is djxl just being a little silly and not outputting as much as it could, or if the file has an odd order.
2025-10-03 05:08:38	Also yes, LQIP (low quality image preview) was disabled in libjxl years ago for performance reasons, so it can no longer render before the first full image pass

AccessViolation_

	veluca No no
2025-10-03 05:12:47	many of these papers you've (co-)authored are about the types of things that interest me too so I might read some of them over the weekend

jonnyawsom3

	_wb_ If you encode with -p you should get that iirc
2025-10-03 05:14:22	That's only with my v0.12 PRs, so not released yet. As Tirr said, manually specifying it works though
	Jake Archibald I guess I should try the output from Squoosh since it's on a much older version
2025-10-03 05:17:42	If you want to try progressive lossless too, I'd highly recommend grabbing a new build from https://artifacts.lucaversari.it/libjxl/libjxl/latest/ Like I said in my other replies, we did a lot of work on progressive in the upcoming version, including fixing it so that it works at all. Plus the Oxide WASM demo is great to test it

lonjil

	Also yes, LQIP (low quality image preview) was disabled in libjxl years ago for performance reasons, so it can no longer render before the first full image pass
2025-10-03 05:26:40	I wasn't talking about any LQIP, just the LF.

jonnyawsom3

	lonjil I wasn't talking about any LQIP, just the LF.
2025-10-03 05:27:32	Yeah, that's the name for partial LF decoding

veluca

	AccessViolation_ many of these papers you've (co-)authored are about the types of things that interest me too so I might read some of them over the weekend
2025-10-03 05:27:48	heh, I feel like my papers change between 5ish mostly unrelated topics

lonjil

2025-10-03 05:27:48

I wasn't talking about partial LF decoding.

jonnyawsom3

	lonjil I wasn't talking about partial LF decoding.
2025-10-03 05:30:20	Then what did you mean by > I wonder if this is djxl just being a little silly and not outputting as much as it could

lonjil

	Then what did you mean by > I wonder if this is djxl just being a little silly and not outputting as much as it could
2025-10-03 05:31:34	Nothing in particular. I can't know exactly how djxl will behave in every situation.

Jake Archibald

	lonjil it's still there
2025-10-04 08:56:31	oh lol it only appears in `cjxl --help -v -v`
2025-10-04 09:04:40	`--progressive_dc 1` was absolutely what I was missing here. I now get a render in 2kb, and an "I can tell what it is" render in 6kb. This is via `jxl-oxide`, not `djxl`, which still waits until 60kb. Thanks folks! Why isn't `--progressive_dc 1` the default?

Mine18

	Jake Archibald `--progressive_dc 1` was absolutely what I was missing here. I now get a render in 2kb, and an "I can tell what it is" render in 6kb. This is via `jxl-oxide`, not `djxl`, which still waits until 60kb. Thanks folks! Why isn't `--progressive_dc 1` the default?
2025-10-04 09:57:34	is it not with `-p`?

Jake Archibald

2025-10-04 10:01:26	Not with `-p`
2025-10-04 10:02:28	That didn't produce what I was looking for. I was aiming for an early-as-possible render that had enough detail so you could tell what the image was.

username

2025-10-04 10:04:09	what version of libjxl are you using? because the nightly versions should have this fixed with this PR: https://github.com/libjxl/libjxl/pull/4258
2025-10-04 10:04:27	0.12 whenever that releases formally should have this

jonnyawsom3

	Jake Archibald `--progressive_dc 1` was absolutely what I was missing here. I now get a render in 2kb, and an "I can tell what it is" render in 6kb. This is via `jxl-oxide`, not `djxl`, which still waits until 60kb. Thanks folks! Why isn't `--progressive_dc 1` the default?
2025-10-04 10:06:32	I made it so that progressive dc is used in `-p`, but that update isn't released yet. As for why it's not default, it had some hefty memory usage and speed penalties in the past. We improved it a lot, but it's still almost 2x slower and a bit larger, so still opt-in for now

username

2025-10-04 10:08:39

speaking of what's the difference between setting `--progressive_dc` to `1` vs `2`?

jonnyawsom3

	username speaking of what's the difference between setting `--progressive_dc` to `1` vs `2`?
2025-10-04 10:11:10	```--progressive_dc=-1..2 Number of progressive-DC frames, default = -1. -1 = encoder chooses. 0 = disable. 1 = extra 64x64 low-resolution pass. 2 = extra 512x512 and 64x64 passes.``` Basically another 'full pass' opportunity for progressive loading massive images
	username what version of libjxl are you using? because the nightly versions should have this fixed with this PR: https://github.com/libjxl/libjxl/pull/4258
2025-10-04 10:11:26	https://artifacts.lucaversari.it/libjxl/libjxl/latest/

Jake Archibald

	I made it so that progressive dc is used in `-p`, but that update isn't released yet. As for why it's not default, it had some hefty memory usage and speed penalties in the past. We improved it a lot, but it's still almost 2x slower and a bit larger, so still opt-in for now
2025-10-04 10:12:47	Makes sense, thank you!

jonnyawsom3

2025-10-04 10:13:58

Hopefully once jxl-rs is done, there'll be more motivation for ultra progressive encoding

_wb_

2025-10-04 11:41:50	With super progressive rendering, the trade-off is always between showing more passes and spending the compute on doing those intermediate renders (which also takes some time that might delay the final render). What trade-offs make sense depend a lot on current network conditions.
2025-10-04 11:45:37	There are certainly times, especially on the road, when the network is so bad that basically I'd like to see any image data available no matter how much decode time overhead that's causing. But when on a good, fast network (or of course when loading images from local cache), probably no progressive passes should be shown at all.

jonnyawsom3

2025-10-04 11:49:40

I made a suggestion on the jxl-rs repo a while ago. A simple timeout would work well, if the connection drops just render whatever we've got https://github.com/libjxl/jxl-rs/issues/387#issuecomment-3312545154

CrushedAsian255

	_wb_ With super progressive rendering, the trade-off is always between showing more passes and spending the compute on doing those intermediate renders (which also takes some time that might delay the final render). What trade-offs make sense depend a lot on current network conditions.
2025-10-05 06:20:24	Maybe have it only perform a pass every X seconds or something?
2025-10-05 06:20:48	so if the entire file loads in < X seconds, then it just displays all at once, so no overhead

jonnyawsom3

2025-10-05 06:28:00

I suggested targeting TOC entries to render at, but rendering anyway on the timeout, or skipping if more has already been downloaded

New Player 🇩🇪

2025-10-05 07:04:02

webp annoys me, its getting used more and more its its kinda outdated

Meow

	New Player 🇩🇪 webp annoys me, its getting used more and more its its kinda outdated
2025-10-05 10:24:37	This applies to other formats as well

Mine18

2025-10-05 12:43:02

id rather webp than gif

Jake Archibald

2025-10-06 07:14:47

<@238552565619359744> if the connection drops, browsers tend to clear the rendering of the image, and fire an error event

jonnyawsom3

	Jake Archibald <@238552565619359744> if the connection drops, browsers tend to clear the rendering of the image, and fire an error event
2025-10-06 07:17:51	The Firefox integration is in progress, so it could be changed. Depends how far along the download is, since 25% of a JXL is still pretty good quality

Jake Archibald

	The Firefox integration is in progress, so it could be changed. Depends how far along the download is, since 25% of a JXL is still pretty good quality
2025-10-06 07:25:06	The amount of image available depends on how it's encoded. But, what you're talking about is a pretty big break from what browsers currently do, so it should be done with care. Currently, if an image fails to download, Firefox renders the alt text instead. You're talking about changing that, which shouldn't be done on a whim.

jonnyawsom3

2025-10-06 07:26:50	The integration should follow the built-in TOC of each file, so it would be easy to tell when to render and when to abort
2025-10-06 07:27:30	But I see your point, maybe I'm just on an old version because I don't see that behaviour on my phone

Jake Archibald

2025-10-06 07:30:15	I could be talking shit 😄
2025-10-06 07:31:08	If other formats hold their partial rendering after a connection failure, then of course I'm wrong
2025-10-06 07:33:09	How do I test the latest JXL integration in Firefox? I assume it's different to `image.jxl.enabled`?

jonnyawsom3

2025-10-06 07:35:04

Right now you need to compile it yourself, and progressive isn't actually implemented yet. All I did was put forth a proposal of how it could work

Jake Archibald

	Right now you need to compile it yourself, and progressive isn't actually implemented yet. All I did was put forth a proposal of how it could work
2025-10-06 07:39:53	Ah ok. Makes sense
2025-10-06 07:42:17	<@238552565619359744> I think you agree already, but I think the early-as-possible-but-you-can-tell-what-it-is rendering (as seen with `progressive-dc`) is the most important here, rather than the "it's almost ready" renderings. It could do with some blurring, like you see with `djxl` and its initial rendering (although that's much later)

jonnyawsom3

2025-10-06 07:47:14	Like I said, it should use the TOC to know if it's legible or not. It can adapt to the network, skipping progressive, rendering 1:8 without DC, or loading per power of 2 if the network is very slow
2025-10-06 07:50:34	(again depending on encode settings, but websites should be using the progressive flag)

Jake Archibald

2025-10-06 08:01:18	I think we're talking about a different thing here. `djxl` and the decoder that went into Chromium doesn't seem to do anything with `progressive_dc`, which seems bad.
2025-10-06 08:02:45	Even through Chromium handled later progressive stuff, it missed, imo, the most important opportunities

jonnyawsom3

2025-10-06 08:05:15

Chromium is 3 years old at this point and used what libjxl exposes. Firefox is getting a brand new decoder which has the same progressiveness of jxl-oxide

Jake Archibald

2025-10-06 08:06:39

For block rendering `cjxl` supports left-to-right, top-to-bottom, and center-out. Does the format technically support arbitrary block ordering?

jonnyawsom3

2025-10-06 08:08:03	Yeah, centre-out is just an example, as we don't have an easy tool to customise it right now
2025-10-06 08:08:55	I'd love a little program with a UI to re-order JXLs. Could make some fun loading shapes with it

Jake Archibald

2025-10-06 09:05:25

Yeah, or just optimise loading of a photo with multiple focal points, like a group photo

jonnyawsom3

2025-10-06 09:06:06

Yeah, I assume you saw the old Google saliency demo

Jake Archibald

2025-10-06 09:24:18

ohhh, I had, but had forgotten about it

_wb_

2025-10-06 10:34:04

Besides arbitrary group ordering, you can also do progressive passes where the amount of detail added depends on the region. Unlike JPEG where each pass corresponds to a selection of coefficients and significant bits and is the same for the whole image, and once a bit is signalled there is no way to revise it in a future pass, in JXL every pass can update any bit in any coefficient. So you could in the first pass signal blocks inside the faces at higher precision than blocks in the background, etc.

2025-10-06 10:35:41

(but libjxl doesn't have any mechanism to do such variable-precision passes, it would require quite a bit of API to pass precision weight maps or something so we haven't bothered doing that; it's just a bitstream feature, not something libjxl exposes)

jonnyawsom3

2025-10-06 10:47:57

There's a lot that's built into the format but not libjxl yet, it's quite futureproof

Quackdoc

	Jake Archibald The amount of image available depends on how it's encoded. But, what you're talking about is a pretty big break from what browsers currently do, so it should be done with care. Currently, if an image fails to download, Firefox renders the alt text instead. You're talking about changing that, which shouldn't be done on a whim.
2025-10-06 12:56:21	this is behavior that I generally dislike, since an image can be loading and the user can see it loading, it should just fail

Jake Archibald

	Quackdoc this is behavior that I generally dislike, since an image can be loading and the user can see it loading, it should just fail
2025-10-06 01:37:36	Which part do you dislike? I don't think I understand

Quackdoc

2025-10-06 01:43:08

disappearing images that were already loading but failed midload

jonnyawsom3

2025-10-06 02:37:21

The only downside to JXL art, the HTTP header is over 20x the size of the actual image

Jake Archibald

	Quackdoc disappearing images that were already loading but failed midload
2025-10-06 04:17:05	I guess it's an issue of user expectation. How would they know the difference between a 'broken' image download and one just taking a while?

jonnyawsom3

2025-10-06 04:20:05

The loading bar not being finished

CrushedAsian255

	Jake Archibald Yeah, or just optimise loading of a photo with multiple focal points, like a group photo
2025-10-06 10:53:55	Maybe that is a good use of ML, determining salience

Quackdoc

2025-10-06 11:52:27	how hard would it be for cjxl to support `--streaming_input` for jxl input?
2025-10-06 11:54:08	cjxl keeps ooming on a bunch of images for me

Orum

2025-10-06 11:54:17	so decode and encode only a portion of the original image at a time?
2025-10-06 11:54:28	just use ppm?

Quackdoc

2025-10-06 11:55:05

that would involve decoding the image to ppm first which is a round trup that wouldnt help at all since I would need to decode to a tmpfs anyways

Orum

2025-10-06 11:56:57

decode to SSD <:CatSmile:805382488293244929>

Quackdoc

2025-10-06 11:57:02

[omegalul~1](https://cdn.discordapp.com/emojis/885026577618980904.webp?size=48&name=omegalul%7E1)

Orum

2025-10-06 11:57:45

or just download some more ||z||ram

Quackdoc

2025-10-06 11:58:04

I tried, doesnt work on android, well on lineageOS anyways [omegalul~1](https://cdn.discordapp.com/emojis/885026577618980904.webp?size=48&name=omegalul%7E1)

Orum

2025-10-06 11:58:32

oh, you're running it on a phone.... no wonder you're running out of memory

Quackdoc

2025-10-06 11:58:46	I mean,. 4g of ram really should be enough for this
2025-10-06 11:58:57	streaming input would fix a lot of the issues

Orum

2025-10-06 11:59:40

are you using `-e 1`?

Quackdoc

2025-10-07 12:00:19	`e7`
2025-10-07 12:00:32	e 1 not good enough for me [dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=dogelol)

Orum

2025-10-07 12:00:56	if you're running out of memory and not using `-e 1` then what are you even doing <:WhatThe:806133036059197491>
2025-10-07 12:01:36	save e >1 for the desktop or server <:PeepoDiamondSword:805394101340078092>

Quackdoc

2025-10-07 12:02:38

never [megareee](https://cdn.discordapp.com/emojis/912393017741160479.webp?size=48&name=megareee)

Orum

2025-10-07 12:02:59

that said, yes cjxl uses a lot of memory, and yes it'd be nice if it used less, but still there are options that do reduce the memory footprint substantially

Quackdoc

2025-10-07 12:03:02

only one more month until black friday, I need my poor phone to hold on until then lol

Orum

2025-10-07 12:03:24

"I'm tired boss 😩" - Your phone

Quackdoc

2025-10-07 12:04:15

bro has no idea, my pops got this phone when it was brand new, and I got it when my s9+ decided it's screen no longer wanted to display color for some reason

Orum

2025-10-07 12:04:39

well at least the battery didn't explode

Quackdoc

2025-10-07 12:04:53	true
2025-10-07 12:05:22	but man, the lg is a beast, lg g7 thinq, still get a full day battery if im not on it 24/7, non stop use for 7 years, not a single part replaced

Orum

2025-10-07 12:09:04	I wish I knew why my phone randomly disconnects from the cellular network all the time
2025-10-07 12:09:24	other than that it's great

Quackdoc

2025-10-07 12:20:41

probably changing towers

Orum

2025-10-07 12:20:54

yeah but it does it all the fucking time

Quackdoc

2025-10-07 12:21:06

weird, what phone?

Orum

2025-10-07 12:21:18	Poco X5 Pro running Lineage
2025-10-07 12:21:44	not sure if it's even a HW or a SW problem at this point

Quackdoc

2025-10-07 12:24:49

IIRC i've heard of similar issues with pocos before

Orum

2025-10-07 12:30:33

honestly I should probably just move to crdroid

Quackdoc

2025-10-07 12:36:00	i've had a lot of issues with crdroid whenever I used it
2025-10-07 12:36:15	tho if you have the free space you could try gsi images easily enough [dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=dogelol)

Orum

	Quackdoc i've had a lot of issues with crdroid whenever I used it
2025-10-07 12:38:19	yeah well you have issues with literally every piece of software on the planet <:KekDog:805390049033191445>
2025-10-07 12:38:24	what issues though?

Quackdoc

2025-10-07 12:44:07

I had a few issues, for one oom tuning was way out of wack, to the point that even 6gb phones would oom in ridiculous situations, this was somewhat fixable with some root commands, the other issue I found myself hitting fairly often was sometimes on reboot the notification led would never stop blinking which was immensely annoying

Orum

2025-10-07 01:05:05

you put Gapps on it or not?

Quackdoc

2025-10-07 02:09:22	hell no
2025-10-07 02:09:38	gapps can go die in a fire, microg supremacy

username

2025-10-07 02:31:15	<@794205442175402004> If possible do you have the time to (re-)review the [blue noise PR for libjxl](https://github.com/libjxl/libjxl/pull/4305)? I understand if you are busy or otherwise however I'm pinging you with this just in case it's something that simply flew under your radar
2025-10-07 02:32:37	oh I probably should have posted this in <#804324493420920833> whoops

_wb_

2025-10-07 02:33:05	no worries, and yes I forgot about that one
2025-10-07 02:41:26	since the off-by-one errors caused by doing +0.5 are fixed and conformance passes again, I don't really see why not improve the dithering, so I approved it
2025-10-07 02:41:48	(there will be a tiny cost in binary size and decode speed but I think we can ignore that)

diskorduser

2025-10-07 03:24:38

So it replaces photon noise hereafter?

jonnyawsom3

2025-10-07 03:40:24

No, it just replaces the 8x8 bayer dither

username

2025-10-07 03:51:07

it's used when decoding a high bit depth image to a lower bit depth

_wb_

2025-10-07 04:04:10

It's not causing visible noise, it is meant to reduce potential banding when decoding an image to 8-bit (or I suppose other bit depths where banding might still be an issue, like 10-bit PQ). Simply quantizing the internal float32 pixel values to uint8 can cause banding that isn't actually there in the image signal, so applying some dithering is useful to mitigate that. The amplitude of this dithering is low enough to not change any pixel value if the image is a lossless uint8 image, so it is pretty different from photon noise which can have a way stronger amplitude and can create intentionally visible noise that mimicks the actual photon noise caused by the effect of light coming in discrete photons, so photos captured in low-light conditions inherently have sampling noise in them. Also jxl's photon noise operates in XYB to create mostly luma noise, while this dithering step operates in RGB at the very end, when converting float32 to uint8 (or whatever other integer type) and applies equally and independently to each color component.

screwball

2025-10-08 05:40:35	<@245794734788837387> you may wanna tell eustas to update the "Release v0.12.0" checklist
2025-10-08 05:40:49	since that PR is now merged

AccessViolation_

2025-10-08 06:13:42	The JPEG XL Wikipedia article is a bit of a mess in certain sections so I'm in the process or rewriting and rephrasing certain sections. Do you consider this an improvement? Original: > The JPEG XL Image Coding System[7] is a free and open standard for a compressed raster image format. It defines a graphics file format and the abstract device for coding JPEG XL bitstreams. It is developed by the Joint Photographic Experts Group (JPEG) and standardized by the International Electrotechnical Commission (IEC) and the International Organization for Standardization (ISO) as the international standard ISO/IEC 18181. As a superset of JPEG/JFIF encoding, it features a compression mode built on a traditional block-based transform coding core. Additionally, there is a "modular mode" for synthetic image content and lossless compression. Optional lossy quantization enables both lossless and lossy compression.
2025-10-08 06:14:04	Edited: > The JPEG XL Image Coding System[1] (JPEG XL, sometimes shortened to JXL) is an image format that supports lossy and lossless compression. It was developed by the Joint Photographic Experts Group (JPEG), Google and Cloudinary. It is a free and open standard defined by ISO/IEC 18181. The standard is made up of four parts that cover the Core coding system, File format, Conformance testing, and Reference software, respectively. It features a lossy compression mode called VarDCT that's built on block-based transform coding which is similar to — but significantly improves and expands upon — the compression method of JPEG, and a modular mode that allows different features of the format to be combined in a "modular" way. Modular mode can be used to achieve mathematically lossless image compression, similar to PNG, and in other combinations that result in different lossy and lossless compression methods.
2025-10-08 06:17:15	I think the way it was originally written might overwhelm people reading this that aren't very familiar with image formats or leave them with more questions than answers

afed

2025-10-08 06:30:25

(JPEG XL, sometimes shortened to JXL, but not JPEG-XL) <:KekDog:805390049033191445>

AccessViolation_

2025-10-08 06:40:00	published, feel free to edit, or revert if anyone has major qualms
2025-10-08 06:41:09	I'll be going through the article and making more edits like this
	afed (JPEG XL, sometimes shortened to JXL, but not JPEG-XL) <:KekDog:805390049033191445>
2025-10-08 06:43:38	my previous edit was actually removing instances of "JPEG-XL" in the article...

jonnyawsom3

	screwball <@245794734788837387> you may wanna tell eustas to update the "Release v0.12.0" checklist
2025-10-08 06:58:18	It's not urgent, more will be added and marked on the list as PRs are picked

A homosapien

2025-10-08 09:08:31

I hope 0.12 comes out this year

jonnyawsom3

	A homosapien I hope 0.12 comes out this year
2025-10-08 10:00:51	I hope we can get more of my braches ready for it

cioute

2025-10-08 10:30:07

when google chrome will supports jpegxl?

juliobbv

	afed (JPEG XL, sometimes shortened to JXL, but not JPEG-XL) <:KekDog:805390049033191445>
2025-10-08 10:34:49	we should go the katakana route and start calling it ジェーペグ・ＸＬ

derberg🛘

2025-10-09 12:57:27

This should be added to the name of the guild, then an anime banner showing perks of the format and ofc a guild tag (would propose JPEG rather than JXL for the tag cause people rather know about the former and might be curious because of that). Just needs some nitro boosts for that.

Meow

	juliobbv we should go the katakana route and start calling it ジェーペグ・ＸＬ
2025-10-09 02:25:58	XL エックスエル

derberg🛘

2025-10-09 04:01:04	次世代の画像ファイル形式「JPEG XL」
	Meow XL エックスエル
2025-10-09 04:03:19	But okay that is more funny. Also needs a logo inspired by the one anime logo that everybody is copying for their software logos

jonnyawsom3

	derberg🛘 This should be added to the name of the guild, then an anime banner showing perks of the format and ofc a guild tag (would propose JPEG rather than JXL for the tag cause people rather know about the former and might be curious because of that). Just needs some nitro boosts for that.
2025-10-09 08:58:08	It was actually decided here that JXL will be the standard term, as "JPEG XL" doesn't actually have any meaning. We also already get some confused people joining for help with their classic JPEGs by accident

Meow

2025-10-09 09:00:51

ジェーエックスエル

derberg🛘

2025-10-09 09:01:28	Well, when clicking on a guild tag there is a small preview showing guild name and banner image.
2025-10-09 09:03:55	E.g. this appears when clicking on the "AV1" tag next to the username shown in the screenshot. Discord on Android. Only looks slightly different on desktop.

Lumen

2025-10-09 09:08:41

butterdog approved x)

jonnyawsom3

	It was actually decided here that JXL will be the standard term, as "JPEG XL" doesn't actually have any meaning. We also already get some confused people joining for help with their classic JPEGs by accident
2025-10-09 09:20:11	https://discord.com/channels/794206087879852103/822105409312653333/1412357666482683925
	derberg🛘 Well, when clicking on a guild tag there is a small preview showing guild name and banner image.
2025-10-09 09:20:45	Yeah, the first step regardless would be getting the boosts to do it

Demiurge

2025-10-10 05:58:16	Last I checked the entire wiki article looked like it was written by an AI and was completely bizarre
2025-10-10 05:58:32	Should just be rewritten from scratch. There's no fixing that
2025-10-10 06:00:51	Also it seems kind of a waste to donate time working for wikipedia for free when your time is valuable.
2025-10-10 06:02:02	Even if it's for an important topic like JXL, I don't really feel like it's right to work for Wikipedia for free
2025-10-10 06:02:36	Is there a codec wiki?
2025-10-10 06:06:04	Wikipedia has an extremely low standard of quality, or no standard at all, with seemingly arbitrary enforcement and unclear scope.
2025-10-10 06:07:11	I feel like time spent on wikipedia is largely a waste of time

A homosapien

2025-10-10 06:08:26

Actually, there is a codec wiki being worked on https://wiki.x266.mov/

Demiurge

2025-10-10 06:08:43

https://wiki.x266.mov/docs/images/JXL

monad

	Demiurge Even if it's for an important topic like JXL, I don't really feel like it's right to work for Wikipedia for free
2025-10-10 09:12:36	Is it better to work for Discord for free?

Demiurge

2025-10-10 09:29:31

No? Discord is probably worse. But... it would be cool to have jxl support in more online services such as discord. And they did release their image preview backend "lilliput" under the free MIT license.

jonnyawsom3

	Demiurge No? Discord is probably worse. But... it would be cool to have jxl support in more online services such as discord. And they did release their image preview backend "lilliput" under the free MIT license.
2025-10-10 09:31:07	They already said they want to add support https://discord.com/channels/794206087879852103/803950138795622455/1381771491774959709

lonjil

	Demiurge No? Discord is probably worse. But... it would be cool to have jxl support in more online services such as discord. And they did release their image preview backend "lilliput" under the free MIT license.
2025-10-10 09:33:40	And Wikipedia articles are released for free under a Creative Commons license!

Demiurge

2025-10-10 09:39:37	I honestly think it's weird that imageboards/booru don't use jxl yet. They don't have a problem converting videos to crappy webm format but they somehow have a problem with lossless image conversion?
2025-10-10 09:42:04	If I had an imageboard running on my server I would love the opportunity to save terabytes of storage and bandwidth.

jonnyawsom3

2025-10-10 09:55:22

Well it's pretty obvious why, because only 1 major browser supports it

Demiurge

2025-10-10 11:03:16	Safari is pretty major though
2025-10-10 11:03:41	Plus windows has built in support at the platform level
2025-10-10 11:05:50	And it would already be enabled by default in Chromium/Edge if the AVIF creator didn't personally step in and abuse his senior position on the Chromium team, let's be real here.

lonjil

2025-10-10 11:07:52

AFAIK Edge doesn't use Chrome's codec code anyway

username

	Demiurge And it would already be enabled by default in Chromium/Edge if the AVIF creator didn't personally step in and abuse his senior position on the Chromium team, let's be real here.
2025-10-10 11:09:10	I see it as a team failing. attributing the blame on one single person seems kinda dangerous tbh

HCrikki

2025-10-11 12:01:14

imo the lack of origin trials doomed the verbal proclamations of support. origin trials basically force enable specific flags for a predetermined number of websites that can also be cdns. publicly accessible live deployments with high enough traffic will be essential (small hobbyist sites with no traffic would not contribute diverse enough performance feeback)

Demiurge

	lonjil AFAIK Edge doesn't use Chrome's codec code anyway
2025-10-11 07:59:42	JXL support worked in Edge until they updated the Chromium engine to the version that diked out the JXL codec code
2025-10-11 08:00:00	So yeah, they do...
2025-10-11 08:00:31	The only reason Edge doesn't still support JXL is because it was removed from Chromium...
2025-10-11 08:00:45	Which Edge depends on
	username I see it as a team failing. attributing the blame on one single person seems kinda dangerous tbh
2025-10-11 08:03:24	Holding leaders accountable for executive decisions they are supposed to be responsible for is not what's dangerous.
2025-10-11 08:13:08	What's ACTUALLY dangerous is when people in positions of power, who are trusted with leadership positions, are able to abuse that position for personal, ego-driven reasons without any accountability at all for all of the downstream effects their decision has. No one appointed this On2 guy to be the Browser God, telling us all from On High that JXL is unworthy
2025-10-11 08:14:44	Google just gave him a nice position as part of Google's acquisition deal with the On2 VP8 team
2025-10-11 08:16:11	Trusted as a subject matter expert on web multimedia codecs

Exorcist

2025-10-11 08:16:34

Demiurge

2025-10-11 08:17:14	No one expected avif/jxl to be competitors until he declared war on JXL
2025-10-11 08:17:27	They were going to be used for what they were good at
2025-10-11 08:17:35	There isn't a lot of overlap
2025-10-11 08:18:16	AVIF is not designed to do what JXL is good at and vice versa

Exorcist

2025-10-11 08:22:32

AVIF in Chrome still not support partial loading Google may think "partial loading is not needed if images are small enough"

Demiurge

2025-10-11 08:24:07	I don't think this is about money actually because I think money favors both of them
2025-10-11 08:24:41	This is someone's midlife crisis
2025-10-11 08:26:02	Who just happens to be in a position of power where their crisis has far reaching consequences that affect everyone downstream from the Chromium project

jonnyawsom3

2025-10-11 08:26:17

We don't need the same rant every other week, we all know Chrome got rid of it, we know there's no official reason

cioute

2025-10-11 08:28:09

Why so hard add jxl support in browser?

Demiurge

	We don't need the same rant every other week, we all know Chrome got rid of it, we know there's no official reason
2025-10-11 08:32:23	Well it's so cartoonishly clownish and hard to believe such an absurd conflict of interest is allowed to stand for so long without any challenge or ridicule. And I don't understand what is "dangerous" about holding leaders accountable either? Isn't that the whole point of being a leader is to be the one responsible?
2025-10-11 08:37:37	Isn't it more dangerous to pretend like it's all normal?
2025-10-11 08:39:13	It's ridiculous and maybe if people actually ridiculed it more like they should, someone from Google might notice or get embarrassed enough to actually respond in some way.

Quackdoc

	cioute Why so hard add jxl support in browser?
2025-10-11 12:57:27	its not hard, it's hard to do it safely and in a way where minimal maintenance will be necessary on the browser developers side of things

spider-mario

2025-10-11 01:46:31

I find it funny to try and picture the alternative timeline where AVIF won the JXL call for proposals in 2018 (instead of PIK & FUIF) and ended up _being_ JPEG XL

jonnyawsom3

2025-10-11 01:48:48	Modular mode and AV1 instead of VarDCT
2025-10-11 01:50:08	That gave me a cursed idea of translating AVIF coefficients into a JXL to prove we can hit the same density/quality, but I have had a few to drink so maybe it's just hypothetical

Exorcist

2025-10-11 02:07:36

It is more meaningful if H264 become WebP

jonnyawsom3

2025-10-11 02:43:13

What?

A homosapien

	We don't need the same rant every other week, we all know Chrome got rid of it, we know there's no official reason
2025-10-11 05:45:04	I thought the official reason was that "there wasn't enough interest from the internet ecosystem" to justify adding it to chrome

cioute

2025-10-11 06:11:33

But jpegxl is a better jpeg, not adding support in browser is sabotage of progress.

Quackdoc

	cioute But jpegxl is a better jpeg, not adding support in browser is sabotage of progress.
2025-10-11 06:13:37	mozilla already laid out a path, its just waiting for the library to mature enough now
2025-10-11 06:13:58	wait for firefox, and it will snowball from there

HCrikki

2025-10-11 08:09:45

we should have unofficial firefox nightly builds with the support added at least for folks to test and contribute feedback for. anyone making working ones for themselves should share

Demiurge

	Quackdoc wait for firefox, and it will snowball from there
2025-10-11 08:32:45	Hopeful thinking. As if Firefox has any relevance or influence left anymore...
2025-10-11 08:33:22	Then again Google is shooting Chrome in the back of the head with their Manifest API changes

Quackdoc

	Demiurge Hopeful thinking. As if Firefox has any relevance or influence left anymore...
2025-10-11 09:03:16	Google doesn't like being known as the only browser not to support X feature
2025-10-11 11:19:07	batch encoded a wack load of images, one folder I got this, meaning that 50 encodes had a ssimu2rs score of below 80, most of these were around 77 or so, Used jxl-oxide + ssimulacra2-rs which is a factor, but all in all, super solid results. all of the input is png.jxl but this is still nice since it's not a hard error with cjxl which is nice. `cjxl --streaming_input --streaming_output -d 1 -e 7 "$file" "$base-d1e7.jxl"` ```ps ➜ l .png.jxl \| wc -l 50 ➜ l .jxl-d1e7.jxl \| wc -l 5932 ```
2025-10-11 11:24:26	all in all so far across the many folders I have encoded I've said 12gib by encoding 13665 lossless jxl images to lossy with at least an ssimu2rs score of 80 or higher

gb82

	spider-mario I find it funny to try and picture the alternative timeline where AVIF won the JXL call for proposals in 2018 (instead of PIK & FUIF) and ended up _being_ JPEG XL
2025-10-14 03:38:45	I think about this a lot
	Exorcist It is more meaningful if H264 become WebP
2025-10-14 03:38:59	https://tenor.com/view/mundo-feliz-onetreehsll-world-if-gif-14071235670792471304

juliobbv

	gb82 I think about this a lot
2025-10-14 04:52:13	I do wonder how would a psychovisually-oriented tune would've looked like for an AV1-based JXL product
2025-10-14 04:53:43	as in, would more coding tools be added to the format?

gb82

2025-10-14 05:02:22	true, what a world that'd be
2025-10-14 05:02:36	at the very least, lossless jpeg recompression right?
2025-10-14 05:03:01	and lossless?
2025-10-14 05:03:12	oh and a better container

Apathy

	Demiurge Hopeful thinking. As if Firefox has any relevance or influence left anymore...
2025-10-14 06:14:57	Influence is shockingly something Mozilla absolutely still has
2025-10-14 06:15:33	Their impact reaches pretty far despite low market share

jonnyawsom3

	juliobbv as in, would more coding tools be added to the format?
2025-10-14 10:04:01	I often think about that part in particular. AV1 has gotten years of tuning, but JXL still has so many coding tools that aren't used, aren't selected, or just aren't efficient currently. It's made to be future proof, but it desperately needs tuning in the present.

JKUser4592

2025-10-14 06:55:41

Are there currently any Android apps that can play animated JXL files on mobile devices?

cioute

	JKUser4592 Are there currently any Android apps that can play animated JXL files on mobile devices?
2025-10-15 10:43:35	https://github.com/oupson/jxlviewer maybe only one

Adrian The Frog

2025-10-15 05:25:58

Isn't animated jxl pretty terrible compared to avif? Lossily at least

username

	Adrian The Frog Isn't animated jxl pretty terrible compared to avif? Lossily at least
2025-10-15 05:29:05	animated AVIFs are just full video streams so yes
2025-10-15 05:30:35	in the future animated JXL encoding could be improved a bit by making use of the different blending modes that JXL supports but that libjxl currently doesn't make use of when encoding

Exorcist

2025-10-15 05:45:43

AVIF is exactly same as normal AV1, allow inter-frame prediction The only different is container

jonnyawsom3

2025-10-15 07:57:51

AVIF is for making 'modern GIFs', JXL is for preserving existing GIFs (essentially)

veluca

2025-10-15 08:36:12

I am not entirely convinced animated jxl wouldn't be competitive on screen content

HCrikki

	Adrian The Frog Isn't animated jxl pretty terrible compared to avif? Lossily at least
2025-10-15 09:13:20	Animated jxl is a real animation, afaik keyframes only in current encoders. It also has true replacement capability, generating smaller files from a gif, without a pixel's difference. Avif fails at that so you have to go to the highest quality original video your gif made generated from and then create your animated avif from that unrelated file
2025-10-15 09:14:49	Imagine generating a bloated OR lossy animated avif from a 256 color gif in any era

AccessViolation_

2025-10-16 09:44:48	I think JXL would be pretty good for recordings of chess games
2025-10-16 09:45:56	you could store all the pieces in a reference frame and move them around using patches

Orum

2025-10-16 09:46:25	or.... just use chess notation
2025-10-16 09:47:07	or if you must be graphical svg

AccessViolation_

2025-10-16 09:47:43	svg is barely supported in places where you'd want a video of a chess game
2025-10-16 09:48:24	also how do you mean just use chess notation? then people would have to enter it in a program or website, which defeats the whole point of having an animated jxl you can just share

Orum

	AccessViolation_ svg is barely supported in places where you'd want a video of a chess game
2025-10-16 09:59:40	Browsers? They support it quite well...
	AccessViolation_ also how do you mean just use chess notation? then people would have to enter it in a program or website, which defeats the whole point of having an animated jxl you can just share
2025-10-16 10:00:11	play it through in your head

Exorcist

2025-10-16 10:29:45

for recording chess, I don't know why need auto & loop play? you need think on every step

AccessViolation_

2025-10-16 11:46:49

I don't know, I just know people often export and share chess games as GIFs

AshRatte

2025-10-16 08:55:22

Hey guys, sorry if that was mentioned before, but, any idea how can I turn a 10sec video into animated jxl?

username

	AshRatte Hey guys, sorry if that was mentioned before, but, any idea how can I turn a 10sec video into animated jxl?
2025-10-16 09:00:56	I think modern versions of FFMpeg can do so? on the other end there is this website if you prefer: https://ezgif.com/video-to-jxl
2025-10-16 09:01:53	just be warned that the file size might be relatively large since currently JXL encoders don't take advantage of blend modes between frames which the JXL format itself supports

jonnyawsom3

2025-10-16 09:03:22

The best way to do it currently is video, to APNG, optimize the APNG, then encode with cjxl. Messy, and still doesn't use blend modes fully, but it works

username

	The best way to do it currently is video, to APNG, optimize the APNG, then encode with cjxl. Messy, and still doesn't use blend modes fully, but it works
2025-10-16 09:04:13	oh huh does the APNG code the libjxl tools transfer over some of the blending modes?

jonnyawsom3

	username oh huh does the APNG code the libjxl tools transfer over some of the blending modes?
2025-10-16 09:04:57	Well it does the standard transparency and cropped frames of GIF, but APNG has full color

RaveSteel

2025-10-16 09:29:12

I can't remember if this has been asked and answered before, but how can I display the reference frame for a JXL if patches were used?

AshRatte

	The best way to do it currently is video, to APNG, optimize the APNG, then encode with cjxl. Messy, and still doesn't use blend modes fully, but it works
2025-10-16 09:36:31	Just converted to APNG, how do I optimize them?

jonnyawsom3

	AshRatte Just converted to APNG, how do I optimize them?
2025-10-16 09:41:42	I think this is the best one. Don't need any fancy settings since it's only an intermediary https://sourceforge.net/projects/apng/files/APNG_Optimizer/

AshRatte

2025-10-16 10:02:19

thx

spider-mario

2025-10-16 10:33:29	yeah, for chess, an SVG file could literally animate the pieces at any desired framerate
2025-10-16 10:33:38	silky smooth 1000fps rendering
2025-10-16 10:35:46	here is a continuous clock I made 14 years ago

monad

	RaveSteel I can't remember if this has been asked and answered before, but how can I display the reference frame for a JXL if patches were used?
2025-10-17 05:32:53	encode with `benchmark_xl --debug_image_dir`

jonnyawsom3

2025-10-17 09:32:13

Does that still work? I thought most libjxl debug output was broken

RaveSteel

	monad encode with `benchmark_xl --debug_image_dir`
2025-10-17 09:44:46	Thank you

Traneptora

	AshRatte Hey guys, sorry if that was mentioned before, but, any idea how can I turn a 10sec video into animated jxl?
2025-10-18 08:37:08	you can do it with ffmpeg
2025-10-18 08:37:33	`ffmpeg -i input.mkv -map v:0 -c:v libjxl_anim output.jxl`
2025-10-18 08:37:36	something like this

Mia

	JKUser4592 Are there currently any Android apps that can play animated JXL files on mobile devices?
2025-10-19 06:00:08	krita can view them too 😅

JKUser4592

2025-10-19 06:00:25

prove it

Mia

2025-10-19 06:05:03	discord for some reason fails to upload an image for me
	JKUser4592 prove it
2025-10-19 06:05:38	https://0x0.st/K160.png
2025-10-19 06:06:17	there is a separate mode for working with animations there

novomesk

2025-10-19 06:06:34

Neochat on Android playing animated AVIF and animated JXL.

Quackdoc

	Traneptora you can do it with ffmpeg
2025-10-19 06:07:35	is this in stable?

Traneptora

	Quackdoc is this in stable?
2025-10-19 07:20:45	ffmpeg doesn't have a stable branch

Quackdoc

	Traneptora ffmpeg doesn't have a stable branch
2025-10-19 07:30:08	I just mean whatever the latest tag is

Traneptora

	Quackdoc I just mean whatever the latest tag is
2025-10-19 09:22:27	I think so

ignaloidas

2025-10-20 11:05:55

Are there any extra resources on how entropy coding works? I've implemented parsing jxl up to everything that doesn't require it to parse the data (so image and frame headers), but what's written in spec is a bit too complicated for me to understand rn (tho maybe it's just me being up for too long lol)

_wb_

2025-10-20 11:45:48

it is quite complicated in general. Have you tried readying the code of an existing decoder?

Tirr

2025-10-20 11:53:34	image header can be read without entropy decoding, but for frame header it depends
2025-10-20 11:56:08	and yeah the spec is not very good for reading, I'd recommend reading the actual code instead

ignaloidas

	Tirr image header can be read without entropy decoding, but for frame header it depends
2025-10-20 01:02:50	Unless I misread something, everything until TOC is readable without entropy coding (ignoring icc, I don't need that data unless I want to make a "good" decoder)

Tirr

2025-10-20 01:04:40

but you cannot skip ICC without actually decoding it, so it depends

_wb_

2025-10-20 01:05:24

yes but you can make an incomplete decoder that just only works for files without ICC, I think that's what he meant

ignaloidas

2025-10-20 01:05:36	And yeah, I guess tomorrow will be time to read other implementations - I briefly tried to look for "simple" implementations but J40 is a pain to read and a Python implentation mentioned in wiki parses even less than mine
	_wb_ yes but you can make an incomplete decoder that just only works for files without ICC, I think that's what he meant
2025-10-20 01:06:21	Yep, exactly - currently I'm more interested in basic data than actual decoding

_wb_

2025-10-20 01:08:02

the entropy decoding is pretty complicated since there's context maps, ANS or Prefix each with their own way of histogram signaling, optional lz77, hybriduint configs, etc.

Lucas Chollet

	ignaloidas And yeah, I guess tomorrow will be time to read other implementations - I briefly tried to look for "simple" implementations but J40 is a pain to read and a Python implentation mentioned in wiki parses even less than mine
2025-10-20 02:28:46	shameless plug to [serenity's decoder](https://github.com/SerenityOS/serenity/blob/master/Userland/Libraries/LibGfx/ImageFormats/JPEGXLLoader.cpp) The entropy decoder is almost isolated in its own file.

_wb_

2025-10-20 03:16:45

how complete is this decoder? it looks like it's quite complete for Modular, but VarDCT still needs to be implemented?

jonnyawsom3

2025-10-20 03:18:48	It was the source of this issue https://github.com/libjxl/libjxl/issues/4482
2025-10-20 03:19:02	After they implemented EPF

_wb_

2025-10-20 03:20:17

in any case, always nice to see another jxl decoder

Exorcist

2025-10-20 03:24:58

update <#822120855449894942> ?

jonnyawsom3

2025-10-20 03:25:44

With what?

Lucas Chollet

	_wb_ how complete is this decoder? it looks like it's quite complete for Modular, but VarDCT still needs to be implemented?
2025-10-20 05:02:28	Yeah exactly, there is no VarDCT support for the moment. And it still misses a lot of features like noise, splines or XYB color transformations

_wb_

2025-10-20 06:05:54

can it already fully decode a typical lossless image? (like what `cjxl -d 0` produces)

Lucas Chollet

2025-10-20 07:09:35

Some of them yes, from the conformance suite (and what I remember off the top of my head) : - grayscale pubic university - lz77 flower - cmyk_layers (with a few local patches) - delta_palette And I think one or two more

Inner Hollow

2025-10-21 02:04:21	Doing a batch conversion of 394 photos from my camera (4608x3456 resolution JPG) to .jxl (q70 e5) (I have slow ass CPU), will share results asap
2025-10-21 02:18:19	Took like ~17 minutes Original 394 files (JPG): 1,535,050,700 bytes After conversion (JXL Q70 E5): 349,025,258 bytes Quality looks good (it's q 70 afterall) The converted files have 22.7% of the total disk size than original JPGs

Orum

2025-10-21 02:19:02

why not do the lossless recompression?

Inner Hollow

2025-10-21 02:19:13	I could try yes
2025-10-21 02:20:17	I just got an SD card reader so I'm trying it out at the same time, I converted files at 1MB/S using on-camera wifi/bluetooth now I can transfer any files hundreds of times faster
2025-10-21 02:20:28	I'll try lossless conversion
2025-10-21 02:20:30	Next
	Orum why not do the lossless recompression?
2025-10-21 02:23:10	Oh my god this is going to take ages, takes like 10 sec for one image at e5 Dual core cpu is melting <:nooooooo:832412073912565771>

jonnyawsom3

	Inner Hollow Oh my god this is going to take ages, takes like 10 sec for one image at e5 Dual core cpu is melting <:nooooooo:832412073912565771>
2025-10-21 02:25:22	What command are you using?

Inner Hollow

	What command are you using?
2025-10-21 02:25:36	Thing is I'm doing it compeltly wrong

Orum

2025-10-21 02:26:07

well anything with a dual core is quite old or very low power

jonnyawsom3

2025-10-21 02:27:19

Even so, my 8 year old phone can do 20MP JPEG transcoding in under a second

Inner Hollow

2025-10-21 02:27:40	I told you, I was doing something wrong
2025-10-21 02:27:46	I'm working on a fix rn
	Even so, my 8 year old phone can do 20MP JPEG transcoding in under a second
2025-10-21 03:01:30	i did it now, much faster now, for Lossless recompression, went from: Original 394 files (JPG): 1,535,050,700 bytes to After conversion (JXL Q100 E5): 1,275,334,077 bytes 83% of the original size. and did it like under 5 minutes because i was doing something a lil wrong

Orum

2025-10-21 03:40:03

anyway better place to discuss this is <#803645746661425173>

qdwang

2025-10-23 10:47:18

Is there a method to compare normal 8bit jpeg vs jpegli encoded one? I tried to use `djpegli` to decode them to 16bit ppm, but it contains dithering so both decoded ppm has 65535 levels of color.

Orum

2025-10-23 10:58:19

what about using `--bitdepth=8`?

qdwang

	Orum what about using `--bitdepth=8`?
2025-10-23 11:05:05	The blog https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html said JPEGLI can encode 10+bits per component, so i'd like to check if it's true. I cannot check this with 8 decode depth.

Orum

2025-10-23 11:05:56

just round off the last 6 bits then?

_wb_

2025-10-23 11:17:38

try a slow gradient in 16-bit, maybe in some wide-gamut space like ProPhoto so it will become more obvious that regular jpeg encoders have banding caused by quantizing to 8-bit yuv

qdwang

2025-10-23 11:35:58

Thank you for the advice. But id like to inspect the data to compare between normal jpeg and jpegli. Why can djpegli output 65535 levels of color for normal 8bit jpeg? Is it because of dithering?

_wb_

2025-10-23 11:59:44	jpegli implements the DCT / iDCT in higher precision, making better use of the internal precision available
2025-10-23 12:01:25	8-bit JPEG internally uses 12-bit DCT coefficients so if you implement it with enough precision, you can actually preserve more than 8-bit data with it. But the usual implementations like libjpeg-turbo are doing several integer quantizations along the way
2025-10-23 12:04:38	roughly speaking: libjpeg-turbo: 8-bit RGB -> 8-bit YCbCr -> approximate fwd DCT -> 12-bit DCT coeffs -> jpeg file -> 12-bit DCT -> approximate inverse DCT -> 8-bit YCbCr -> 8-bit RGB jpegli: 16-bit RGB -> f32 YCbCr -> accurate fwd DCT -> 12-bit DCT coeffs -> jpeg file -> 12-bit DCT -> accurate iDCT -> f32 YCbCr -> f32 RGB -> 16-bit RGB

qdwang

	_wb_ roughly speaking: libjpeg-turbo: 8-bit RGB -> 8-bit YCbCr -> approximate fwd DCT -> 12-bit DCT coeffs -> jpeg file -> 12-bit DCT -> approximate inverse DCT -> 8-bit YCbCr -> 8-bit RGB jpegli: 16-bit RGB -> f32 YCbCr -> accurate fwd DCT -> 12-bit DCT coeffs -> jpeg file -> 12-bit DCT -> accurate iDCT -> f32 YCbCr -> f32 RGB -> 16-bit RGB
2025-10-23 12:43:30	Thank you for the detailed explain.
2025-10-23 12:45:56	So when i call C API from jpegli, should i manually setup `jpeg_compress_struct` like by setting `data_precision` to 12, `dct_method` to FLOAT, `optimize_coding` to 1, etc.

_wb_

2025-10-23 12:57:28

I don't think manual setup is needed, the defaults should be fine

qdwang

2025-10-23 01:30:45

``` if (cinfo->data_precision != kJpegPrecision) { JPEGLI_ERROR("Invalid data precision"); } ``` it seems data_precision has to be 8

_wb_

2025-10-23 01:33:13	yes, that's the only type of jpeg files in the de-facto standard
2025-10-23 01:34:40	12-bit JPEG exists too (this has 16-bit DCT coefficients) but most software doesn't support that, e.g. it won't work in a browser. jpegli uses just the de facto standard, 8-bit JPEGs

lonjil

2025-10-23 02:17:02

Basically, 8 bit JPEG has a lot of wiggle room. If you do a good job, that wiggle room is enough to squeeze out about 10.5 bits of precision in smooth gradients. But they're still 8 bit JPEGs, you just need to do a good job decoding if you want the precision benefit of such a file.

_wb_

2025-10-23 02:27:28

Exactly. I think they added 4 bits of wiggle room to ensure that a DCT roundtrip would not inherently lose too much precision even in worst-case scenarios. Worst cases are things like pure noise, for which all DCT coefficients are important. The key observation is that banding will mostly be an issue in regions where only the DC and a few of the lowest frequency AC coefficients are needed (nonzero). If this is the case, then the actual available precision is higher than in the worst-case. In the most extreme case: a perfect horizontal gradient only requires DC and one AC coefficient, and the precision lost by doing a DCT transform and quantizing the coefficients to 12-bit will be pretty small, there should still be 11 bits of precision left after a roundtrip. In regions with lots of high-frequency detail, the effective precision that can be achieved is lower, but that's OK, there won't be banding artifacts there since the high-frequency stuff will mask the artifacts.

qdwang

2025-10-23 02:29:23	But why general decoders get worse result from jpegli than other normal jpeg encoders. The samples are decoded from rawtherapee with 5 levels of exposure increasing. The jpegli one has more black blocks, i don't know why. The first is encoded from apple encoder in 2.3MB. The second is encoded from cjpegli in 2.6MB. They are both yuv420. The source is a 16bit PNG The cjpegli is compiled from `main` branch.
2025-10-23 02:46:09	mozjpeg is even much worse with 2.4MB
2025-10-23 02:47:21	I don't know how apple optimize their jpeg encoder... I just exported the JPEG in the Preview App
2025-10-23 03:01:39	The libjpeg turbo result likes Apple's result, but still a little worse.
2025-10-23 04:13:37	on the contrary, JXL kills it with 2mb and better than apple's jpeg

A homosapien

But why general decoders get worse result from jpegli than other normal jpeg encoders. The samples are decoded from rawtherapee with 5 levels of exposure increasing. The jpegli one has more black blocks, i don't know why. The first is encoded from apple encoder in 2.3MB. The second is encoded from cjpegli in 2.6MB. They are both yuv420. The source is a 16bit PNG The cjpegli is compiled from `main` branch.

2025-10-23 04:14:09

Unless there is a bug/colorspace issue somewhere I'm not aware of, I think this is because jpegli is perceptually informed. Jpegli inclined to preserve data you can actually see, not the literal darkest shadows in the image. Therefore it gives more bits to brighter areas of the image and less to super dark areas. Maybe Apple's jpeg encoder is tuned for flawed metrics like psnr or ssim, but those image metrics don't really align with human vision very well. I'm not sure what your use case is. I guess the question is, do you really need +5 stops of shadow detail in a jpeg? Wouldn't other formats be better at that?

qdwang

2025-10-23 04:16:23

Thank you for mentioning that jpegli focuses on perceptual quality. That makes sense

jonnyawsom3

	But why general decoders get worse result from jpegli than other normal jpeg encoders. The samples are decoded from rawtherapee with 5 levels of exposure increasing. The jpegli one has more black blocks, i don't know why. The first is encoded from apple encoder in 2.3MB. The second is encoded from cjpegli in 2.6MB. They are both yuv420. The source is a 16bit PNG The cjpegli is compiled from `main` branch.
2025-10-23 04:17:30	Speaking of rawtherapee, this may be of interest to you https://github.com/RawTherapee/RawTherapee/issues/7125#issuecomment-2538513015
2025-10-23 04:18:37	There my results were that jpegli's high bit depth decoding was important, but having both encoding and decoding by jpegli massively improved the usable range

qdwang

	Speaking of rawtherapee, this may be of interest to you https://github.com/RawTherapee/RawTherapee/issues/7125#issuecomment-2538513015
2025-10-23 04:23:20	great post. I just tried to `djpegli` the jpg from jpegli to png, then put the png to rawtherapee, i saw a lot of improvement.
2025-10-23 04:30:55	<@238552565619359744> it seems the key is "Adaptive Quantization"?
2025-10-23 04:30:58	i'll have a try
2025-10-23 04:39:46	it works, disabling AQ can preserve more quality for shadow area

jonnyawsom3

	<@238552565619359744> it seems the key is "Adaptive Quantization"?
2025-10-23 04:41:28	Ah yeah, we found AQ should be disabled above q90

qdwang

	Ah yeah, we found AQ should be disabled above q90
2025-10-23 04:51:03	So does AQ only work for finding visually imperceptible areas and use more quantization on them?

jonnyawsom3

	So does AQ only work for finding visually imperceptible areas and use more quantization on them?
2025-10-23 05:16:09	Yeah, so when you want to adjust exposure/keep fine details, it's better to disable it. We made a PR that does it automatically at high quality, but it needs more testing

qdwang

2025-10-23 06:05:10

BTW, I saw there are two repos for jpegli, 1 is https://github.com/google/jpegli, 2 is https://github.com/libjxl/libjxl/tree/main/lib/jpegli I'm current using the `cjpegli` from 2, it seems to update more frequently

jonnyawsom3

	BTW, I saw there are two repos for jpegli, 1 is https://github.com/google/jpegli, 2 is https://github.com/libjxl/libjxl/tree/main/lib/jpegli I'm current using the `cjpegli` from 2, it seems to update more frequently
2025-10-23 06:33:49	Most updates in 2 are just incidental typos or formatting fixes from other libjxl work. 1 has the actual jpegli updates, but they're all pending PRs. If you can compile yourself, I'd advise merging all PRs in 2 and using that

qdwang

	Most updates in 2 are just incidental typos or formatting fixes from other libjxl work. 1 has the actual jpegli updates, but they're all pending PRs. If you can compile yourself, I'd advise merging all PRs in 2 and using that
2025-10-23 08:23:01	Thank you for the tips.
2025-10-24 11:29:28	One idea: is it possible to embed the jpegli encoded jpg to jxl without file size expansion and enjoy the 10.5bit quality by any jxl decoder?

Orum

2025-10-24 11:33:30

Can't you just encode with jpegli, losslessly transcode to jxl, and get it that way? But that begs the question, why not just use cjxl instead, which will crush anything you can get from cjpegli...

qdwang

	Orum Can't you just encode with jpegli, losslessly transcode to jxl, and get it that way? But that begs the question, why not just use cjxl instead, which will crush anything you can get from cjpegli...
2025-10-24 11:38:58	Yes, it can. But id like to know decoding this kind of jxl can output 8bit quality or 10.5bit?

_wb_

2025-10-24 11:52:41

the libjxl decoding of recompressed jpegs is similar to the jpegli decoding. However, djxl will by default output 8-bit since a recompressed jpeg will be tagged as being 8-bit (also if it was created with jpegli), so you will need to explicitly ask it to produce 16-bit output, or output to something like pfm

qdwang

	_wb_ the libjxl decoding of recompressed jpegs is similar to the jpegli decoding. However, djxl will by default output 8-bit since a recompressed jpeg will be tagged as being 8-bit (also if it was created with jpegli), so you will need to explicitly ask it to produce 16-bit output, or output to something like pfm
2025-10-24 01:07:49	Thank you for the explain which is very helpful.
2025-10-24 04:04:32	So, if there is a way in the jxl file to tell jxl decoder that i need a 16bit output then all decoders can render 10.5bits for this `jxl(jpegli)` format.
2025-10-24 04:05:04	I tried to use `cjxl --override_bitdepth=16` but it doesn't work

jonnyawsom3

	I tried to use `cjxl --override_bitdepth=16` but it doesn't work
2025-10-24 04:17:04	What about with djxl?

_wb_

So, if there is a way in the jxl file to tell jxl decoder that i need a 16bit output then all decoders can render 10.5bits for this `jxl(jpegli)` format.

2025-10-24 05:30:48

The jxl file can be tagged as being 10bit or 12bit or whatever, but current libjxl will not do that when recompressing JPEG. In any case the tagged bit depth is just a suggestion, decoders can always decode to any bit depth, djxl just follows the suggestion by default. Also there should be dithering applied by libjxl when producing 8-bit output so even in 8-bit there should be less banding than with simple jpeg decoders which won't dither.

New Player 🇩🇪

2025-10-24 07:28:43

whats the reason jxl is not used im chromium for example?

jonnyawsom3

2025-10-24 07:35:33

No one knows

HCrikki

2025-10-24 07:50:43

imo a crucial one was no use of origin trials (either for chrome, edge or firefox). in browser dev context, its critical because it *force enables* a flag for specific websites (that can be image hosts or CDNs too)

monad

	New Player 🇩🇪 whats the reason jxl is not used im chromium for example?
2025-10-25 12:00:43	because the bars and lines say avif is better <https://storage.googleapis.com/avif-comparison/index.html>

Demiurge

2025-10-25 01:12:06

Because the avif/webp tech lead was put in charge of the Chrome Codec Team where he has the final say with no accountability or oversight.

qdwang

	monad because the bars and lines say avif is better <https://storage.googleapis.com/avif-comparison/index.html>
2025-10-25 03:22:03	The article didn’t compare the transcoding speed under the same quality(ssim) and size. Or it should compare with the same time, which codec generates better result.

A homosapien

2025-10-25 03:26:53

Yeah that study had multiple flaws, and yet they used it to justify JXL's removal

jonnyawsom3

	The article didn’t compare the transcoding speed under the same quality(ssim) and size. Or it should compare with the same time, which codec generates better result.
2025-10-25 03:33:00	https://cloudinary.com/blog/contemplating-codec-comparisons

Demiurge

2025-10-25 04:38:38	They don't have any obligation to explain or justify anything. It's just the guy who made avif and webp who gets the final say and he decides he doesn't want "someone else's" codec there, and no one else is there to tell him otherwise.
2025-10-25 04:39:55	That comparison is a joke and farce and their own graphs show avif losing. When Jon contacted them to point out problems and give suggestions he never got a response back.
2025-10-25 04:41:56	The comparison was just put there to stall for time
2025-10-25 04:44:50	They mixed in a whole bunch of nonsense numbers into the averages, at blotchy-smudge-quality levels

o7William

2025-10-25 07:01:11	heya, I barely know anything for in-indepth image codec at all but this has always been bugging me
2025-10-25 07:01:36	about why most image format maximum dimensions usually have power of 2
2025-10-25 07:01:40	but with ± 1

veluca

2025-10-25 07:05:31	eh, X bits can represent 2^X values
2025-10-25 07:05:58	and some formats say "you just write the number", so you get sizes from 0 to 2^X-1
2025-10-25 07:06:15	(and if you say 0 I'd guess the image is invalid)
2025-10-25 07:06:25	and some say "0 is dumb, let's do 1 to 2^X"
2025-10-25 07:06:40	I am not aware of anything starting from 2 though, so I'd be surprised by 2^X+1

o7William

2025-10-25 07:07:15	that was HEIC with 2^13 +1
2025-10-25 07:07:47	so it all exist to make 1x1 dimension?

veluca

2025-10-25 08:03:49

mhhh I think the heic limitation is a different limitation coming from some silly "let's be compatible with hw decoders" reason

lonjil

2025-10-25 08:28:10

Meanwhile JXL has a channel limit of 4096 + 3, for fun reasons

spider-mario

2025-10-25 10:49:43	it’s because my birthday is 4 September so we needed a bunch of 4s and 9s
2025-10-25 10:50:02	but 400 more would have been too much

Demiurge

2025-10-26 08:15:46	tl;dr because the numeral system computers use usually have a power of 2 as the biggest numeral.
2025-10-26 08:17:07	Binary numerals use powers of 2
2025-10-26 08:18:07	Same with octal and hecidecimal

lonjil

2025-10-26 09:11:48

That's not the fun reason

monad

	o7William about why most image format maximum dimensions usually have power of 2
2025-10-26 09:25:00	Context for other comments: it's related to the data storage implementation in hardware where the smallest unit of information has two possible states.

afed

2025-10-26 09:26:52

<:Stonks:806137886726553651> https://en.wikipedia.org/wiki/Qubit

_Broken s̸y̴m̴m̵̿e̴͌͆t̸r̵̉̿y̴͆͠

	afed <:Stonks:806137886726553651> https://en.wikipedia.org/wiki/Qubit
2025-10-26 12:44:54	qubit is more like: 1? 0? maybe something in-between? Or how about I feel totally random today.

Quackdoc

2025-10-26 03:22:04

~~this difference is how many images fail to have an ssimu2 score higher then 80 when encoding using d1 e7, gonna try git when all is said and done since this is using stable jxl~~ ```ps ➜ kuroba l *.png.jxl-d1e7.jxl | wc -l 6415 ➜ kuroba l bin/* | wc -l 487 ``` nvm this weird bug

qdwang

	https://cloudinary.com/blog/contemplating-codec-comparisons
2025-10-27 03:21:36	this article uses tune=ssim, but currently more users recommand to use `tune=iq` for avif encoding. I saw an article, he compared AVIF tune=iq vs JXL under 10 bit encoding, the AVIF has a slightly better compression ratio / speed curve.
2025-10-27 03:23:39	https://www.rachelplusplus.me.uk/blog/2025/07/a-better-image-compression-comparison/
2025-10-27 03:24:38	avif tune=iq improves a lot

_wb_

2025-10-27 03:27:28

yes it does, my article is from 3 years ago though and was a reaction on the comparison that was done back then by the avif team

qdwang

2025-10-27 04:12:23

No worries, the tune=iq just came out this year, it uses SSIMULACRA 2 metric as a guide and validating with subjective visual quality checks. I don’t know if SSIMULACRA 2 can help jxl to improve even more?

_wb_

2025-10-27 04:38:37

Possibly, though in general I think optimizing/tuning encoders for a metric is more likely to reveal limitations of the metric than it actually improves the encoder 🙂 But yes, probably there is room for improvement in libjxl's encoder heuristics. Maybe we should somehow make it a bit easier to implement alternative encoder heuristics / tunings to encourage improvement in this area.

monad

2025-10-28 05:04:53

I prefer optimization by the Jyrki metric.

Demiurge

2025-10-28 09:24:39

I have a feeling the age of the libjxl codebase combined with the C++ template hell, will limit how much future improvement will happen in the encoder efficiency front. I wouldn't be surprised if groundbreaking improvements are introduced by a different encoder entirely. Like possibly jxl-rs if they add an encoder to it in the future.

spider-mario

2025-10-28 01:56:16	I think you are overestimating the negative impact of templates on the libjxl codebase
2025-10-28 01:57:15	although SIMD hell may be another story

jonnyawsom3

2025-10-28 02:08:36

I still think this PR should be reverted... At least until it's proven to be equal to the old method, but it's been so long it'd be a pain https://github.com/libjxl/libjxl/pull/2836

Dunda

2025-10-30 08:20:29	Hi, I have a small question about XYB
2025-10-30 08:21:41	I was just recreating the forward transform in blender to visualise the space, and found that the resultant size in the X dimension is quite a lot smaller than YB. Is a small X range an expected behaviour of XYB, or did I make an error reproducing it?
2025-10-30 08:22:37	I have used the transform from an earlier draft paper, and the 2.0 whitepaper so far
2025-10-30 08:24:55	And here are some views of the transformed space
2025-10-30 08:27:52	After scaling X by 10x, it looks a bit more normal

jonnyawsom3

2025-10-30 08:29:46

I'll let the color experts weigh in on this one, but nice idea. Don't think anyone's made an actual 3D model of the colorspace before, only web renders

_wb_

2025-10-30 08:38:03

Yes, the range of X is a lot smaller. For the purposes of ssimulacra2, I multiply it by 14: https://github.com/cloudinary/ssimulacra2/blob/main/src/ssimulacra2.cc#L215

Dunda

2025-10-30 08:44:03	Thank you, that's good to hear. It's cool to see you worked on ssimulacra, it's a very interesting metric
	I'll let the color experts weigh in on this one, but nice idea. Don't think anyone's made an actual 3D model of the colorspace before, only web renders
2025-10-30 09:22:17	Thanks, here is a turnaround animation and the blend file
2025-10-30 09:26:16	Hm, that came out with really crappy quality and doesnt even load in Discord

jonnyawsom3

2025-10-30 09:33:45

Huh, it plays on my phone, but does look like a render from the 90s with how quantized it is haha. Probably just Blender's default output settings

Dunda

2025-10-30 09:33:48	Okay it was because divx is apparently terrible
2025-10-30 09:34:16	I picked a bad codec when I switched the container
2025-10-30 09:37:08
2025-10-30 09:38:27	Also, this model is rotated about X such that Y (luma) faces up

jonnyawsom3

2025-10-30 09:43:13

That peak for the Yellow is the bane of my existence currently xD The B keeps pushing over into the White instead

Dunda

2025-10-30 11:33:33	Oklab and XYB (XYB has been rotated and scaled)
2025-10-30 11:34:16	They both convert to an LMS space and use a cube power transfer, so it's interesting to see how different they look
2025-10-30 11:35:12	Although XYB has a bias, while oklab does not
2025-10-30 11:38:50	XYB also has some nice behaviour towards black, while sRGB in OkLab is very sparse for dark colours

jonnyawsom3

2025-10-30 11:44:40

Could be good to post in <#1288790874016190505> too

Dunda

2025-10-30 11:46:18

You're right, I'll crosspost there

Jyrki Alakuijala

	Dunda I was just recreating the forward transform in blender to visualise the space, and found that the resultant size in the X dimension is quite a lot smaller than YB. Is a small X range an expected behaviour of XYB, or did I make an error reproducing it?
2025-10-31 08:06:03	Probably not. X is small.

AccessViolation_

2025-10-31 09:25:33

X formerly known as ~~twitter~~ red-green

Orum

2025-11-02 06:00:57	why does cjxl photon noise ISO of 1600 roughly correspond to images I've taken at 100 ISO and then denoised somewhat?
2025-11-02 06:01:09	seems like the scale is just way off
2025-11-02 06:05:48	I've also noticed that cjpegli likes to turn dark orange/reds into dark greens 😮‍💨
2025-11-02 06:07:13	even at `-d 1` it's trivial to see the difference; it's especially sad that a 596KB jpg can't come close to looking as good as a 76 KB avif

Demiurge

2025-11-02 07:29:52	If you have a really good example of this happening, I would love to see it. And I'm sure the devs would like this also.
2025-11-02 07:30:44	Color errors like that
2025-11-02 07:31:10	If it's present in cjpegli it's probably present in cjxl too
2025-11-02 07:32:29	They have similar problems especially with shadows and color. They have a lot of shared code.

spider-mario

	Orum why does cjxl photon noise ISO of 1600 roughly correspond to images I've taken at 100 ISO and then denoised somewhat?
2025-11-02 08:06:19	at which resolution? the scale assumes the input file corresponds to the whole sensor

jonnyawsom3

	Orum why does cjxl photon noise ISO of 1600 roughly correspond to images I've taken at 100 ISO and then denoised somewhat?
2025-11-02 09:37:13	What camera did you use? Photon noise in libjxl is currently assuming a 35mm sensor <https://github.com/libjxl/libjxl/blob/445e90984346b632ab3d039e1a3f790b5ade5b0f/lib/jxl/enc_photon_noise.cc#L33>

Orum

	spider-mario at which resolution? the scale assumes the input file corresponds to the whole sensor
2025-11-02 03:09:12	the image is uncropped and unscaled, so that should be accurate
	What camera did you use? Photon noise in libjxl is currently assuming a 35mm sensor <https://github.com/libjxl/libjxl/blob/445e90984346b632ab3d039e1a3f790b5ade5b0f/lib/jxl/enc_photon_noise.cc#L33>
2025-11-02 03:09:31	ah, mine is APS-C so I guess that could cause it
	Demiurge If you have a really good example of this happening, I would love to see it. And I'm sure the devs would like this also.
2025-11-02 03:10:04	hold on, making a crop of the area that has the problems...
2025-11-02 03:15:27	source image:
2025-11-02 03:15:43	d1 from cjpegli (make sure you download instead of looking at the preview in discord):
2025-11-02 03:16:13	the reds have turned to a gray or possibly mild green

jonnyawsom3

2025-11-02 03:25:33

The problem is YCbCr, it doesn't have enough precision in those dark shades. Using our PRs that enable RGB compression at q100, the green goes away Will have to compare these locally since they're such high quality, but hopefully you see what I mean

Orum

2025-11-02 03:25:50

it's not YCbCr, because my YCbCr AVIFs look fine

jonnyawsom3

2025-11-02 03:27:00

Doesn't AVIF use SharpYUV?

Orum

2025-11-02 03:27:39	I'm just manually converting them to YCbCr before I hand them to the encoder
2025-11-02 03:28:27	I am using higher bit depth though, so maybe that is saving it <:SadOrange:806131742636507177>

Exorcist

2025-11-02 03:30:02

Both AOM and SVT receive YUV (they won't convert by themselves) You need convert by external library

jonnyawsom3

2025-11-02 03:30:02

> The problem is YCbCr, it doesn't have enough precision in those dark shades Using higher precision would help with that, yeah xP Could still be something else, but if those two files I sent are green and not-green, the only difference is the right using RGB instead of YCbCr

Orum

2025-11-02 03:33:03	let me try an 8-bit AVIF
2025-11-02 03:36:35	8- bit AVIF, still not nearly as bad as cjpegli
2025-11-02 03:37:59	the color transitions in the AVIF where it is problematic are more abrupt though
2025-11-02 03:56:11	lossy webp is also 8-bit YCbCr, and it looks better in terms of color accuracy (though still has its problems, too):

A homosapien

	Orum lossy webp is also 8-bit YCbCr, and it looks better in terms of color accuracy (though still has its problems, too):
2025-11-02 05:50:33	It's really weird that WebP has better color accuracy than jpegli. Jpegli uses higher precision math to avoid this issue... Is there something wrong with the color management pipeline?

Demiurge

2025-11-02 08:06:17	For some reason it just looks black on my iphone
2025-11-02 08:07:26	Does it not happen with xyb?

_wb_

2025-11-03 09:11:22

all the images above just look black to me

jonnyawsom3

2025-11-03 09:14:50

On my OLED phone it's just black, until I set the brightness to full

lonjil

2025-11-03 09:24:37

on my 500 year old SDR screen, the issue is quite visible

_wb_

2025-11-03 09:26:58

on my macbook I can't see anything other than just black even with max brightness. maybe I need to adjust my display settings. the pixels are not actually black but I cannot see anything but black.

AccessViolation_

2025-11-03 09:30:47	try zooming in and slowly panning the image
2025-11-03 09:31:15	there's a gradient, the bottom and left side are a bit brighter than the top and right side

_wb_

2025-11-03 09:35:37

ok if I set my display to SDR mode at 500 nits and with a pure gamma 2.4 instead of the sRGB transfer function, I can see the blocks in the jpegli image and it's clear that it is overall darker than the original. In the default settings I was using before, I couldn't really see any structure in the original nor any artifacts in the jpegli image.

jonnyawsom3

2025-11-03 10:26:33

Oh the joys of color management and display technology (Also remember the previews in Discord are very low quality WebP)

spider-mario

2025-11-03 12:23:01

odd, I would have expected gamma 2.4 to make the issue less visible, not more

AccessViolation_

2025-11-03 12:54:51

worth noting that discord on desktop/web does show the original media when you zoom in. in-chat preview: webp. full image preview: higher quality webp. zoomed full image preview (by clicking): original file.

jonnyawsom3

2025-11-03 12:57:57

Huh, the AVIF uses lossless WebP for the thumbnail `https://media.discordapp.net/attachments/794206170445119489/1434566873575329882/problem_area.avif?ex=690974c3&is=69082343&hm=f3728e3732c9d6754a0d72b133d682694bd9dcd72e9afa2bbb96b82bc072fffb&=&format=webp&quality=lossless&width=350&height=350` Otherwise it's 350x350, 850x850 and then full res

AccessViolation_

2025-11-03 01:01:32

oh yeah, weird. especially because the preview is unsurprisingly larger than the original that's loaded when you zoom in

jonnyawsom3

2025-11-03 01:03:56

PNG gets lossless too `https://media.discordapp.net/attachments/803645746661425173/1432320289680658453/image.png?ex=6909da38&is=690888b8&hm=73a589754b48379d25bb09d95190d1566b3577848c4fca3e8e505350c6adb7c4&=&format=webp&quality=lossless&width=1108&height=600` Probably because they're assuming WebP and JPEG are already low quality, so they need even lower quality for previews to make sense, while PNG is assumed lossless and AVIF assumed higher quality?

2025-11-03 01:04:16

It's been a thing for years and always annoyed me, but I doubt they'd change it

AccessViolation_

2025-11-03 01:04:29	the png preview is not lossless for me
2025-11-03 01:04:38	not for the thing I just posted at least
2025-11-03 01:05:03	oh wait no it is, my bad
2025-11-03 01:06:06	what would make the most sense to me is if they made pngs lossless webms because converting things like screenshots from lossless to lossy can inflate the file size, defeating the point of a lower quality preview
2025-11-03 01:06:16	but that doesn't explain why the avif got the lossless preview as well
2025-11-03 01:19:29	> To ensure maximum compatibility, we convert AVIF content to WebP while maintaining the highest possible visual quality <https://discord.com/blog/modern-image-formats-at-discord-supporting-webp-and-avif>
2025-11-03 01:27:37	oh that reminds me, <@1156997134445461574> any updates on discord allowing ingress of jxl sources? 👀 I remember you saying it would be considered later this year

_wb_

	spider-mario odd, I would have expected gamma 2.4 to make the issue less visible, not more
2025-11-03 01:36:22	Indeed. But it could be that this Apple dialog box is talking about EOTF instead of OETF or the other way around, I always get confused

Jyrki Alakuijala

	Orum why does cjxl photon noise ISO of 1600 roughly correspond to images I've taken at 100 ISO and then denoised somewhat?
2025-11-03 02:23:28	File an issue. Could also relate to the shutter time and lens power...

Orum

2025-11-03 02:42:03

well if it assumes a 35mm sensor then that could make sense

spider-mario

2025-11-03 03:24:06	the difference with APS-C is not _that_ much; you’d have to multiply the APS-C ISO values by about 2.56 (Canon) or 2.25 (others)
2025-11-03 03:24:38	also, I think my correction to align it with the intended amount of noise was going to make it less noisy still
2025-11-03 03:26:02	just to confirm, do you shoot at the nominal exposure for ISO 100, or do you ETTR (“expose to the right” (right of the histogram)) and then pull the tones down?

Info

JPEG XL

General chat

Voice Channels

Archived

jxl

Anything JPEG XL related