|
Demiurge
|
2025-03-18 03:36:09
|
At least it's only the frame start, and not something even more crucial. Like image size or something. |
|
|
Traneptora
|
2025-03-18 03:44:51
|
yea the super tiny header is useful for many super tiny images |
|
2025-03-18 03:45:12
|
but in those cases the TLS handshake and the HTTP roundtrip is more important than the size of the image |
|
|
AccessViolation_
|
2025-03-18 03:50:59
|
that's true |
|
2025-03-18 03:51:14
|
that's why I'm a big QUIC proponent as well |
|
|
_wb_
|
2025-03-18 07:28:20
|
Images can be data-uri inlined in a page, and requests can be multiplexed etc... |
|
|
CrushedAsian255
|
2025-03-19 09:37:52
|
<:JXL:805850130203934781> |
|
2025-03-19 09:39:11
|
For this small of an image you can probably afford `-e 10` in which i get a 1775 byte JXL file for that emoji |
|
|
|
AccessViolation_
|
2025-03-19 09:44:46
|
it's probably still more efficient to put them all in a sprite sheet and make browsers selectively render parts of them (which I think HTML/CSS can do natively?), but it's only economical if you know you're going to be using most of them |
|
2025-03-19 09:49:03
|
for example Discord could just make you download the sprite sheet that contains all of a server's custom emoji at react size, and then at message size. Twitch could have a sprite sheet for global emotes and make you download the channel-specific emotes for the specific channel you're watching, and still use a request per emote for any emotes from external channels that are posted in the stream from someone else |
|
2025-03-19 09:50:26
|
but loading them individually when needed gets more efficient if you serve many different sizes of the same image in many different places, because all size options would require their own sprite sheet |
|
|
jonnyawsom3
|
2025-03-19 11:37:08
|
I'd try lossless with --keep_invisible 0 |
|
|
|
CrushedAsian255
|
2025-03-19 11:41:25
|
still 1775 bytes |
|
|
|
_wb_
|
2025-03-19 07:56:09
|
.svg.br is the way to go for such images |
|
2025-03-19 07:56:28
|
Don't rasterize vectors unless you have to |
|
|
couleur
|
2025-03-19 08:35:22
|
whats .br |
|
|
TheBigBadBoy - 𝙸𝚛
|
2025-03-19 08:35:39
|
brotli |
|
2025-03-19 08:36:04
|
`-e 11` ftw |
|
2025-03-19 08:36:28
|
yeah but JXL's splines [⠀](https://cdn.discordapp.com/emojis/1059276598660059136.webp?size=48&name=av1_trollhq) |
|
|
|
AccessViolation_
|
2025-03-19 08:37:58
|
for brotli they really took the "compact header" idea to the next level didn't they <:tfw:843857104439607327> |
|
2025-03-19 08:39:00
|
who needs magic signatures |
|
|
|
_wb_
|
2025-03-19 09:01:29
|
Aren't all compressed streams like that? IIRC, a raw deflate stream is also headerless |
|
|
|
AccessViolation_
|
2025-03-19 09:22:00
|
hmm maybe, but the problem is that you if you just brotli compress a file you end up with a nondistinct blob that software can't automatically check the format of. whereas zstd for example includes a magic number |
|
2025-03-19 09:22:56
|
i'm only now realizing that this isn't an issue at all if you use a container format compatible with brotli |
|
|
|
_wb_
|
2025-03-19 10:23:23
|
It's like gzip vs raw deflate. Both have their uses. |
|
|
|
5peak
|
2025-03-25 04:14:08
|
This is different problem domain. Speed of light is the limit. |
|
|
|
Demiurge
|
2025-04-10 03:24:17
|
So there was some talk earlier about good images to use for visual comparison demos versus other codecs to showcase the strengths of JXL. I think I found some really impressive samples where jxl utterly dominates. |
|
2025-04-10 03:26:14
|
And it would be cool to show these actual real life examples on the fan website. Photos where other codecs don't even come close and libjxl seems decades ahead. |
|
2025-04-10 03:34:25
|
https://afontenot.github.io/image-formats-comparison
I was looking at this comparison again recently, and it has some examples where libjxl is unbelievably superior compared to others, as well as a few examples of libjxl doing poorly, but overall libjxl tends to outperform other codecs if you overlook 3 main weaknesses with libjxl. In order of how noticeable the flaws are, they are: Reduced color saturation across a wide range of images, excessive punishment of darker shaded image regions, and excessive ringing and colorful specks at lower bitrates |
|
2025-04-10 03:36:39
|
One of the best examples of supreme libjxl domination over competitors is the "Sunset" image. |
|
2025-04-10 03:37:55
|
There are many images where entire details and textures completely disappear in avif and only libjxl preserves them! This would be great on the fan site! |
|
2025-04-10 03:41:38
|
Take a look at "Sunset," "Seikima," and "White Dune" for some good examples of libjxl domination. |
|
2025-04-10 03:45:55
|
Also the water and trees in "Reykjavik." Or the red details on the merry-go-round or the texture on the black fish and foliage texture in "Kopenhagen." |
|
2025-04-10 04:21:47
|
"Mercado" also is a very dramatic difference on that page. With the tiles, and stone surfaces, completely smoothed away by avif but not by libjxl |
|
2025-04-10 04:22:24
|
I can also list some examples where libjxl does particularly poorly and highlights the 3 flaws I mentioned. |
|
2025-04-10 04:22:32
|
If anyone's interested |
|
2025-04-10 04:22:58
|
Either way someone should put these demos on the fan site for sure, in my opinion |
|
2025-04-10 04:23:47
|
I would credit the source too, "afontenot" |
|
|
gb82
|
2025-04-11 05:21:59
|
Looks like they aren’t using tune iq for avif, that’s a big disadvantage to avif |
|
|
|
Demiurge
|
2025-04-11 05:24:23
|
Is that a recently added thing? |
|
|
|
gb82
|
2025-04-11 05:54:39
|
Yeah pretty recent |
|
|
|
Demiurge
|
2025-04-11 11:56:04
|
Part of psy tuning fork merge? |
|
2025-04-11 11:59:19
|
Really hope those folks patch libjxl next 😂 |
|
2025-04-12 12:00:32
|
libjxl is already really impressive for a DCT codec but it's got some stiff competition from libaom, sometimes it even looks like av1 is using splines |
|
|
|
gb82
|
2025-04-13 03:43:48
|
yeah, we created Tune 4 in SVT-AV1-PSY for still image performance & it did well, but it had some inherent limitations (like 4:2:0-only) so its being ported to libaom |
|
2025-04-13 03:44:10
|
actually a lot of our inspiration came from libjxl, and some from x264 |
|
|
|
Demiurge
|
2025-04-13 03:57:25
|
Damn, it's too bad libaom is benefitting from libjxl innovations instead of the other way around 😂 |
|
2025-04-13 03:58:33
|
I'm pretty mad at the tech lead of libaom for his childish removal of libjxl from chromium |
|
2025-04-13 04:00:01
|
I honestly want libaom to fail after that, since the entire planet is being set back on image compression for the sake of his petty ego |
|
2025-04-13 04:00:21
|
So equally petty I want libaom to utterly fail |
|
2025-04-13 04:00:42
|
And libjxl to succeed ♥️ |
|
2025-04-13 04:30:58
|
I know libjxl is an utterly nightmarish pile of old coagulated spaghetti code but I really hope someone shows it some love, dikes out some of the old cruft and complexity, and gives it some tuning love. If I have time I might even do it one of these days since no one else seems to -_- |
|
2025-04-13 04:33:10
|
The devs seem afraid to make major overhauls/changes/refactors because alleged, unfounded fear of messing things up |
|
2025-04-13 04:33:19
|
libjxl-tiny is the only other encoder afaik |
|
2025-04-13 04:34:44
|
Is there anything x264 does that libjxl could copy? |
|
|
|
gb82
|
2025-04-13 05:26:50
|
im not really sure, I don't think there's as much overlap compared to SVT-AV1 or libaom because they're video encoders first and foremost |
|
|
|
Demiurge
|
2025-04-13 06:29:14
|
Well x264 does have tune=stillimage or something and an intra-only mode without any motion vectors. |
|
|
|
jonnyawsom3
|
2025-04-13 08:05:29
|
hydrium does ultra-low memory lossy encoding |
|
2025-04-13 08:07:07
|
libjxl is an unwieldy beast, but exposing so many paramters has come in useful. Everything in <#1358733203619319858> has just been changes to if statements and variables, enabling and disabling existing features under different conditions |
|
|
|
Demiurge
|
2025-04-13 08:07:11
|
I forgot about that one. That's pretty cool... and it's pretty simple to tune the parameters for these extra-simplified lossy encoders too, so they can benefit a lot from visual testing and tuning |
|
|
|
jonnyawsom3
|
2025-04-13 08:10:40
|
I also cooked up a new group size heuristic. Currently it's 256 x 256 unless the image is <= 400 tall and wide, or it's effort 11. Mine will try and use the largest group size that maximizes thread utilization. Roughly speaking, an 8 core 16 thread CPU will use g1 (256 x 256) for 1080p, g2 (512 x 512) for 4K and g3 (1024 x 1024) for 8K.
Need to do a bit more testing on it's impact though, may limit g3 to effort 9+ due to the memory increase |
|
|
|
Demiurge
|
2025-04-13 08:14:40
|
I think it's better if the criteria is based on the image rather than the particular environment it's being run on |
|
2025-04-13 08:17:31
|
I think there's too many effort levels too... certain features would be better as their own separate experimental option rather than adding yet another gradation to the effort knob |
|
2025-04-13 08:18:47
|
Unless/until those features become solid enough to enable by default in a certain effort setting. The current state of the effort setting are pretty poor tradeoffs. |
|
|
|
jonnyawsom3
|
2025-04-13 08:19:02
|
If you mean using the block size that gives the best density, the only option is brute forcing all of them currently, which is what effort 11 does. It would check that the image is at least as big on both axis as the chosen block size, to avoid cases like a 1 pixel long strip using 99% empty 1024 x 1024 groups, instead using 128x128 |
|
|
|
Demiurge
|
2025-04-13 08:19:58
|
No, it can be a heuristic like the same as your proposed algorithm except not dependent on the host environment (always assume X hypothetical threads for example) |
|
|
|
jonnyawsom3
|
2025-04-13 08:20:55
|
Heuristic... How? See if it has lots of HF data and use smaller blocks for more locality, with big blocks for smooth images? |
|
2025-04-13 08:22:26
|
Wait, this is the website channel... |
|
|
|
Demiurge
|
2025-04-13 08:22:33
|
Like I said, it could be the same as what you are proposing, but instead of being dependent on the host environment, it can use static values |
|
2025-04-13 08:23:12
|
I just personally would prefer the compression parameters weren't affected by the host system |
|
2025-04-13 08:23:24
|
Unless explicitly asked |
|
|
|
jonnyawsom3
|
2025-04-13 08:23:28
|
Continuing in https://discord.com/channels/794206087879852103/804324493420920833/1360893182203789332 |
|
2025-04-20 10:21:30
|
Maybe we shouldn't have *all* our email addresses publicly listed... <@594623456415449088> <https://jpegxl.info/about/contributors.html> |
|
|
monad
|
2025-04-20 06:59:31
|
an ironic criticism given they were published publicly by each individual to an enduring and widely disseminated git repo |
|
|
|
jonnyawsom3
|
2025-04-20 07:01:29
|
The git repo is less likely to be found by random members of the public, including mischievous kids, than the front facing page for the format |
|
|
KKT
|
2025-04-21 03:29:46
|
Yeah, we had a debate about it back in the day and decided to go ahead since they were already public… Maybe they should be links to their github pages or LinkedIn? |
|
|
|
jonnyawsom3
|
2025-04-21 08:28:50
|
Could link to their contributions to libjxl (or eventually jxl-rs) |
|
|
Jyrki Alakuijala
|
2025-05-13 12:38:12
|
Clouds are not easy for usual compressors, I paid quite a bit of attention to get natural looking clouds in JPEG XL. I like how the sky looks, and I like clouds particularly 😄 |
|
|
|
Demiurge
|
2025-05-13 12:39:08
|
Not just the clouds but also the foliage |
|
|
Fab
|
2025-05-13 01:45:04
|
How is the yt encoder of today at encoding the clouds at 1080p resolution and av1? |
|
|
Tirr
|
2025-06-02 05:51:54
|
Duplicate Image Finders section of <https://jpegxl.info/resources/supported-software.html>: I think [czkawka](https://github.com/qarmin/czkawka) also supports jxl, via jxl-oxide |
|
|
Quackdoc
|
2025-06-02 08:33:52
|
correct. I use krokiet, the slint frontend for czkawka a lot :D |
|
|
|
jonnyawsom3
|
2025-06-11 12:52:26
|
It'd be nice to do some minor Cleanup of the site that never got done months ago.
Fixing the bad compression of the background image, making the effort vs quality sliders more coarse to reduce the amount of files needed |
|
|
|
KKT
|
2025-06-11 03:58:23
|
At this point I'm probably just going to rebuild it in Webstudio and use Decap as the CMS. Just need to find a bit more time.
For the background image, I used the largest size available on the download. It's the full width, so the JPEG artifacts are baked in. I guess I could try an AI upscale it or something. As well, I thought it was only really noticeable when we had that bug that scaled it to like 2000% on some Linux browsers.
I don't think it's worth it on the effort vs quality side. It was suggested we use jxl-oxide to do the compression and decompression. Not sure how performant that will be, but I guess we can try. |
|
|
|
jonnyawsom3
|
2025-06-11 05:13:32
|
Well jxl-oxide is a decoder only, you'd need to lobotomize Squoosh for a WASM encoder.
I think effort vs quality still has a place, but significantly cut it down. Generally the people moving at distance 0.1 increments are the kind to do testing locally, we just need a general showcase of Distance 0-5, maybe 0.25 increments and use the oxide WASM decoder so we don't need to store hundreds of extra images for fallback |
|
|
|
KKT
|
2025-06-11 07:07:58
|
As a photographer I find it interesting to look at those kind of increments. We can certainly cut down the high distances. Does it hurt to have more? Performance seems fine |
|
|
|
jonnyawsom3
|
2025-06-11 07:23:45
|
.... |
|
2025-06-11 07:26:24
|
It makes it an absolute nightmare to edit and maintain, when 90% of visitors don't even use the page, yet alone test all 100 distance notches at all 10 effort levels per image |
|
2025-06-11 07:27:50
|
Personally I go for distance 0.3 when using lossy, so I too would like fine grained control, but when the images are only a few hundred pixels wide anyway, you can't see the difference between distance 0 and distance 0.5 yet alone distance 0 and 0.1 |
|
2025-06-11 07:31:41
|
Maybe a dynamic distance slider? 0.1 increments up to distance 1, 0.25 up to distance 2, 0.5 up to distance 5, and 1 up to distance 15 |
|
2025-06-11 07:35:02
|
That cuts it down to 300 images from 1,500. Then add the WASM decoder and the repo is 20x smaller, far smaller in filesize too since we don't need lossless fallbacks |
|
|
|
KKT
|
2025-06-12 12:44:18
|
Background image has been updated and recompressed. Best I could do with that image. Scaled up using AI, scaled down, then converted to greyscale PNG, the convert to JXL & webp. Maybe looks slghtly better? Otherwise we'll have to find a replacement. |
|
|
|
jonnyawsom3
|
2025-06-12 01:10:16
|
Since it's meant to be a showcase of the format... v0.8 up to distance 9.9, then main for distance 10-15 should give the best visual results... Effort 9 and 10 are identical for images under 2048*2048 too |
|
2025-06-12 08:27:20
|
Actually ignore that, v0.8 is still better all round, you'll just want to manually enable resampling at distance 10+ to match the behaviour of main |
|
|
|
monad
|
2025-06-12 09:31:58
|
No, old versions shouldn't be used in general and impressions shouldn't be artificially manipulated. It's bad enough people still propagate the generation loss resistance claim based solely on Jon's old videos without any practical substantiation in years. |
|
|
A homosapien
|
2025-06-12 10:00:50
|
I agree with monad, using the latest version is what most people would normally use anyways. Also, there is generation loss resistance but only for distances ≤0.5. |
|
|
|
jonnyawsom3
|
2025-06-12 12:10:50
|
I also agree with monad, we shouldn't need to use old versions, but here we are |
|
2025-06-12 12:11:24
|
You could say the same about JXL art, the tiny sizes aren't representative of normal encoding, but we still show them off and boast |
|
|
HCrikki
|
2025-06-12 12:28:36
|
decode speed is super important too. for some one given image, itd be helpful to demonstrate that it has no direct relation to *filesize* and depending on the encoding parameters, efforts, flags (decoding not so much since i assume images are almost always decoded at the highest precision possible), an image can be made to load instantly even on old weak hardware |
|
2025-06-12 12:30:44
|
could help influence the scripters and integrators away from insanely ressource-hungry settings, efforts and implementations that damage jxl's reputation |
|
2025-06-12 12:33:08
|
like, ok you inconstently save 10 kilobytes for the average 10 megapixel image but was it worth making images take 10x more cycles and time to decode now that the cost of energy for server and cloud compute has drastically increased ?
consider comics and danbooru-like galleries, some scripts cause ludicrously huge increases in computing cost, encode durations and decode speeds, to the point site ops prefer nopeing off to avif or stick to jpg for another decade
anything above effort 8 shouldve been locked down as developper-only not meant to be used except for intentionally specific purposes or allowed only for images smaller than 2 megapixels if system isnt known to benchmark very high for jxl encoding and decoding (flawed as it is, see phoronix test suite results for an idea) |
|
|
|
jonnyawsom3
|
2025-06-12 12:40:26
|
When the next version releases, we can definitely rerun the numbers and get some solid results for decode speed, progressive loading, ect |
|
|
|
monad
|
2025-06-12 05:19:26
|
Latest releases incorporate improvements regardless of coding efficiency observations. They are most accessible as integrations update. JXL art as a process could be misunderstood, but that's separate to my argument. |
|
|
diskorduser
|
2025-07-19 07:07:38
|
this look weird. hits counter |
|
|
|
_wb_
|
2025-07-19 07:54:13
|
Does that happen at a specific viewport width? On my phone it looks normal |
|
|
|
diskorduser
|
2025-07-19 08:05:41
|
I used waterfox on desktop. 1920x1080 on windows 11. |
|
2025-07-19 08:07:27
|
may be the problem with firefox based browsers? it looks like that in android waterfox but on chrome it looks ok. |
|
2025-07-19 08:08:57
|
|
|
|
|
KKT
|
2025-07-19 07:24:52
|
I'll fix |
|
2025-07-19 07:29:08
|
Done |
|
|
|
jonnyawsom3
|
2025-10-18 07:29:19
|
A very minor nit pick, but in light of [this](<https://redd.it/1oa4ip9>) Reddit post, maybe we should use underscores instead of dashes for spaces, to avoid `JPEG-XL` confusion xD
<https://jpegxl.info/resources/jpeg-xl-test-page.html> |
|
|
|
KKT
|
2025-10-18 11:36:04
|
Hmm, I usually use hyphens for SEO best practices, but it probably doesn't matter much. I wonder if we should just create a JPEG XL branding guidelines page? |
|
|
|
monad
|
2025-10-19 02:50:38
|
Actually, the dash is correct on Reddit. |
|
|
|
KKT
|
2025-11-11 04:07:46
|
I added Shutter Encoder and updated the Affinity logo/link on the software page. |
|
2025-11-23 06:00:20
|
I've updated the website with a bunch of the new articles (JPEG XL in hardware, PDF support, Chrome support). Let me know if there are other good ones… |
|
2025-11-23 07:12:24
|
Hey, I'm trying to update the HDR image on the website (remove the video for Safari now that HDR images are supported). I couldn't find my original source file, so I recreated it (in Affinity, like before). I'm exporting as an EXR and it looks exactly like the source. I export as PNG and it's much more saturated but significantly less bright. I'm converting to AVIF and JXL. Both are coming out dark. I guess I could use them this way, but I thought they looked better brighter. Any idease? |
|
2025-11-23 07:17:29
|
AVIF:
`avifenc -q 90 -s 0 -r f -d 10 -y 444 --nclx 9/16/9`
JXL:
`cjxl -d 1.5 -e 7` |
|
2025-11-23 07:18:48
|
|
|
2025-11-23 07:19:34
|
I created the JXL from both the EXR & PNG and they both end up looking exactly the same. |
|
2025-11-23 07:28:27
|
I guess now that Affinity is free, you can take a run at the original too: |
|
2025-11-23 07:28:35
|
Had to split in two to upload. |
|
|
spider-mario
|
2025-11-23 07:31:22
|
maybe using `exr_to_pq` from libjxl? |
|
2025-11-23 07:45:40
|
ah, it seems it doesn’t behave well with alpha, I should fix that |
|
2025-11-23 07:57:13
|
is this how it’s supposed to look? |
|
2025-11-23 07:57:58
|
ah, one second, forgot the `--intensity_target=829` |
|
2025-11-23 07:58:10
|
there |
|
|
|
jonnyawsom3
|
2025-11-23 08:28:54
|
I thought we were trying to avoid using AI generated content on the site? |
|
|
|
AccessViolation_
|
2025-11-23 08:35:15
|
there are so many nice freely usable images out there
https://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year |
|
|
|
KKT
|
2025-11-23 09:04:25
|
I chose that one so I could crank the HDR-ness without messing with the actual intent of the image. |
|
2025-11-23 09:05:43
|
And those are great images, but I don't see any HDR ones in there. |
|
2025-11-23 09:15:53
|
Thanks! That looks good. Can we get it closer to the 180KB from the 1.8MB for the web? Anything I can do to make the AVIF look closer? |
|
|
|
spider-mario
|
2025-11-23 09:23:55
|
that was lossless, so we could in principle recompress this lossily for JXL, and decompress to PNG / recompress with `avifenc --ignore-icc --cicp 9/16/9` for AVIF |
|
|
|
KKT
|
2025-11-23 09:30:10
|
I was using the PNG to create the AVIF but it was dark too. What were the flags for the JXL? |
|
|
|
spider-mario
|
2025-11-23 10:00:35
|
mainly, I used `tools/exr_to_pq --luminance white=203 original.exr pq.ppm`, which said “The resulting image should be compressed with `--intensity_target=828.486`.”, so then I ran `tools/cjxl -d 0 -x color_space=RGB_D65_202_Rel_PeQ --intensity_target=829 pq.ppm image.jxl` |
|
2025-11-23 10:00:58
|
because that image is now in PQ, decompressing that jxl to png and then encoding that png to avif should not be dark anymore |
|
2025-11-23 10:01:30
|
(I really mainly used JXL as an alternative to PNG here, to convey the result of the PQ conversion) |
|
|
|
KKT
|
2025-11-24 01:12:23
|
Mmm. `avifenc -q 90 -s 0 -r f -d 10 -y 444 --nclx 9/16/9` from the PNG is giving me this: |
|
2025-11-24 01:12:30
|
Looks non-HDR |
|
2025-11-24 01:12:49
|
In case Discord is messing around with it |
|
|
juliobbv
|
2025-11-24 02:33:34
|
discord tonemaps preview images down to SDR |
|
2025-11-24 02:33:50
|
but if I open the original AVIF I can see it's HDR |
|
|
|
KKT
|
2025-11-24 02:43:59
|
It's not nearly the same as the JXL though. |
|
2025-11-24 03:43:41
|
OK, I updated the site. Looks good on the Mac in Safari and Chrome. Not so much on Firefox. Can some others test it out on Windows & Linux? |
|
2025-11-24 03:44:55
|
I have an non-HDR windows machine and you can tell the difference between the HDR & SDR but it doesn't look great. |
|
|
|
monad
|
2025-11-24 04:00:29
|
my linux sys |
|
|
|
KKT
|
2025-11-24 04:02:05
|
Would an HDR JPEG work better as a fallback? |
|
|
|
spider-mario
|
2025-11-24 07:58:05
|
maybe it needs the `--ignore-icc`? |
|
2025-11-24 07:58:31
|
otherwise libjxl's tone-mapping ICC might be taking precedence over the CICP |
|
2025-11-24 07:59:43
|
ah, never mind, didn't read the rest quite right |
|
2025-11-24 07:59:55
|
(just woke up 😅) |
|
|
|
AccessViolation_
|
2025-11-24 06:42:38
|
I'm pretty sure Firefox's color management isn't available on Linux, and changing about:config flags doesn't help |
|
2025-11-24 06:45:09
|
I went down that rabbit hole like a week or two ago |
|
2025-11-24 06:47:01
|
likewise it doesn't work on Firefox for Android |
|
|
RaveSteel
|
2025-11-24 07:32:24
|
It used to work in firefox 135 IIRC, but has stopped working since |
|
2025-11-24 07:32:35
|
heck, at this time I cannot even get Youtube with HDR to work anymore |
|
|
|
_wb_
|
2026-01-06 08:54:38
|
firefox doesn't support HDR at all afaik |
|
|
|
RaveSteel
|
2026-01-06 08:58:58
|
setting gfx.wayland.hdr to true works somewhat, but only for video and even there it is spotty |
|
|
|
Traneptora
|
2026-01-09 08:44:05
|
I can't really tell bc I use X11 |
|
2026-01-09 08:44:28
|
Ive been looking for a stacking wayland compositor that is basically cherios |
|
2026-01-09 08:44:38
|
like Metacity for wayland |
|
2026-01-09 08:44:45
|
but it doesn't exist |
|
|
|
Quackdoc
|
2026-01-09 09:13:34
|
hopefully eventually xlibre or Phoenix will support hdr |
|
|
|
Traneptora
|
2026-01-09 09:13:54
|
X11 probably never will |
|
2026-01-09 09:14:33
|
my monitor doesn't so whatever |
|
|
|
Quackdoc
|
2026-01-09 09:18:12
|
xorg probably never will, not x11. |
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2026-01-09 09:30:03
|
do you use xlibre ? |
|
|
|
Traneptora
|
2026-01-09 09:30:27
|
I bet he uses wayland |
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2026-01-09 09:30:49
|
oh yeah, that's what I thought |
|
|
|
Quackdoc
|
2026-01-09 09:31:39
|
I use both, but mainly Wayland via cosmic. xlibre on one device |
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2026-01-09 09:32:16
|
do you recommend going to xlibre instead of xorg ? |
|
2026-01-09 09:32:54
|
seeing it only on the AUR is what refrains me |
|
|
|
Quackdoc
|
2026-01-09 09:33:19
|
for now, not unless you want seatd or the extra security from xnamespace |
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2026-01-09 09:33:44
|
I'm still sticking to X11 because of IceWM, put too much effort to configure it <:KekDog:805390049033191445> |
|
|
lonjil
|
2026-01-09 09:35:20
|
Why would you use the Nazi xorg fork |
|
2026-01-09 09:35:46
|
Anyway rootful Xwayland is probably the future for people who want stuff to work into the future |
|
|
|
Quackdoc
|
2026-01-09 09:36:01
|
there is the per monitor DPI stuff too |
|
2026-01-09 09:36:11
|
because the so called Nazi fork is just better |
|
2026-01-09 09:36:21
|
meanwhile still no multi monitor |
|
|
|
lonjil
|
2026-01-09 09:36:50
|
But the guy who created it is so incompetent that Xorg maintainers had to rollback most of his code |
|
|
|
Quackdoc
|
2026-01-09 09:37:19
|
thats what they are saying, meanwhile xlibre has been going perfectly fine |
|
2026-01-09 09:38:04
|
and if his work is considered incompetent just wait until you see the kernel lmao |
|
|
|
lonjil
|
2026-01-09 09:38:05
|
Yeah I mean there were real bugs that were getting reported |
|
|
|
Quackdoc
|
2026-01-09 09:38:32
|
often due to them commiting PRs that were half done |
|
2026-01-09 09:38:54
|
this is evidenced by those same bugs not existing in xlibre |
|
|
|
lonjil
|
2026-01-09 09:39:02
|
"requesting this to be pulled"
"Wow why did you pull that that wasn't done" |
|
2026-01-09 09:39:23
|
And I recall at least one instance of that guy literally not even knowing the most basic C stuff |
|
|
|
Quackdoc
|
2026-01-09 09:40:04
|
is there any real evidence to this? The only case I found is one that's actually an extremely common error that many professionals get wrong. |
|
|
|
lonjil
|
2026-01-09 09:40:56
|
I don't even remember exactly what issue I saw was (my brain doesn't retain trivia like that) but I definitely thought it was amateur when I saw it. |
|
|
|
Quackdoc
|
2026-01-09 09:40:58
|
Yes, because that's the workflow that's was how xorg was using until they moved to GitLab. |
|
2026-01-09 09:41:36
|
meanwhile xlibre has real benefits over xorg like xnamespace and seatd support |
|
|
|
lonjil
|
2026-01-09 09:41:38
|
Uhh, that's not how email based development works |
|
|
|
Quackdoc
|
2026-01-09 09:49:44
|
branch based workflows and reviews. |
|
|
🐺 BONES ⚡
|
2026-01-17 01:42:09
|
coverage |
|
|
|
AccessViolation_
|
2026-01-17 01:53:58
|
oh no, not Theo - t3.gg again |
|
2026-01-17 01:54:43
|
some other time they made a video about JPEG XL they got comically many things wrong |
|
2026-01-17 01:56:27
|
the moment I heard him say "and JPEG XL, which I'm pretty sure doesn't support lossless" I knew what the rest of the video was going to be like |
|
|
|
jonnyawsom3
|
2026-01-17 02:52:49
|
Yeah, most of the previous video was his livestream viewers correcting him on various things by looking it up themselves |
|
|
hjanuschka
|
2026-01-17 07:01:55
|
damn - that's my CL - getting theo-d was not on my bucket list 😓 |
|
2026-01-18 12:55:16
|
is the recording somewhere? |
|
|
|
🐺 BONES ⚡
|
2026-01-18 01:31:44
|
He doesn’t save the vods
But he will make a video from the livestream within a week of it |
|
|
|
hjanuschka
|
2026-01-18 01:32:24
|
ok, was it bad about jxl? |
|
2026-01-18 01:32:39
|
he usually is freaking/bashing of off something, pretty insecure ego |
|
2026-01-18 01:32:43
|
atleast from my pov |
|
|
|
Quackdoc
|
|
|
5peak
|
2026-01-22 02:47:04
|
https://jpegxl.info/resources/jpeg-xl-test-page.html
©2024-2025 JPEG XL and the JPEG XL Community.
Year++
8-) |
|
|
|
HCrikki
|
2026-01-22 03:17:19
|
that page shouldve always had jxl files being downloadable so people could have something to test in non-browser applications. at least in some 'dont see the image? download it' |
|
|
|
jonnyawsom3
|
2026-01-22 04:30:41
|
https://github.com/jxl-community/jxl-community.github.io/pull/93 |
|
2026-01-22 04:31:03
|
Did a few quick tests and seems to work, so made a PR |
|
|
|
_wb_
|
2026-01-24 11:47:27
|
https://discord.com/channels/794206087879852103/822105409312653333/1464585670667407496 maybe should have written that here instead of in <#822105409312653333> |
|
|
|
jonnyawsom3
|
2026-01-24 11:54:42
|
The PR got merged by the way, image labels on the test page are now clickable |
|
|
|
HCrikki
|
2026-01-24 12:13:27
|
that sandwich tab could use some attention btw. even on 4K monitors you need to seriously go out of your way to find whats hidden there. software support and test page notably |
|
|
Exorcist
|
2026-01-24 02:07:11
|
I reviewed the common introduction of JXL:
- https://jpeg.org/jpegxl/
too short
- https://en.wikipedia.org/wiki/JPEG_XL
too verbose
- https://jpegxl.info/
too Apple-style
- https://cloudinary.com/blog/
separate in different pages
- https://arxiv.org/abs/2506.05987
too technical
- https://discord.com/channels/794206087879852103/822120855449894942
hide in Discord |
|
|
username
|
2026-01-24 02:09:21
|
what about https://jpegxl.info/old/ ? |
|
|
|
Exorcist
|
2026-01-24 02:15:47
|
The link of old site is at bottom, I didn't find this <:FeelsAmazingMan:808826295768449054> |
|
|
|
_wb_
|
2026-01-24 02:25:44
|
Maybe we should add a toggle on the jpegxl.info page to switch between the current polished "Apple-style" page and a more sober and technical page. I mean both in layout style and content. For the general public, the current page is perfect I think, but for a dev audience, I think we could use something a bit more no-nonsense and with more technical/practical info, like pointers to libjxl and jxl-rs, a technical overview of the codec and file format, etc. |
|
2026-01-24 02:28:51
|
The jpeg.org subpage can be updated but it's a pain since it can only be done during a jpeg meeting (so once every 3 months), and it requires committee consensus to make any change. And some committee members are very conservative, e.g. they don't want to have links to blogposts or community pages, only to papers and books. |
|
2026-01-24 02:32:48
|
There's also this: https://cloudinary.com/labs/jpeg-xl
which does try to centralize the info. But of course this is a cloudinary marketing page... |
|
|
|
Exorcist
|
2026-01-24 02:45:10
|
Also, the word "lossless transcoding, lossless recompression" is confusing
"repack" is more clear and honest |
|
|
|
HCrikki
|
2026-01-24 02:47:22
|
'Reversible' lossless transcoding imo would be more dscriptive as it covers both directions. Avg adopter will only care about no-loss transcoding to jxl anyway |
|
2026-01-24 02:48:57
|
Sometimes it seems theres confusion about efficiency over jpg with the 20% claim misunderstood |
|
|
|
Exorcist
|
2026-01-24 02:56:02
|
When introduce 3 modes of JXL,
I want to see this:
- lossy
- lossless
- repack existing JPEG ✅
Not this:
- lossy
- lossless
- lossless recompress lossy JPEG ❌ |
|
|
|
jonnyawsom3
|
2026-01-24 03:04:06
|
I mean, I think JPEG Transcode is fine when put next to Lossy and Lossless, otherwise why would it be seperate |
|
|
VcSaJen
|
2026-01-24 03:04:46
|
Software list link is also a bit hard to find, I didn't expect it to be exclusive to hamburger menu.
--- |
|
2026-01-24 03:08:18
|
I think there need to be a separate list of software that supports lossless jpg transcode (fully integrated via libjxl library, not via running cjxl subprocess). This is a widely advertised feature, and yet it's very hard to find software that takes advantage of that. Making a list would be very helpful |
|
|
|
HCrikki
|
2026-01-24 05:02:45
|
how about crowdsourcing updates into some shared public document the website would periodically reference? |
|
2026-01-24 05:03:29
|
DropWebp (alternatively named Drop Compress Image) handles lossless transcode on an aside |
|
2026-01-24 05:04:43
|
handful of scripts and simple guis just use cjxl underneath or command it as a remote process (ie server). would those qualify as applications? |
|
|
|
KKT
|
2026-01-24 06:53:33
|
There was supposed to be an entire 'technical' section of the site we just never got to before launch. And a new art page. |
|
2026-01-24 06:56:06
|
I've never heard the word repack used in this context. I think Transcoding is a better, more widely understood term, no? |
|
|
|
RaveSteel
|
2026-01-24 06:59:12
|
In my experience the average person is inclined to believe that changing a file extension converts a file, without ever having heard of the term "transcoding"
Maybe this has changed in recent years though |
|
|
|
AccessViolation_
|
2026-01-24 07:04:00
|
> changing a file extension converts a file
the windows line of reasoning |
|
|
|
jonnyawsom3
|
2026-01-24 07:04:17
|
I did that on this phone back in the day |
|
|
|
KKT
|
2026-01-24 07:22:46
|
BTW, we talked about a technical section to the site here using Docusaurus: https://discord.com/channels/794206087879852103/1256302117379903498/1285303997149876294 |
|
|
|
spider-mario
|
2026-01-25 05:49:58
|
I’m now imagining a file manager that would actually implement this |
|
|
|
AccessViolation_
|
2026-01-25 05:51:01
|
actually that's...not a bad idea for casual users |
|
|
|
spider-mario
|
2026-01-25 05:51:02
|
just picture it: you click `04. Exit.wav` to rename it, change it to `04. Exit.flac`, you get a brief progress bar and the file is smaller |
|
|
|
AccessViolation_
|
2026-01-25 05:54:40
|
if there's a popup that makes you chose between "change file name only" and "transform content into new file type" or something, I could see this being very convenient for less savvy users that don't want to bother looking for the right software to convert files |
|
|
|
RaveSteel
|
2026-01-25 05:55:22
|
most users don't even have file extensions visible, because the default on windows is to have them hidden |
|
2026-01-25 05:55:28
|
most users never enable them either |
|
|
|
AccessViolation_
|
2026-01-25 05:55:42
|
oh interesting |
|
|
|
spider-mario
|
2026-01-25 05:59:08
|
which put me in an awkward situation when I had to explain to someone why it was fine for two specific files to have “the same name” (they had different extensions) but not other files |
|
|
|
AccessViolation_
|
2026-01-25 06:11:45
|
we should create a file called 'con' to collect all the cons of the way windows handles files |
|
|
|
spider-mario
|
2026-01-25 06:18:13
|
incidentally, they were image files; I _think_ they were `.jpg` and `.png` but they could equally have been `.jpg` and `.jpeg` |
|
2026-01-25 06:18:42
|
they wanted a third file with the same name |
|
2026-01-25 06:19:12
|
(why couldn’t several photos have the same name? they were of the same person) |
|
|
|
username
|
2026-01-25 06:21:03
|
how did you explain it to them? I would have just said something like "Windows hides part of the file names by default so those two files technically have two different names you just can't see them fully" |
|
|
|
spider-mario
|
2026-01-25 06:22:37
|
unfortunately, that was about 20 years ago, so I don’t really remember |
|
|
|
runr855
|
2026-01-25 07:14:51
|
I''m sure most users have have the "Type" column enabled in Windows Explorer |
|
|
|
spider-mario
|
2026-01-25 08:43:39
|
does it default to column view nowadays? |
|
|
|
VcSaJen
|
2026-02-13 10:50:38
|
I'm a bit confused on the site's structure. Isn't it supposed to be a site generated by a static site generator, like Jekyll or equivalent? If so, I'm failing to find actual source code, there are only auto-generated HTML files in the repo.
***Edit***: I read earlier messages in this channel, looks like it does not use generation at all, I was just confused 😅 . |
|
|
|
KKT
|
2026-02-13 09:03:51
|
Yeah, someone was going to redo it with a static generator, but never finished. I've been meaning to do a rebuild but have been too busy |
|
|
|
RaveSteel
|
2026-02-17 04:57:59
|
the HDR test page on jpegxl.info currently shows this if a JXL image is clicked with stable chromium |
|
|
|
jonnyawsom3
|
2026-02-17 04:59:15
|
Works with the flag enabled though |
|
|
|
RaveSteel
|
2026-02-17 04:59:49
|
I have the flag enabled. the images load properly, just clicking on them for full view shows this |
|
|
|
jonnyawsom3
|
2026-02-17 05:20:16
|
Oh, I didn't know you *could* click on them |
|
|
|
RaveSteel
|
2026-02-17 05:26:00
|
same, until half an hour ago |
|
|
|
_wb_
|
2026-02-17 05:50:03
|
<@594623456415449088> can you update that so it uses a picture tag instead of guessing support based on user agent (or whatever it is currently doing)? |
|
|
|
KKT
|
2026-02-17 06:18:23
|
I think it is using a picture tag. That's the picture if it falls through JPEG XL |
|
2026-02-17 06:20:15
|
i.e. those images are all working for me in Chrome Dev on a Mac… |
|
|
|
username
|
2026-02-17 06:21:59
|
same issue happens for me when clicking a JXL image on the HDR test page in a browser with full JXL support |
|
|
|
KKT
|
2026-02-17 06:22:11
|
Ohhhhh |
|
2026-02-17 06:22:39
|
I think someone else added the clicking to expand feature. |
|
2026-02-17 06:23:51
|
Hmmm, the Compute Headroom has stopped working as well |
|
|
|
RaveSteel
|
2026-02-17 06:24:03
|
That works for me |
|
2026-02-17 06:24:37
|
at least in chrome |
|
|
|
KKT
|
2026-02-17 06:25:05
|
Mac/PC/Linux? |
|
|
|
RaveSteel
|
2026-02-17 06:27:02
|
Linux |
|
|
|
KKT
|
2026-02-17 06:27:12
|
Defs stopped working on the Mac. |
|
2026-02-17 06:45:23
|
Actually, this is a new machine. I might not have experimental features turned on. |
|
|
|
_wb_
|
2026-02-17 06:49:07
|
it works for me, but I do have experimental features turned on |
|
|
|
KKT
|
2026-02-17 06:59:28
|
OK, page updated if everyone wants to test. Apparently it was me who added the click to enlarge code a year ago… Great I have no memory of it. There was a small logic error that's been fixed. |
|
2026-02-17 07:02:35
|
And yes, I hadn't turned it on on this new machine, so Compute Headroom working as expected. |
|
|
|
RaveSteel
|
2026-02-17 07:07:25
|
works now, nice |
|
|
|
_wb_
|
2026-02-20 09:23:28
|
revamped this page: https://jpegxl.info/media/newsroom.html |
|
2026-02-22 08:21:10
|
added the old jxl art page to the menu and updated the layout for that page: https://jpegxl.info/art/ |
|
|
dogelition
|
2026-02-22 08:24:21
|
the source for zou produces an error |
|
|
|
_wb_
|
2026-02-22 08:27:51
|
we should probably replace all the source links to a more recent web interface, like luca's |
|
|
|
veluca
|
2026-02-22 08:29:46
|
or Helmut's, assuming we confirm it works fine 😄 |
|
2026-02-22 08:30:41
|
(as in, once we do I'll upload it in the usual place) |
|
|
|
KKT
|
2026-02-23 02:46:06
|
Looks good. We'll have to sort out the tabs on mobile. They're a bit busted. |
|
2026-02-23 02:47:44
|
Did we switch them to a dropdown at that size? |
|
2026-02-23 02:47:53
|
I can't remember. |
|
2026-02-23 02:58:05
|
Looks like there are a few issues with the mobile menu now too |
|
|
|
_wb_
|
2026-02-23 07:36:32
|
I think the layout issues are fixed now, please check |
|
2026-02-23 09:42:01
|
Are there any youtube videos or other talks/presentations/podcasts on jxl worth adding to https://jpegxl.info/media/newsroom.html?tab=Presentations ? Preferably ones that don't include me 😅 |
|
2026-02-23 09:43:49
|
https://jpegxl.info/ |
|
2026-02-23 09:44:07
|
only the main page has a nice link preview, hm |
|
|
awxkee
|
2026-02-23 01:15:02
|
https://github.com/awxkee/jxl-coder is listed twice at some point as supported software 🙂 |
|
2026-02-23 01:15:38
|
I think one entry could be changed for [swift bindings](https://github.com/awxkee/jxl-coder-swift) |
|
|
|
KKT
|
2026-02-23 03:45:23
|
I can add it to the others. Who do we have to harass to have JXL added to the list of supported filetypes for Open Graph images? |
|
|
|
_wb_
|
2026-02-23 03:46:10
|
added something to the others, though all using the same image so that's something that could be improved |
|
2026-02-23 03:46:24
|
https://jpegxl.info/resources/jpeg-xl-test-page.html |
|
2026-02-23 03:46:48
|
ok the generated descriptions have to be checked a bit lol |
|
2026-02-23 03:47:00
|
there's no encoding going on on that page 🙂 |
|
|
|
KKT
|
2026-02-23 04:06:24
|
Oh, yeah, that was going to be a totally different page when I wrote that. |
|
2026-02-23 04:16:44
|
I had big dreams for that page 🥴 |
|
|
|
username
|
2026-02-25 09:57:33
|
IMO the other pages still have poor discoverability. could we can some of the most important ones added as text based buttons on the top bar instead of it being mostly empty? |
|
2026-02-25 09:59:10
|
they are all practically hidden away in the hamburger menu currently and I wouldn't be surprised if visitors of the site are completely unaware that there are other pages |
|
|
|
_wb_
|
2026-02-25 10:01:59
|
I did add an expanded menu at the bottom of the main page, but I like the idea |
|
|
|
HCrikki
|
2026-02-25 12:02:52
|
support page could use some additional browsers and notable OSes with jxl support available out of the box.
* on by default: *zen browser*, *ladybird* (early supporter since serenityos with its high conformance inhouse decoder, since then integrates libjxl).
* off by default: similar to ff nightly, librewolf (limited), brave, cromite - maybe with an asterisk footer note specifying a user can enable it themselves for now and which flag to change where |
|
|
whatsurname
|
2026-02-25 12:56:10
|
I don't think it's necessary to list every Chromium/Firefox fork, especially those with the same JXL support status as upstream |
|
|
|
_wb_
|
2026-02-25 01:15:38
|
for browser support maybe it would make sense to start with the major browsers and indicate the status for each of them:
- Chrome/ium: behind a flag, all features supported
- Safari: enabled by default, no animation
- Firefox: behind a flag on nightly only
and then list the exotic ones that we want to promote because they have jxl support on by default
I wouldn't add the ones that are not doing anything special regarding jxl support |
|
|
|
jonnyawsom3
|
2026-02-25 02:07:14
|
I was going to say, I'm pretty sure canIuse has an embed available for the support table |
|
|
|
_wb_
|
2026-02-25 04:22:40
|
right, let me see if I can wire up https://caniuse-embed.vercel.app/ there |
|
|
|
KKT
|
2026-02-25 05:33:53
|
Can it be styled? |
|
2026-02-25 05:35:29
|
I wish CanIuse was a bit more clear about where things were for JXL. |
|
|
|
_wb_
|
2026-02-25 05:46:16
|
this thing is via iframe, you can select between dark and light but neither of them fit particularly well with our style. Then again, you can also see it as just an interactive diagram coming from somewhere external. |
|
2026-02-25 05:46:26
|
I added it in https://jpegxl.info/resources/supported-software.html |
|
|
|
KKT
|
2026-02-25 06:37:03
|
Yeah, it's kind of hideous and not very helpful I don't think. |
|
2026-02-25 06:37:25
|
I think it would be better just to link to it and come up with a better design that's clearer. |
|
2026-02-25 06:41:59
|
The new footer is in the wrong parent container. |
|
2026-02-25 07:03:11
|
The vast majority of browsing is done on the phone these days, so people are pretty familiar with hamburger menus since that's go-to choice. That being said, if we want to do a full menu that's fine, but a bastardization of both is a UX disaster. |
|
|
|
VcSaJen
|
2026-02-26 09:21:12
|
It would make sense to only list support if it's supported by default, i.e. not behind a flag or nightly-only. It would give more weight to the list instead of it being basically a filler. |
|