JPEG XL

4 MB is the largest `output_size` for ICC at level 5

the box format explicitly allows XLBoxes (boxes larger than 4 GB)

actually i guess jbrd might have its own signalling limit

yeah, `tail_data_length`

im want to burn an image of an XL sized t-shirt encoded as a JPEG XL onto a BD-RE XL disc

> 1. HEIC and AVIF can handle larger images but not directly in a single code stream. You must decompose the image into a grid of independently encoded tiles, which could cause discontinuities at the grid boundaries. Illustration: grid boundary discontinuities in a HEIC-compressed image. _HEIC and AVIF can handle larger images but not directly in a single code stream. You must decompose the image into a grid of independently encoded tiles, which could cause discontinuities at the grid boundaries. Illustration: grid boundary discontinuities in a HEIC-compressed image._ Is this really different from JPEG XL in terms of discontinuities since JXL splits images into 1 MP blocks?

For some reason yeah jxl doesn't have tile boundaries like heif does

Somehow

It was designed to be super smooth with no discontinuities and block boundaries

Suitable for smooth gradients and skies

Hmm

Blocks can be independently encoded and decoded so I don't think it can actively compensate for discontinuities by looking at the pixels in surrounding blocks?

For an explanation on how this works, please refer to the following diagram

As you can see, it all makes sense now

Maybe the decoder just blurs the lines <:KekDog:805390049033191445>

the old vaseline trick

One format was actually designed to be suitable as an image codec for arbitrarily huge images

~~PNG?~~

oh 'suitable', no

The other is just... half assed container format with a video codec frame inside and all of its inherent limitations

Just as halfassed as webp before it

And just as forced

Because the guy pushing all these halfassed formats out just happens to be the sole decider of what codecs are enabled in chromium

And this is the second time he's abused his influence over the chromium source tree to force an unpopular half baked format he invented onto everyone thanks to everyone's dependency on chromium

While at the same time gaslighting everyone about how there's supposedly "not enough interest" for jxl in a bug tracker filled with reps from intel shopify nvidia facebook etc all very interested in having it enabled by default

meh

personally i think that kind of reasoning could use some hanlon's razor

I would really like to see jxl integrated in chrome but I don't think this is some personal vendetta from sam google codecs team

and unlike us they're probably not thinking about it on a daily basis, if at all

In jxl, the restoration filters (gaborish and EPF) run across group boundaries, while in any file format level tiling (tiff, DNG, HEIF etc), the tiles are independent so you may get visible seams when using lossy.

Oh then I was completely wrong about what the edge preserving filter was, I thought that was for edges in the image subject itself, like to mitigate ringing

Jim Bankowski is the lead of the chrome codec team, the team that made webp and avif and fast-tracked its adoption in chrome and youtube, and the subject matter expert seemingly responsible for ultimately deciding what codecs are included in chrome. After fast tracking his own half baked and unpopular formats, he essentially told a room full of big players in the industry (on the bug tracker) that there just "isn't enough interest" for a less half-baked format like jxl. He uses vague language like "we" and "our partners" etc. to deflect his own responsibility as a key decision maker and leader of the chrome codec team. Last time I brought this up several people said it's probably not good to bring attention to such a thing on such a personal level, but I don't understand what's bad about holding leaders accountable for making absolutely absurd decisions that impact a lot of people negatively, especially when they seem to have transparently selfish motivations.

It's so absurd and surreal that I'm really surprised it's even possible for something that ridiculous to happen

And actually even more surprised more people aren't talking about it and recognizing how absurd it is

Or questioning why he's some kind of god of the internet making decisions for everyone, beyond reproach

it is

it's for both

Aren't there also some DC related tricks to keep things nice and smoooooth?

Beyond block boundaries too

The Voldemort of image formats

I think you meant adaptive LF smoothing

LF image is encoded in Modular in most cases though, so LF doesn't affect group boundary discontinuity very much

Yes, there's adaptive DC dequant and extra_precision which both help to avoid DC-related banding in very slow gradients.

EPF helps for ringing/DCT noise but also blocking. It has a funky weighting that causes it to smooth a little more around block/group boundaries than inside the blocks.

Who appointed him as Lord though? That's what I wanna know 😂 Who appointed him as our web codec god and why isn't his selfishness being reigned in?

He's building up a legacy of using his own clout and influence at Google to force his own mediocre and half baked image formats onto the web time and time again, where he had the lead role in their creation and design, and at the expense of less half baked formats that have more industry support and demand

If you use witchcraft and turn him into a frog right now, literally nothing would change. This stuff operates on the level of multi-company groups, not on individual level.

I don't see any evidence of that. Calling the shots on this matter is in his job description.

And he hasn't specified anyone else that was involved in the decision making process.

AVIF yes, webp I think is an unfair comparison as our own Jyrki here designed the lossless format and it's pretty cool.

at the time webp lossless was state of the art, fantastic compared to PNG (and in some cases still beats jxl)

nothing like webp lossy which is just worse jpeg

Lossless WebP is still quite good in some scenarios

If only ffmpeg were able to decode it

it is via libwebp isn't it?

The lossless webp compression from Jyrki still is state of the art and better than jxl half the time. But webp has crippling limitations thanks to the overarching design decisions and Jim was and still is the leader of the project that produced such a half baked and limited format

yes

I just checked, it can decode lossless webp natively

``` leo@gauss ~/Pictures/test_images :) $ webpinfo compass-64.webp File: compass-64.webp RIFF HEADER: File size: 1796 Chunk VP8L at offset 12, length 1784 Width: 64 Height: 64 Alpha: 0 Animation: 0 Format: Lossless (2) No error detected. leo@gauss ~/Pictures/test_images :) $ ffmpeg -i compass-64.webp -f null - ffmpeg version N-97819-g0225fe857d Copyright (c) 2000-2025 the FFmpeg developers built with gcc 14.2.1 (GCC) 20240910 configuration: --prefix=/home/leo/.local --enable-gpl --enable-version3 --enable-nonfree --enable-shared --disable-static --disable-htmlpages --enable-manpages --disable-podpages --disable-txtpages --enable-frei0r --enable-gcrypt --enable-gmp --enable-gnutls --enable-lcms2 --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcelt --enable-libcdio --enable-libdav1d --enable-libdc1394 --enable-libfdk-aac --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libiec61883 --enable-libharfbuzz --enable-libjack --enable-libjxl --enable-libkvazaar --enable-libmodplug --enable-libmp3lame --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librtmp --enable-librubberband --enable-libsmbclient --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxcb-shm --enable-libxcb-xfixes --enable-libxcb-shape --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-openal --enable-opengl --disable-openssl --enable-pic --enable-ffnvcodec --enable-libdrm --disable-outdev=sdl2 --enable-vapoursynth --enable-vulkan --enable-libdvdread --enable-libdvdnav --enable-demuxer=dvdvideo --extra-cflags='-Wno-format-truncation -Wno-stringop-overflow -Wno-array-bounds' libavutil 59. 56.100 / 59. 56.100 libavcodec 61. 31.101 / 61. 31.101 libavformat 61. 9.106 / 61. 9.106 libavdevice 61. 4.100 / 61. 4.100 libavfilter 10. 9.100 / 10. 9.100 libswscale 8. 13.100 / 8. 13.100 libswresample 5. 4.100 / 5. 4.100 libpostproc 58. 4.100 / 58. 4.100 Input #0, webp_pipe, from 'compass-64.webp': Duration: N/A, bitrate: N/A Stream #0:0: Video: webp, argb, 64x64, 25 fps, 25 tbr, 25 tbn Stream mapping: Stream #0:0 -> #0:0 (webp (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help Output #0, null, to 'pipe:': Metadata: encoder : Lavf61.9.106 Stream #0:0: Video: wrapped_avframe, argb(pc, gbr/unknown/unknown, progressive), 64x64, q=2-31, 200 kb/s, 25 fps, 25 tbn Metadata: encoder : Lavc61.31.101 wrapped_avframe [out#0/null @ 0x5724982241c0] video:0KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A speed=38.8x ```

Ah sorry, I should have specified animated WebP, my bad

oh, there's a thing on the ML for that iirc

dwebp also does not support animated WebP

isn't that the reference implementation

I think so, yes ``` Usage: dwebp in_file [options] [-o out_file] Decodes the WebP image file to PNG format [Default]. Note: Animated WebP files are not supported. ```

huh that is what it says

I think much of the limitations of webp (dimensions, bitdepth, 420) came not from Jim but from Skal, but I may be wrong. Hard to tell from the outside how decisions were actually made. But from the little interactions I have had with Skal, the general approach of "good enough for the web" seemed to play a big role in his design philosophy.

Who came up with the goofy idea of calling it web pee

I guess WebM was first

WebI would also sound silly I guess

Even Android, that comes from the same Google as webp, can't decode awebp oob. Separate lib is required 🤦‍♂️We faced this issue right now

Webm sounds bad too

Especially since it's literally just matroska

People keep insisting it's different but it's not according to the spec...

WebP is RIFF at the container level...

Do correct me if I'm wrong, but doesn't Android not support animated AVIF either?

I'm not sure, we did not investigate it

Yet larger images have been existing https://commons.wikimedia.org/wiki/File:Blue_Marble_2002.png

The dimension of 43,200 × 21,600 pixels is far larger than WebP's limitation

I kind of understand webm. It’s basically just Matroska but only supporting open source codecs (vp8 vp9 av1 Vorbis opus webvtt etc..)

Anyone who says it’s not matroska is silly though

what I dislike about webm is that the standard never got any meaningful updates after vp9

so av1 support is "de jure" (every player/muxer/tool that has webm support understands av1 if they have support for the codec), but not "de facto" (so uploading an av1 webm video to a service that supports webm isn't guaranteed to work)

this is the case with any format that can be extended

nothing really possible about that

with a revision, software makers at least have some sort of formal reference to adhere to

they can still reject implementing the revision of course, but doing so it's an explicit action that can be documented

which is at least better than "welp, webm doesn't really state av1 is supported anywhere in their docs so 🤷‍♂️"

has that ever actually happened though?

Yeah but nobody expects matroska to mean "every possible codec combination ever"

It's weird that they rebranded something that already had its own branding. You don't just scribble out someone else's brand and put your own cringe there instead

matroska actually sounds cool :)

actually a lot of people expect this

cause for the most part it does work

WebM is a specific subset of matroska. Every webm file is matroska but not the other way around fwiw

matroska is designed in a way that devices and decoders are not expected to support and recognize every feature ever made

That is true, which is why a specific meaningful subset was standardized

No, it's not meaningful... The webm spec is basically the ENTIRE matroska spec.

Just with certain av codecs singled out

That doesn't sound right

https://www.matroska.org/technical/elements.html

yea, are split files part of webm spec

iirc they are not

Notice here: `W — All elements available for use in WebM.`

Pretty much the entire spec is in webm

It's literally just matroska, in its entirety. It's not a meaningful subset or anything.

that doesn't sound correct

idk about split files, but basically the supported matroska elements in webm cover nearly every element in the spec

all it really specifies is a certain combination of video/audio codecs

and they slapped their ugly branding on top and scribbled away the cool matroska branding

these are ebml entries. they do not correspond directly with features

it seems uncool to rebrand someone else's project, but if webm didn't sound so cringe compared to the original name it wouldn't be so bad

liking a name or not is subjective

also matroska is a registered trademark

Well that's basically all that matroska is, a specification on how to read and interpret ebml elements.

That is not the same thing as a list of features

most of these are simply metadata tags

like chapter title language

I know it's subjective but I feel there's an argument to be made that maybe webm is objectively worse sounding than matroshka

😂

notable things like file referrals and laces are missing

It's a container format, the only "feature" is containing/organizing metadata and payload

I don't think you understand as much about the purpose of a container as you think you do

Perhaps not!

AVIF uses the MIAF subset of HEIF, I guess it's similar to WebM being a subset of mkv

I also think it's pointless to complain about you personally disliking the name

when Matroska itself is trademarked

Who owns the trademark?

https://www.matroska.org/legal.html

a nonprofit in France

So they don't want people to use the name if they don't intend to fully implement it, kind of makes sense I guess

Well I actually didn't know about it being trademarked but their website encourages commercial users to contact them to ensure compatibility.

On this page it says they'll allow the usage of their branding in exchange for becoming a sponsor

https://www.matroska.org/license.html

It's clearly designed in a way that implementors can choose any subset of the spec they choose to support and you're clearly not meant to support or use every possible ebml box

It's a bit of a hurdle to do it that way though. With jxl we just define conformance and anyone can make an implementation and claim it is conformant. Whether or not you want to believe such claims is in principle just a matter of running the conformance tests.

Yeah, they are kinda protective of their branding by comparison. But it's their way of trying to get sponsorship I guess. They don't have the backing of ISO 😂

If a corporation is going to benefit and save money by using matroska it makes sense for them to give a little bit of the money they saved back to the project that made it possible.

Rather than just take someone else's work, benefit from it and change the branding to avoid having to pay any money despite being one of the most wealthy and powerful corporations on earth 😂

You keep acting like it was stolen without permission

I wish you didn't need to recompile programs to recognize other codecs in mkv. tho I dunno if that is an ffmpeg thing specifically or an mkv one

that's ffmpeg specifically

honestly I have no idea if they reached out and asked

or if they became a sponsor

sadge T.T ~~yet another reason to migrate to gstreamer~~

gstreamer is awful

yeah... I don't like the audio video library state of things right now

you should expect that list to be done at compiletime

why would you need or want that kind of runtime configurability

if only rustav didn't effectively die <:PepeHands:808829977608323112>

in general, I don't see the need for it in the modern world. I use the jxl video mkvs I use for instance, in general it's really nice to put "whatever you want into a container" especially for things like image sequences

so then stop just talking as though it didn't happen

Because jxl video mkv is a thing you invented and you shouldn't expect it to Just Work

I don't see why a user shouldn't have the capability in a modern world. It's a useful feature in general, and the cons of having such flexibility are small

well for starters how do you expect ffmpeg to map a fourcc to a codec id #

if you didn't compile that in

matroska stores riff fourccs

I'm not saying that my hack is a good one, rather just that the features itself are. I would rather see a new container without the limitations that caused this

Except what you're asking for is for software to just implicitly know how to decode a codec for which it has no mapping

which is an unrealistic request

it sees a fourcc that it doesn't recognize what do you think it *should* do?

how is ffmpeg supposed to select the right decoder if it sees a file that has a codec tagged with something it doesn't recognize

<@184373105588699137> like, what is your solution to this problem

A new container format? Same question

What do you expect the software to do

that's a good question, and not one I have an immediate answer for. However I do know that fourcc itself can be rather limiting in this aspect as you may have a bunch of custom fourcc stuff in the world. I think a better solution might be to leverage existing file parsing stuff, but this isn't something I can think of a good implementation for off the top of my head, it's easy to say "scan this range of bytes for the magic header stuff" but ofc that can always have issues too.

that being said, I don't think it's an unfeasible task to do given adequate thought

Fair, I'll stop complaining about how bad it looks 😂

oh right, also I forgot what are you talking about?

webm spec is being maintaned here https://github.com/ietf-wg-cellar/matroska-specification

https://github.com/ietf-wg-cellar/matroska-specification/blob/5ed5c4363cacf8a72d5e52182b36c5a61e8d5e42/codec/av1.md

> This document specifies the storage format for AV1 bitstreams in Matroska video tracks. Every time Matroska is mentioned it applies equally to WebM.

Quack, ffmpeg is great! I dunno why you're sad... The codecs it supports is configured at compile time because that's what ends up being the most convenient and likely time to decide.

in the end, one thing I like about gstreamer is that I almost never have to mess with something once I get it working (though getting it working can often be pure pain)

It allows you to disable certain codecs for paranoid patent reasons for those distributing compiled binaries

gstreamer's plug in system for sure has issues, but it's strengths are hard to deny, I just wish we had something modern

If something is disabled in ffmpeg blame whoever compiled it or wrote the compile script

ffmpeg is modern and awesome

Trust me

It's great!

https://cdn.discordapp.com/emojis/867794291652558888?size=64

It's basically the final word in av libraries

rip whip, maybe moq will have a better chance with ffmpeg

Anything that starts with a g is suspect

actually true

oh, interesting

ok, AV1 in webm is official then

also JP2K in matroska as well, neat

https://github.com/ietf-wg-cellar/matroska-specification/commit/1cd0a9be4b2d1e7c60184ec68404e00e46e3123e

the obvious solution is my cursed patent pending idea to make every media format a wasm bytecode file that has the decoder as the program and the media attached as static memory at the bottom interested in commercial use? let's talk: pay-us@cursedformats.com

lmao

and DNG is TIFF

And everything is octet-stream

gstreamer is better than ffmpeg because gstreamer has a lot of Rust in it

based, rewrite ffmpeg in rust time [av1_chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&name=av1_chad)

what are dots?

it says nothing about them in the draft spec, iirc they were a feature similar to patches that may or may not have been removed?

not a JXL feature if you're wondering

patches, splines, and noise are the three overrendered features

you may be thinking of Spot Colors

> Currently patches are mostly for text in screenshots and dots are intended for something like a few stars in the sky in a regular photo https://discord.com/channels/794206087879852103/803645746661425173/1326667918662176850

are they a libjxl specific thing then, making use of some other coding tool

IIRC, it's another Patches heuristic that searches for points of color instead of text

Ahhh gotcha

You know, that might be a good starting point for implementing splines in the encoder. You could maybe encode dots with a gradient falloff, like stars, as zero-length splines?

I wonder if it'd be worth it, or if splines require so much data to define that a simple patch or nothing at all would be better

IIRC it does also take into account gradients

Or beneficial rather, I doubt it'd be *worth it* to spend time on regardless <:KekDog:805390049033191445>

Hard to tell what's dots and what's patches in a normal encode

Dots were a separate coding tool in an early version of jxl, with quad trees to signal positions and quantized ellipses for the dots themselves. We removed it from the final spec since doing them with small patches also worked, and it simplified the spec quite a bit.

anyone have balanced `cjxl` parameters for serving lossy images on web?

the defaults are pretty good, I'd only add `--faster_decoding=2 --progressive`, and potentially look into jxl.js, but you can probably use a significantly higher distance, as even up to d2 i find it hard to see any loss without pixel-peeping. Do keep in mind this is my entirely "out my ass" opinion.

Well, the defaults are fine. If you care about progressive decoding `--progressive_dc=1` is recommended.

If you are aiming for medium quality images I would say distances up to 2 look fine on the web.

Unless you're loading hundreds of images on a web page, faster decoding is not really necessary imo

I wouldn't , just use progressive_dc

it is really nice and ads very little size

Mostly because current progressive is broken due to chunked encoding

For the web, I would say d2 would be the typical target. If fidelity is more important than usual, then maybe d1.5, or even d1. If bandwidth is more important than usual, then maybe d2.5, or even d3. The range d1-d3 probably covers 98% of what is used/needed on the web.

Artworks available on websites mostly go to the two extremes — either bloated PNG or JPEG worse than d2 equivalent

I use d1 or d0.5 for gallery style applications, d2 for general use, and d5 for preview stuff

preview stuff being "click to view full image" things

i see

alright then

oh, and is there a jpeli binary anywhere for windows?

the one in the libjxl release page seems outdated

https://artifacts.lucaversari.it/libjxl/libjxl/latest/

Here is a nightly build

great, thanks

well that sucks

oof

and for jpegli? quality 95?

or is 90 enough

nevermind

i saw `-d`

You can also use distance with jpegli

So more like q80-85 typically, q65-90 covers most web applications.

q95 is camera quality, too high for most websites

ic

the default of progressive level 2 is fine right

Defaults should be sensible in cjxl

sorry i meant cjpegli

Same

d0 for cjpegli isn't equivalent to d0 for cjxl however

Right. Cannot do lossless within de facto JPEG...

I did try cjpegli -d0 yesterday and its ssimulacra2 score is just about 92, if I recall correctly

Tested again, about 91.5 of ssimulacra2. Slightly higher than JXL d0.1 for the same source

Also interesting that `cjpegli -q 100` archived the slightly higher score than `cjpegli -d 0`

I thought d0 and q100 should be equivalent

Did you try `-d 0.001`?

Could it even reach higher quality?😧

did you try -q 101?

Anyone know why Mozilla is draging its feet on JXL?

paid off by big tech (google)?

if this is Waterfox, you need to update

they had a JXL-related decoding bug

they're waiting for jxl-rs, should be done in a couple months

so is jxl just not finished yet I noticed its not in a 1.0 status

im not really a programmer or a software guy

it's fully compliant and working, it's just not 100% stabled

what does that mean is laymen terms?

In terms of image decoding, it's stable enough to use it in projects such as browsers or image viewers. But the decoder is written in C++, a memory unsafe language, and Mozilla is concerned that might introduce vulnerabilities into the browser so they are waiting for the decoder implementation in Rust (a memory safe language) to be finished. Here's the latest update on the progress regarding this: <https://github.com/web-platform-tests/interop/issues/700#issuecomment-2551623493>

ah okay

it's floorp

Better late than never 🥹

It means it's missing certain things the devs want in the 1.0 release. I forgot which features they wanted to include for 1.0. The ultimate fate of libjxl after the 1.0 release is... jxl-rs might just replace it.

Isn't jxl-rs just a decoder?

Yes, at least for now

i'd love it if there was a rust-based encoder, then i could actually actually try implementing my wacky encoder ideas in a fork instead of just talking about them <:galaxybrain:821831336372338729>

zune-image has one but it's jusf the fast jxl thing ported

It would be interesting if so-called libjxl 1.0 is in fact the complete jxl-rs

Can C code include rust code as a library?

yes

```rust // Rust #[no_mangle] pub extern "C" fn hello_from_rust() { println!("Hello from Rust!"); } ``` ```c // C extern void hello_from_rust(); int main(void) { hello_from_rust(); return 0; } ```

So rustc can produce C header files right?

not rustc itself, but cbindgen can

i'm curious, does anyone have a set of like, "i wish we did this differently" things about jxl? things that were a good idea then but you feel like they could have been done better in hindsight?

i think my only one is 24-bit integer and 32-bit float being the limit for bit depth per channel. you're not very likely to be in a situation where more are very useful, but i don't think it would have hurt basically at all to have a possibility to have 32-bit int and 64-bit float and int. maybe even 128-bit float and int. i think they'd slow down encoding and decoding and increase memory usage, but the file size should stay relatively the same with good predictors, and after (or progressively during) decoding they'd probably be clamped

default effort should be adaptive, correlated to the img resolution. like, if youre crunching webcam/avatar-sized images, default effort increases by 1-2 for smaller sizes with really negligible difference in ressources consumed and time spent. opposite for huge images: default lowers by 1-2 depending on the megapixel count so as to maintain performance (jobs could take 20x less time than if they maintained the og default effort)

not quite jxl or libjxl specific, but any encoder/gui with user-adjustable complexity levels could gain from this in place of an inflexible same effort for *all* the images of this encoding job

I have a few regrets about being super efficient with headers and about the way the file format handles sections

also I think we should have allowed the DCT context model to be expressed by a modular tree (and special-cased the current ctx model), and I think we should have let modular trees make decisions over linear functions of properties

Could this be added to the spec in a future revision?

I guess so, but I'm not sure I want to

ah, another regret is not interleaving channels in modular mode 🙂

We left the option open to signal up to 64-bit in the bitdepth header, so it would be possible to make a Level 20 in the future that requires an implementation using double precision for lossy and int64_t for Modular. For now we saw no need to define or implement that, but if there is a need, it would be possible within the current header syntax.

The TOC signaling would have been more convenient if there was an option to use fixed-size section length fields. The compressed ICC profile could have used a size field that is technically redundant but would allow skipping it if you just want to find the frame headers.

Having a way to use VarDCT for extra channels would have been nice.

And what <@179701849576833024> said about MA trees in the AC ctx model.

the spreading of noise LUT values is also not ideal from what I remember

if I recall correctly, it’s in the direction of the range extending unnecessarily high, such that there isn’t a lot of precision for the values that are likely going to be actually used

Also maybe the option of 128x128 or even 64x64 group sizes for VarDCT, and also smaller ones for modular would maybe have been useful for a GPU implementation.

Maybe splines should have had the option for also working on extra channels (in particular alpha) and having an optional kReplace-like behavior instead of kAdd. Plus maybe the spline params could have been put in a modular subbitstream.

The noise synthesis could also use some optional extra params for how to apply noise to the different channels, instead of assuming XYB.

It's not really too late to add a new header format standard, at this early stage of adoption, right?

In addition to the existing one

I think it's still pretty early if someone wanted to add stuff like that to the spec and to libjxl

It's only too late to remove stuff, not add stuff

I thought VarDCT goes all the way from 8x8 up to 256x256? Or do you specifically mean groups for DC, ect

jxl-ng v2

Overall it's a really carefully thought out and thoughtfully considered bitstream format from what I can tell

It sounds like there aren't any major regrets.

I wonder what veluca would change about the compact header or section format, or what "linear functions of properties" are.

Encoder shouldn't be trying to be too smart. You assume "Higher resolution => higher density", which isn't the case in half of the times. It have no idea about actual canvas size. Use the principle of the least surprise

Actually, to a certain extent, there are certain optimizations and compression techniques that work really really well on large images but not on small images, and vice versa.

So it makes a lot of sense for the encoder to be smart about that to some extent and compress very large images differently. Not necessarily at a different pixel/distortion ratio. But definitely use techniques that make sense for the pixel quantity.

Extremely large images with very little high frequency information is a special case that can be optimized a lot to have very good quality at extremely low bitrates.

Also, recursively progressive images could make sense for ridiculously big images. But obviously not for thumbnail and icon size images

The encoder SHOULD be smart enough to use the appropriate tools to match the content it's compressing.

For starters, it would be nice if it was smart enough to detect if an image would have a better bitrate in lossless mode than lossy DCT mode.

That way people don't accidentally bloat file sizes and degrade quality at the same time.

It should be smart enough to recognize the image enough to select the appropriate compression tools without the user having intricate knowledge about image compression parameters.

It's not gunna be easy, but it's The Dream. A universal, set-it-and-forget-it image encoder.

No fiddling with flags. Just set it and forget.

I think Cloudinary is using some kind of neural net to do something like that?

I mean group size, not block size. In VarDCT the group size is fixed to 256x256.

Correct. Though it also makes mistakes sometimes.

if you change your mind it would probably be good to do it soon ish while there is still basically one decoder in common use and before everything starts supporting it. otherwise it would probably end up like JPEG with arithmetic coding :p

though we can just do a JPEG XXL in the future :)

The Next Next-Generation Alien Technology from the Future Format

I'd prefer to avoid making extensions to the spec that will produce images that don't decode with current decoders. That prevents most of the things on the "with hindsight, maybe it would have been better if" list. Though some things could still be done, e.g. adding sub-section offsets (plus entropy coder state) that would allow decoding modular planes in parallel or vardct HF coeffs in stripes of 64 rows, if the encode was done in a way that makes that make sense (no prevchannel properties, no varblocks crossing stripe boundaries). This could be added in a frame header extension and would only be useful to speed up decoding but just ignoring it would be fine, so existing decoders still work.

Well, you could add support for new bitstream formats to the current decoder software, but have the encoder continue to produce the same old bitstream until everyone upgrades their decoders.

Apple is the main player here and I think they're currently using libjxl as the decoder support library

If you want to make bitstream changes, just update the spec and update the decoders like libjxl but ensure the encoders are still producing the same old format until the day everyone is using a newer version of the decoder

But it sounds like all the bitstream changes you guys were talking about were all extremely minor and low impact anyways

It's already an astoundingly well designed format

There was already a week long discussion about the bug that caused lossless files to fail decoding outside of libjxl. Intentionally breaking backwards compatibility for anything non-critical seems unlikely at best

Apple can and probably will upgrade their version of libjxl in the future. There aren't any other major commercial products with jxl support that won't have the capability to update their decoder software in the foreseeable future.

No one is going to be using libjxl 0.7 anymore at a certain point in the future.

So maintaining compatibility with old software is not necessary in the long term if it's done correctly.

It's still possible to change things at this point in the life cycle of jxl

Just add decode support to current software first, and don't enable it on the encode side until everyone is using the newer version of the library.

And continue to support the old bitstream format forever.

Libavif is currently doing that with lossless YCoCg support. I'm surprised they're still breaking things after ver 1.0

If we're going to change things, we better do it now before libjxl becomes mainstream

Assuming the changes are actually good enough 😂 like I said the format is already incredibly well designed and the current bitstream format must be supported forever regardless. A new bitstream format would have to bring concrete advantages and tangible coolness to the table.

To be worth creating

Then it would be added on a very experimental basis with no encode support unless --use-idiot-options enabled (they should rename it from "expert")

It would be decode-only for a long time until everyone is satisfied and no one is using ancient libjxl

Theoretically it shouldn't be a problem this way

But it's a lot of ceremony for something with limited benefits and impact

Unless the proposed new bitstream is actually really tangibly cool and awesome compared to the existing one

Ease of 3rd party implementation should be a priority and ideally any changes to the spec should make it easier and not harder on people trying to create jxl decoders

With all that in mind I think it's kind of unlikely there will be any changes

Jon would probably be something of a ringleader and organizer if that sorta thing were to take place 😂 so if he doesn't think it's worth it then it probably won't happen

He's like the most energetic promoter of jxl in general too from what I can tell

I think there's value in not making spec changes, it helps avoid creating the impression that supporting the format is a "moving target".

So if we make changes, they should be worth it, or they should be things like decoder speedup hints that can be ignored without any impact on the decoded image.

None of the things mentioned above that "with hindsight would have been done a bit differently" are major things, it's mostly things that would have been slightly more convenient for encoders, would further increase the bitstream expressivity and thus potential compression improvements (but it's already expressive enough to leave room for many decades of research on encoder improvements), or things that would allow faster decode (but decode is already more than fast enough for most use cases).

in most other cases i personally think keeping things static to avoid the "moving target" is very valuable, at the same time this is intended to be a long-term format specifically. if we're being drip-fed new formats then you can select one that has the nice to haves that you desire, but since jpeg xl is specifically designed to be viable for a very long time, that does put a bit more weight on those imo

but if we implemented all our wishes now and said this was the *true* final version, it's not like we wouldn't have a similar situation with new "we should have done that" cases in the future again

i also agree that jxl is more than good enough already, it blows everything else out of the water in terms of viability for many different use cases as far as i'm aware

jxl could go the opus 1.5 way, and have improvements be backwards compatible

e.g. by adding a tiny bit of extra metadata that could help an enhancement layer increase the fidelity of an encoded image

non-aware decoders would just deal with the base image

imo improvements in libjxl should not be part of spec changes to jxl but passively obtained through software updates to decoders and encoders

even now theres still holdouts stuck on old libs 0.8 that have yet to experience it properly and update scripts for 0.10 and newer. unneeded changes could upset early adopters and diminush the position of those pushing for adoption

are there any hardware decoders in existence right now?

the answer most likely will make or break considering the argument

None afaik

are there even hardware decoders for image formats typically? images are pretty fast to decode regardless compared to a video

iirc AVIF decoders also don't attempt to make use of available AV1 decoding hardware

maybe digital cameras have hardware JPEG decoding? but practically they'd only need to be able to decode the images they produce, so an extension to JXL wouldn't really affect that

There are some for jpg

https://developer.nvidia.com/nvjpeg

so I've noticed cjxl seems to do poorly with closely repeating patterns compared to cwebp

Talked a lot about it recently

e.g. with dithering on (which appears to do ordered dithering) in Subnautica Below Zero, this is substantially larger in <:JXL:805850130203934781>

it's not just grayscale though

How much larger does it become?

3,480,383B vs 3,036,662B, so almost 15%

Not that bad

15% is pretty bad in my book

The sample I mentioned is 3 times larger

well sure, there are definitely worse examples

or saving -288.6%

Corrected the number, slightly better

my SMM one is the most egregious example I've found, where the JXL is ~3.47x as large

I assume patches are automatically enabled/disabled at certain effort levels?

I always use effort 7 (default) however

ah, this was testing all efforts for both encoders (not counting things like e11) and taking the smallest of both

There is value, but there's also not that big of a cost in doing it at such an early stage either.

Just my 2¢

Especially if those changes are made quietly and non disruptively

No one would even notice.

for lossless, patches are enabled at e10 in general and e5+ for single-chunk encoding. note that patches need to meet a relative value threshold and need to include at least one patch of 20+ pixels. also note libwebp is still far more efficient where libjxl patches work best, on text.

``` cwebp -z9 ------ 3,036,662 bytes libjxl -e9 ----- 3,484,727 bytes -e8 with sauce - 2,774,145 bytes ``` The sauce in question is `-d 0 -e 8 -I 20 -g 3 -P 1 -E 4`

No patches needed

well, I don't do that sort of tuning for webp, so I shouldn't have to for JXL

I know, libjxl's heuristics just isn't mature enough like WebP is.

fair enough, but it seems like that is the area with biggest room for improvement now

I consider the lossless mode the most impressive element of Jpeg XL. I can't wait for what the future holds.

I wonder if tuning can redeem JXL here: https://discord.com/channels/794206087879852103/794206170445119489/1212025660831301692

On it boss <:CatBlobPolice:805388337862279198>

I'm going to try some things on my end too

e11 is still quite a difference (in a bad way) from webp...

what the smallest size you got it down to?

What's the command of cjxl to produce the lossless non-photographic image as small as possible?

333,941B

I got it down to 333,933 bytes *Edit (11/03/25): many months later, using this command `cjxl in.ppm out.jxl -P 15 -g 3 -I 100 -E 4 -e 9 -d 0 -Y 0` I got it down to 323,107 bytes. Still a long ways to go.*

.ppm.xz is 196,900B, which is better than either codec <:PepeHands:808829977608323112>

".ppm.xz" is not a image format tho. That's kinda cheating

pfm supremacy

doesn't make it any less embarrassing...

To be fair that source image is one best candidates for preprocessing I've seen

Like downscaling with nearest neighbor then using JXL's upscaling

yeah but it's scaling from the 'native' res isn't simply NN, it's probably bicubic or even bilinear

either way, not ideal

The opposite of ideal

well actually there are two resizers going on there

first is the internal scaling using NN to whatever the console is rendering at

then there's the additional scaling by the emulator to UHD, which is not NN

anyway I will be running another round of compression benchmarks soon, and will compare not just WebP and <:JXL:805850130203934781> this time, but also ppm.xz for everything

best attempt clean rescale

looks pretty good <:PepeGlasses:878298516965982308>

You know... technically you could store the .ppm in a metadata box and compress it via brotli <:KekDog:805390049033191445>

At least then JXL would beat WebP

krokiet/czkawka is really nice but you kinda really quickly hit the limitations of jxl-oxide on it when you are comparing a load of images EDIT: highly reccomend recompiling czkawka with `target-cpu=native` it helps a lot

need jxl-rs I guess [pepehands](https://cdn.discordapp.com/emojis/1075509930502664302.webp?size=48&name=pepehands)

for context

well that's even less likely to display in an image viewer than ppm.xz

and probably going to be larger as well

`cjxl -d 0.5` vs ssimulacra2 = 90, which is the better metric for the visually lossless quality?

We had similar results on Factorio screenshots. The issue is generally repeating tiles/sprites that don't have a clean background. So JXL can't create patches but regular compression can see the patterns

Could be done using layers if JXL encoding were integrated into the game, we've seen up to 10x size reduction in testing from that, but obviously it's unlikely at best...

distance is butteraugli distance, but it's really just an estimate

in any case I don't think butteraugli is as good as ssimul2, but both have their issues

cjxl distance is a target, Ssimulacra2 is an actual measurement. Higher effort settings should make them align more closely. Or rather, give you a more accurate comparison

cjxl says "Target visual distance in JND units"

I fear this may be another victim of image converters not warning about transcoding.... https://www.reddit.com/r/jpegxl/comments/1iidd37/

> I archived all the jpegs into 7z for a smooth transfer and that made me regret EVERYTHING. The space-savings I got from hours spent on converting was nothing compared to what I got from archiving in minutes.

Maybe we should explicitly ask other tools to warn if the input is JPEG and they don't pass it through to libjxl properly

So is that JXL or JPEG?

Read through the article several times and still can't get what has been done

> I was using XL Converter from codepoems sounds like the source of the issue right there

Perhaps not > Its 5.2 gigs to 1.9 in 7z compared to just 4.4 gigs in jxl lossless transcode.

That fits the transcoding savings, just seems like there was an absurd amount of redundancy between images

well something is up if they're going from 5.2 -> 1.9 in 7z 😆

> The images are non-photographic so yes, there should be higher redundancy. That explains it

I have experienced the same thing this guy is experiencing.

A bunch of large JPEGs in a 7z package is much much smaller than converting them to jxl

7z is able to crunch multiple jpeg files well

The only thing that doesn't make sense is saying that it was faster. Lzma is super slow

7z is not able to do the same to multiple similar jxl files

I got butter on gpu 👀

https://github.com/Line-fr/Vship

a rather broad category. even excluding content which typically aligns with photo performance (digital_painting, 3d, machine_learning, texture) it's still the general incantation e10E4I100g3, excluding e11, producing lowest mean bpp. (this backed by e.g. one test of 3840 commands against 1051 8-bpc images requiring 137 different commands to minimize at 4% smaller)

I didn't know lossless webp was that good

I'll have to look into that later, I wonder if it's the format that gives it an edge or if it just has a particularly good encoder

IIRC JXL has all the features Lossless WebP does, the encoder just hasn't been fully ported over yet

lossless lossless webp transcoding when

are they really that similar?

Mostly, there are a few key differences as mentioned here: https://discord.com/channels/794206087879852103/822105409312653333/1300197653136670814 But a lot can be copied over from WebP

Both lossless modes were spearheaded by Jyrki

Main difference I can think of is JXL using groups, so long repetitions can't be caught by the encoder as well, but that's a place for patches anyway. Jyrki mentioning encoder tuning https://discord.com/channels/794206087879852103/794206170445119489/1292778172265533441 and Jon discussing differences https://discord.com/channels/794206087879852103/794206087879852106/1247119135855611944

"we just haven't build a great encoder for lossless" and it's already so good 👀

It may not always beat WebP in size, but in my experience it's always far for efficent in both time and memory

It decodes faster and is competitive with JXl at very small image sizes

Although I have only tested this for lossless

Also competitive in filesizes

Decode speed was about equal for me, or around 50% faster at effort 1 and 2 naturally. Both lossless

Would be nice to optimise the fixed MA trees in there...

I used cwebp at max compression and cjxl at e7, but webp still decodes faster for me. Depending on the "benchmark" (nomacs, ffmpeg with -benchmark), WebP decodes around twice as fast

What resolution if you recall?

very small resolution, I retested again just now. up to 128x128

WebP is around as fast as PNG while being a good bit smaller, around 40%

Ah, yeah. My latest image was 7500 x 7500, so the group decoding would've been multithreaded

E1 would be more conducive for thumbnails I think, but at that point it is handily beaten by WebP, while still being slower to decode, at least according to my aforementioned "benchmarks"

Jyrki hit a home run when building the lossless webp encoder. A similar thing could be achieved with jxl but hasn't yet

`-e 10 -E 4 -I 100 -g 3` Is this correct?

Do note that g3 will sometimes be larger than 0 to 2

What kind of images would sometimes let this happen?

It depends, I myself have not conducted any real tests regarding this, I just noticed it when testing parameters

By the way, I'm planning to experiment copying PNG birth time (no Exif) to JXL as `DateTimeOriginal` and `CreateDate` of Exif. Is that a proper behaviour?

does anyone know if its possible to add jxl as covers for audio files? ‍​​‌‍

i recall seeing foobar and another app reading jxl images as sidefiles (meaning not integrated inside music files, but as .jxl images of the usual common names for those, located in the same folder)

jxl would be excellent for future revisions of audio metadata but the market has been shifting away from that in favour of keeping covers separate so theyre easier to manage by providers/apps

that also gets around market inertia and unfavorable changes in specs. audio services can serve covers in any format they wish to browsers and especially their own apps

I also wonder if that's more recommended than `-e 11 --allow_expert_options`

the real question is what if you convert them to JXL and *then* compress with LZMA? <:galaxybrain:821831336372338729>

both e10 and e11 are super compute inefficient, e11 being much worse. I wouldn't recommend either for practical scenarios. as far as answering the question of a single command to get the smallest size the encoder offers, that would be e11 by a few percent

it is not so significant or differentiating ``` unique mins bpp (mean) | included in 'all' B | mins | | best of 24757629 2.589999 ···· ···· · all 24817297 2.592913 96.09% 17.64% A cjxl_0.10.2-d_d0e10E4I100g3 25018605 2.598436 82.36% 3.91% A cjxl_0.10.2-d_d0e10E4I100g2``` these are more complementary ``` unique mins bpp (mean) | included in 'all' B | mins | | best of 24503705 2.559757 ···· ···· · all 24817297 2.592913 73.01% 72.70% A cjxl_0.10.2-d_d0e10E4I100g3 35807963 3.501005 27.30% 26.99% A cjxl_0.10.2-d_d0e10P0E4I0g3X0patches0```

What does your testing corpus consist of?

this is the roughly non-photo or similarly performing content

generally small images in this case since I ran thousands of combinations of settings

I want to do only for my personally owned works

To try `-e 10 -E 4 -I 100 -g 3` instead if that's the more efficient option

`-e 11` may take days to finish one artwork

Worse than jpeg+lzma

Less redundancy across files

Sad face

i'm guessing that'd be because of adaptive quantization introducing more possible variance

I bet lossless jpeg transcoding would still lz77 about the same, it'd be interesting to test

depends on how many threads you can dedicate. e11 does three stages of encodes: 2 to differentiate content, then either 20 or 24 based on the outcome, then the final encode with the densest settings. So, you could expect it to take roughly 3x longer than e10 minimum for single images, with opportunity to parallelize more with multiple instances of the encoder across multiple files.

The jpeg transcoding introduces Chroma From Luma, Arithmetic encoding (IIRC) and other tools that could mess with the 8x8 blocks that 7z tote so well

At one point I tested archiving VNs transcoding JPEG to JXL before general compression and usually the JXL version was smaller, but in some cases it was much larger.

Good this is not that long process

Saving additional 10% to 15% from default (-e 7) is quite impressive

Even more efficient than ZopfliPNG for me