JPEG XL

At least it's only the frame start, and not something even more crucial. Like image size or something.

yea the super tiny header is useful for many super tiny images

but in those cases the TLS handshake and the HTTP roundtrip is more important than the size of the image

that's true

that's why I'm a big QUIC proponent as well

Images can be data-uri inlined in a page, and requests can be multiplexed etc...

<:JXL:805850130203934781>

For this small of an image you can probably afford `-e 10` in which i get a 1775 byte JXL file for that emoji

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

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

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

I'd try lossless with --keep_invisible 0

still 1775 bytes

.svg.br is the way to go for such images

Don't rasterize vectors unless you have to

whats .br

brotli

`-e 11` ftw

yeah but JXL's splines [⠀](https://cdn.discordapp.com/emojis/1059276598660059136.webp?size=48&name=av1_trollhq)

for brotli they really took the "compact header" idea to the next level didn't they <:tfw:843857104439607327>

who needs magic signatures

Aren't all compressed streams like that? IIRC, a raw deflate stream is also headerless

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

i'm only now realizing that this isn't an issue at all if you use a container format compatible with brotli

It's like gzip vs raw deflate. Both have their uses.

This is different problem domain. Speed of light is the limit.

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.

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.

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

One of the best examples of supreme libjxl domination over competitors is the "Sunset" image.

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!

Take a look at "Sunset," "Seikima," and "White Dune" for some good examples of libjxl domination.

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."

"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

I can also list some examples where libjxl does particularly poorly and highlights the 3 flaws I mentioned.

If anyone's interested

Either way someone should put these demos on the fan site for sure, in my opinion

I would credit the source too, "afontenot"

Looks like they aren’t using tune iq for avif, that’s a big disadvantage to avif

Is that a recently added thing?

Yeah pretty recent

Part of psy tuning fork merge?

Really hope those folks patch libjxl next 😂

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

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

actually a lot of our inspiration came from libjxl, and some from x264

Damn, it's too bad libaom is benefitting from libjxl innovations instead of the other way around 😂

I'm pretty mad at the tech lead of libaom for his childish removal of libjxl from chromium

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

So equally petty I want libaom to utterly fail

And libjxl to succeed ♥️

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 -_-

The devs seem afraid to make major overhauls/changes/refactors because alleged, unfounded fear of messing things up

libjxl-tiny is the only other encoder afaik

Is there anything x264 does that libjxl could copy?

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

Well x264 does have tune=stillimage or something and an intra-only mode without any motion vectors.

hydrium does ultra-low memory lossy encoding

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

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

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

I think it's better if the criteria is based on the image rather than the particular environment it's being run on

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

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.

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

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)

Heuristic... How? See if it has lots of HF data and use smaller blocks for more locality, with big blocks for smooth images?

Wait, this is the website channel...

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

I just personally would prefer the compression parameters weren't affected by the host system

Unless explicitly asked

Continuing in https://discord.com/channels/794206087879852103/804324493420920833/1360893182203789332

Maybe we shouldn't have *all* our email addresses publicly listed... <@594623456415449088> <https://jpegxl.info/about/contributors.html>

an ironic criticism given they were published publicly by each individual to an enduring and widely disseminated git repo

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

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?

Could link to their contributions to libjxl (or eventually jxl-rs)

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 😄

Not just the clouds but also the foliage

How is the yt encoder of today at encoding the clouds at 1080p resolution and av1?

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

correct. I use krokiet, the slint frontend for czkawka a lot :D

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

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.

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

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

....

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

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

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

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

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.

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

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

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.

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.

I also agree with monad, we shouldn't need to use old versions, but here we are

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

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

could help influence the scripters and integrators away from insanely ressource-hungry settings, efforts and implementations that damage jxl's reputation

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)

When the next version releases, we can definitely rerun the numbers and get some solid results for decode speed, progressive loading, ect

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.

this look weird. hits counter

Does that happen at a specific viewport width? On my phone it looks normal

I used waterfox on desktop. 1920x1080 on windows 11.

may be the problem with firefox based browsers? it looks like that in android waterfox but on chrome it looks ok.

I'll fix

Done

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>

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?

Actually, the dash is correct on Reddit.

I added Shutter Encoder and updated the Affinity logo/link on the software page.

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…

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?

AVIF: `avifenc -q 90 -s 0 -r f -d 10 -y 444 --nclx 9/16/9` JXL: `cjxl -d 1.5 -e 7`

I created the JXL from both the EXR & PNG and they both end up looking exactly the same.

I guess now that Affinity is free, you can take a run at the original too:

Had to split in two to upload.

maybe using `exr_to_pq` from libjxl?

ah, it seems it doesn’t behave well with alpha, I should fix that

is this how it’s supposed to look?

ah, one second, forgot the `--intensity_target=829`

there

I thought we were trying to avoid using AI generated content on the site?

there are so many nice freely usable images out there https://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year

I chose that one so I could crank the HDR-ness without messing with the actual intent of the image.

And those are great images, but I don't see any HDR ones in there.

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?

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

I was using the PNG to create the AVIF but it was dark too. What were the flags for the JXL?

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`

because that image is now in PQ, decompressing that jxl to png and then encoding that png to avif should not be dark anymore

(I really mainly used JXL as an alternative to PNG here, to convey the result of the PQ conversion)

Mmm. `avifenc -q 90 -s 0 -r f -d 10 -y 444 --nclx 9/16/9` from the PNG is giving me this:

Looks non-HDR

In case Discord is messing around with it

discord tonemaps preview images down to SDR

but if I open the original AVIF I can see it's HDR

It's not nearly the same as the JXL though.

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?

I have an non-HDR windows machine and you can tell the difference between the HDR & SDR but it doesn't look great.

my linux sys

Would an HDR JPEG work better as a fallback?

maybe it needs the `--ignore-icc`?

otherwise libjxl's tone-mapping ICC might be taking precedence over the CICP

ah, never mind, didn't read the rest quite right

(just woke up 😅)

I'm pretty sure Firefox's color management isn't available on Linux, and changing about:config flags doesn't help

I went down that rabbit hole like a week or two ago

likewise it doesn't work on Firefox for Android

It used to work in firefox 135 IIRC, but has stopped working since

heck, at this time I cannot even get Youtube with HDR to work anymore