JPEG XL

In the long run I think the avif format has a lot less potential.

why do they still want to keep their JPEGs and PNGs, do they like having a full hard drive?

JPEG XL's bitstream has more oppertunities for expansion

also AVIF is fundamentally burdened by being a video delivery format first and foremost

avif has a lot of disadvantages that in my opinion outweigh this, and a lot less potential for future improvement imo as well. But the fact is, as of right now, avif can make your images smaller while at the same time looking better than jxl at the same bitrate.

At least, in my experience.

In the long run jxl has a lot more advantages and potential though.

i guess it's the whole "appeal" vs "fidelity" thing

and avif is not designed for the future at all. Just like webp, it's thoughtless and sloppy

a friend and I discovered that AVIF ends up tinting images red or green (commonly red) with the only found solution to encode AVIFs as 10-bit even if it's 8-bit content

It's just video frames in an MP4 container

which is worse, HEIC or AVIF?

It's the same thing.

not quite

HEIF is the base format

HEIC is HEVC in HEIF

AVIF is AV1 in HEIF

you can use libheif for them all

it's like asking me what's worse, jxl modular or jxl vardct

libheif needs bindings with the other formats

``` > heif-dec --list-decoders HEIC decoders: - libde265 = libde265 HEVC decoder, version 1.0.15 VVIC decoders: AVIF decoders: - aom = AOMedia Project AV1 Decoder 3.9.1 <snip> ```

sure, you need a codec library for whatever codec you're using

worse is "lots of hardware supports avif!" shilling boys, av1 support doesnt bring avif or get avif accelerated at all. almost nothing uses hardware decoders for images due to latency

heif is mostly a single frame of hevc. when used for lossy compression, it discards less detail than jpg

yeah, avif decoding is done by a separate library...

uh maybe y'all should make a thread or move to https://discord.com/channels/794206087879852103/805176455658733570 ?

and usually using dav1d

This is kind of important in coverage though too. One of the reasons I was pushing for a new site was that we don't do a good job of marketing JXL as a solution. If anyone feels like writing an article or something about the issues with other options, this makes great content…

We will see if Apple wants to do that marketing next month

Common misconceptions: "JPEG XL's spec is being sold" -> "JPEG XL is proprietary / non-free" "rANS may have been patented by Microsoft" -> "JPEG XL is owned by Microsoft" "AVIF is sometimes better than JPEG XL, notably for lower quality image" -> "JPEG XL is useless crud, we all should adopt AVIF" "JPEG XL is still new, so there isn't that much support" -> "nOT eNoUGh iNTeResT fRoM thE EcOSySteM"

the last one is specifically targeted towards Google's Chrome Codec team

people also seem to deny the support that is there

I’ve seen this with webp, with some people claiming they haven’t seen any non-browser app support webp

they clearly haven’t been paying attention

Does the default windows gallery support webp nowadays?

Because that is what most people are using lol

MacOS supports it natively

So does any competent system made after 2018

Yes, but we are talking about Windows here lmao

yes, added last year to Windows 11

Nice. What about AVIF?

Both WebP and AVIF assuming you download the media packs from the store, but the imlementations are pretty damn slow...

Clip Studio Paint finally supports WebP since version 3. It may support JPEG XL after 2035

I don't know who the hell spread "JPEG-XL" from the beginning

And then every other media who copied that all used it

I just call it JXL most of the time

Never 'jpeg xl'

Well “image.jpeg xl” is a bit wordy

lossy jxl has a bad reputation especially in the anime community, I think every new release of libjxl should make a conscious point of highlighting any lossy quality improvements, with before-and-after pictures if possible even, to raise awareness that the codec is continually improving and the fidelity is getting better and the problems are getting fixed with smudging and color distortion.

For something like anime, wouldn’t lossy modular work better?

That way it also gets picked up by tech news reporting on the update. If quality improvements are highlighted front and center in the release notes of every major release that is what the news outlets will report on.

That sounds like a good idea

More positive media the better

of course modular is better for anime, but by default libjxl only uses modular for things like patches and DC I think.

Well they go insane with AV1 options, maybe there should be some kind of document explaining the best options for different images

Maybe the people from <#840831132009365514> can help

doubt. jxl as a format covers so much niceties i instead expect their inhouse format will switch to being jxl-based at some point. jxl itself is also ideal for webtoon-type comics (either sides can be reaaly long and it does progressive from at least top blocks to bottom if specific regions arent focused on first for decoding - ideal kind of lazyloading for such images)

"JPEG XL" is the full name, but often spaces are inconvenient and shorter names are nicer, so then JXL or jxl works better. The IANA media type is `image/jxl` and the recommended filename extension is `.jxl` because having spaces or long strings for those things is not a good idea. It's a bit like "JPEG 2000" and J2K or j2k (except there they made it a bit messy with `jp2` and `jpx` and `j2k`).

yeah, and jp2 sounds more like “JPEG 2” than “JPEG 2000”

should the next format be called JPEG XL 3000? 🤔

> JPEG XL 3000 ... Pro Max when impemented by Apple

I'm waiting for JPEG Ultra

The problem with JXL's niceties is that it winds up significantly reducing its appeal to lite-dependency programs. PNG retained its stronghold by being lossless by design and being easy to roll out custom implementations for decoding easily.

JPEG XL is not very likely to break that stronghold for once.

J2K *is* kind of JPEG 2, in the sense that it was the second major codec by the JPEG committee.

is JPEG XL kinda JPEG 4? XR would probably be JPEG 3, XT is kinda JPEG 1 rev. 2 and XS is it's own thing entirely (JPEG - LD (Low anyone?)

or in USB speech, JPEG 1 is JPEG 1.1 Gen 1 and JPEG XT is Jpeg 1.1 Gen 2

Please not the USB nomenclature smh xd

Oh, please, no, do not start this USB versioning 🤦‍♂️ USB 3.0 rev 2, USB 3.1, etc

Only the SD naming could be worse than USB

JPEG XL is now JPEG 2.4 Gen 4x8 Rev. 2.1

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

who doesn't love some terrible naming conventions

XC UHS-1 V30

Tech companies certainly do lmao

me when C10 V10 U1

they're EXACTLY THE SAME THING

arghh

Instead of 2 (3) clear numbers that immediately tells everything about card speed

after all why not? why don't we need ~~3~~ 4 (5?) different ways of indicating speed

SD express 4.0 x2 have a max of 3,938 MB/s

why not just an SSD at this point

They are connected via PCIe

i know

Not the SSDs I mean, but the memory cards

that's what the "express" means

Some guy on DPreview.com connected an 8TB nvme ssd to his camera lol

i'm saying if the SD card is connecting over PCIe, why not just use an SSD

i would prefer that over an 8tb microSD-UC Express

Software RAID in cameras when?

nah, im putting 4 sd cards in my camera and RAID 5 ing them

RAID0 or bust

imagine a RAID 0 of 128 drives

no erasure coding, nothing

just pure raid 0

Who needs data security anyways

i bet the ssd is faster, more reliable, and in general better

The portable Sandisks on the right have a rather high failure rate it seems

umm, i have one

uhh

Same lol

lemme go run a backup

JPEG XL with 3000 Xs

also fine take a samsung

JPEG XXL

JPEG's official merchandise sizes: XS and XL

just use a raid 6, PLEASE

the 25% storage capacity downgrade is so much better

or some other thing idk storage best practice

i just have my computer backup to raid1 NAS and cloud

raid1 nas has 2 drives

If it doesn't make your heart beat at unhealthy speeds every time you think about it then I don't want it <:kekw:808717074305122316>

i have a bunch of old USB sticks

just slap them into a RAID 0

That's my GPU currently, fan bearing is shot so if it goes above idle it vibrates my computer apart

like a pack of 5 8gb from 5 years ago

LTT once made a video about MicroSD card RAID lol

i think i remember that

Was (very obviously) not viable lmao

imagine the failure rate

swapping cards every few days i would imagine

SMART is overrated anyways, no one needs that for SD cards, for sure

why is it called SMART? it pretty DUMB

LMAO GOTTEM

trueeeeeeeeeee

I had around 800 2GB usb sticks at my disposal once, but those thing literally had a 30% of not working straight out of the box

im getting ChatGPT to write the worst possible backup plan

just to see what happens

Encode your data in QR codes as stickers and slap them redundantly in multiple places in your city lmao

Encrypted of course, wouldn't want random people to get your data [BigBrain](https://cdn.discordapp.com/emojis/615775892177944627.webp?size=128&quality=lossless&name=BigBrain)

Raid 0 QR code storage

Certainly! Here's a single paragraph that combines all the worst practices into one epic disaster of a backup plan: In the ultimate terrible backup setup, your primary data and sole backup are stored on the same aging, unreliable hard drive, which you never replace or upgrade. The backup is additionally recorded on a worn-out floppy disk, left openly on your desk, and uploaded to a public cloud service without encryption. The backup process is managed manually every five years, using a drag-and-drop method that often misses important files and overwrites data. You also back up files while they’re actively being edited, leading to corrupted and incomplete backups. Neither the hard drive nor the floppy disk is protected by a UPS, so power outages or surges risk data corruption. The floppy disk is further outdated by being accompanied by a VHS tape backup that you can’t even access due to a lack of a working VHS player. No checks or verifications are performed on any of the backups, and the setup is vulnerable to malware because the backup program doesn’t scan for viruses, meaning any infection on your primary system is copied to the backup. To top it all off, only the most recent versions of files are kept, erasing all previous versions and making it impossible to recover older data. Everything is stored in the same open drawer, exposing it to physical damage, theft, or spills.

in all seriousness i have my master password on a laminated QR code somewhere that i'm not saying for obvious reasons

But anyway, maybe a bit <#806898911091753051>

yeah

yeah

everyone to <#806898911091753051>

I still don't actually know who came up with the name JPEG XL originally. I think it was just an "engineer joke" to contrast with JPEG XS, where the S is for Speed but also for Small in the sense of "low circuit complexity" and "simple" (i.e. sacrificing compression and features for latency/speed), while JPEG XL would be allowed to be a "big" codec with many coding tools and features and the best possible complexity. But people have also told me the L is for "long-term", as in "a successor for JPEG 1 that will last another 30+ years". Fact is that the name was already there before there was a call for proposals and before I got involved.

I mean if <@162416815530704896> feels like making a follow-up with new info that we can provide, like the patches and splines, JXL art, mixed lossless/lossy images based on content, ect then going through the various meanings of the name could be something to talk about

what's the software I should use to convert JPEG's to JXL's and back again

and which best represents JXL's compression capabilities?>!?!?!?!?

Currently that would be cjxl from the Github https://github.com/libjxl/libjxl/releases/tag/v0.10.3

Although there should be a 0.11 release when people are back from holidays

cjxl is just the encoder so you would need *both* cjxl and djxl to convert between JPEG and JXL, also they are CLI based tools but if you fancy a GUI there is this https://github.com/kampidh/jxl-batch-converter

The issue with most software like photoshop, ect is that they decode the jpegs to pixels, when for the direct transcode, JXL needs the raw jpeg data instead

what's the best way of viewing jpegxl files in windows?

in what form? like what software opens/renders them the best or what integrates the best with Windows?

ill go make a quick list of some options

iirc irfanview on windows has a jxl plugin

- [jxl-winthumb](https://github.com/saschanaz/jxl-winthumb): a WIC codec for Windows which makes any software that loads system installed third party WIC codecs receive JXL viewing/opening support such as the classic Windows Photo Viewer (the modern app refuses to load other WIC codecs so that doesn't work and sadly the classic viewer suffers from some weird issue of making dark areas that look fine in other JXL software look bad). - [JPEGView](https://github.com/sylikc/jpegview): a image viewer with support for a bunch of image formats including JXL. note you might have to enable `UseEmbeddedColorProfiles` or something in the .ini for stuff to look correct. - [Thorium](https://thorium.rocks/): This is a fork of Chromium with JXL support fully restored and it's your best bet for viewing JXL files (especially HDR ones) if you don't care about opening a whole browser just to view images.

feel free to ask any other questions!

<https://www.irfanview.com/> Although color management isn't enabled by default either, so you'd probably want to check that in the settings

It does not work if jxl is in anything but srgb. For avif's it works even worse, though

nomacs for Windows has jxl support I believe

xnviewmp. enable color management, associate files and youre set. usable for exporting too (jxl library soon to be updated for big gains)

https://imageglass.org/ is nice photo viewer

Accidental Tech Podcast just did a whole section on JPEG XL: https://atp.fm For those of you not Apple fans, this is probably the most influential podcast on the subject… I have some connections so I'll see if I can follow up with them.

Timestamp?

1h02m30s is where the bit on jxl starts, I just found it 🙂

Thanks

https://www.cultofmac.com/news/jpeg-xl-iphone-new-photo-format-explained Kinda nonstandard to say Apple added support in the camera app when it’s just a Rumour

It would be quite nice if JXL replaced HEIF, this format is barely supported outside of MacOS

Safari even wasn't able to open .heic until version 17

It is/was essentially a DOA format with no adoption, which hasn't changed in the last few years

Most Android phones support it

While that may be the case, where are you going to get an HEIF image from? They have no presence in the web and Android camera apps do not produce HEIF. And iPhones (correct me if I'm worng here) automatically converts heic to jpg if sent over a messenger, while bluetooth does not work at all for sending from iOS to Android.

I just had a look at some heic files from an iPhone and it seems the iPhone exclusively produces yuvj420 heic files?

Samsung's camera app can save HEIF files

Huh, you are right. I never noticed because I exclusively shoot in pro mode, where heif is not supported

https://formulae.brew.sh/formula/libheif <:PepeOK:805388754545934396>

Hearing them say "It needs to get on MacOS" having already been added for a year hurt a little. Maybe we should look into restructuring the Wikipedia page. Moving the Apple support into the history section where the Chrome removal is listed

Some interesting options in libheif ``` -A, --avif encode as AVIF (not needed if output filename with .avif suffix is provided) --vvc encode as VVC (experimental) --jpeg encode as JPEG --jpeg2000 encode as JPEG 2000 (experimental) --htj2k encode as High Throughput JPEG 2000 (experimental) ```

When I transfer files via cloud storage because I insist on the highest quality, I'm pretty thankful that Google Photos can load HEIF files from iOS, though it is a bit slow to process.

Hope this pushes Android into supporting JXL as well

it's google so im not holding my breath personally

start reporting issues to your phone manufacturers that you can't view the images your family and friends are sending you

decoding jxl is a safe feature to add for preinstalled phone gallery apps

Just a tweet, but it's something https://x.com/t3dotgg/status/1829361633614840168

Comments are more interesting

Just found that's a 10-bit image

Probably helps with the internal gradients being more smooth

“AVIF might be even tinier”

Also that guy saying “WRONG” when they downloaded it as a PNG

Clown fr

Because we all know PNG has an equally powerful MA predictive tree

Sometimes it feels like reading Twitter comments is the best way to speedrun losing brain cells

Mainly because these people have no idea what they’re actually talking about

“that can't be true because i screenshotted the image and its definitely more than 34 bytes”

I think that one's meant to be a joke <:KekDog:884736660376535040>

Unfortunately Squoosh can't decode that JXL

Also this guy has never ever heard of the term “procedural generation”

Oops

Oh it can still be opened correctly

MacOS crapping it’s pants with AVIF?

djxl generated a 16-bit PNG, and avifenc generated a 12-bit AVIF from it

Funny that heif-enc turned it back to 10-bit

Does HEIC support 12 bit?

iirc HEIC only goes up to 10 bit

I meant from 16-bit PNG to 10-bit HEIC

yes

Technically, it's a bit ambiguous what exactly "HEIC" means

The file extension .heic and media type image/heic can be either the heic brand or the heix brand.

The heic brand is only 8-bit 4:2:0. The heix brand can go up to 16-bit 4:4:4.

I don't think Apple devices support the heix brand though. I think they're restricted to the heic brand.

but everyone calls the format HEIF anyway

which technically encompasses AVIF

What does that "any" mean?

any means any

~~dump whatever cursed format you want into it~~

HEIF can contain hevc, but also h264, jpeg, JPEG 2000, AV1, etc.

\> vp9 heif

[av1_monkastop](https://cdn.discordapp.com/emojis/720662879367332001.webp?size=48&quality=lossless&name=av1_monkastop)

a truly cursed combo

I have on a few occasions had to decline the proposal to define a jxl payload for HEIF. It would be a silly extra container with no new functionality, so it would be pointless, and it would just add confusion.

why is the format called "C" and the container called "F"? :(

I suspect they consider the container the “format”, and then “C” for “codec”

I always assumed the C came from hevC

That’s what I thought as well

JXL disguised as .heic looks innovative

Well it would be .heif, or maybe .heixl or whatever. Anyway, it's a bad idea.

this ought to be classified as a crime against humanity

sounds like something Apple would do

`.hexl`?

Would HEIF be a good way for a phone to store multiple versions of the same file? Like when you crop/edit an image and you have the option to revert edits.

Is that a valid use of HEIF container on JXL?

You can in principle do reversible cropping in jxl directly too, by just manipulating the headers.

Or storing the original as an extra layer. Although that reminded me of the idea of adding disable options to djxl, for things like ISO noise, so you can get the clean pixels back out

is ISO noise deterministic or random?

as in does it decode the same each time?

that's a philosophical question

to decode or not to decode

that is the question

theoretically it's deterministic as defined in the spec

it uses pseudo RNG and its state is encoded in the bitstream

That makes sense

So the whole decode process is deterministic?

As in the same JXL will always decode to the same ppm/whatever?

it's allowed to have slightly different decoded images within error margin defined by the spec, but basically yes

So excluding floating point nonsense, it’s the same, also is this only for VarDCT?

yeah, lossless should be lossless

What about lossy modular?

Or is that still considered “lossless”

Not exactly. Let's say you store edits on a separate layer, or crop certain layers. Is there a way to mark/distinguish those changes as "post-edits" that make sense to change/revert/remove, rather than image coding tools that form an essential part of the image (like patches etc)

Maybe as another box?

<:JXL:805850130203934781> 📦

There would have to be a way to distinguish post-editing from essential image data in order for the edits to be reverted, and I think it would be ambiguous since the format encourages the use of image decomposition with splines, patches, modular layers, etc

Is there any room in the code stream for extra signalling?

If so , you could tag a layer as “finalised original” and all edits on top could be patches or something

Or have some kind of edit list in the metadata

Unless there's a better way, there's always a vendor specific box for designating optional image data and un-cropping instructions

It's called the whatever-you-feel-like vendor box

Only thing with vendor specific is that it’s not standardised

Are there no clipping bounds defined in the codestreams?

Layers can have names, I guess you could use a naming convention to distinguish "post-edit" layers

There are the image dimensions in the image header, and then there is the frame dimension and crop offset defined in the frame header (by default the same as the image dimensions and no offset). You can keep the frame data intact and do a crop by changing the image header and the crop offset.

... Wdym? Is it not actually "High Efficiency Image Codec"? I swear I saw that in a few articles...

https://youtu.be/pFNmS_HZ2Zs?si=QbN6q9Yt-qSMahAB

Umm what

So guys modular mode has been snapped of the face of the earth I’m afraid

Phew someone corrected him

thanos why [pepehands](https://cdn.discordapp.com/emojis/1075509930502664302.webp?size=48&quality=lossless&name=pepehands) this is not the balance we needed

A lot of hot takes in general

He might wanna get that amnesia checked out

His whole argument is “JPEG XL uses too much CPU”

Skipped to the end to see his full comparison

Would've at least given it some dashes instead of crosses

Also JPEG XL is not just for web delivery

he also falls into the trap of thinking Google is a hivemind

bro is just like me and testing JXL on a 2000 era dual core 1ghz netbook

I should go dig up the results of that again

The funny thing is, as I try to fullscreen the video, the AV1 decoding is so CPU intensive that it takes a few seconds for the UI to load

Also I bet the CPU behind all the crap bloat websites have probably outweighs the CPU cost of any image format

He seems to understand the mistakes he's making, but puts no effort into correcting them. As he puts SVG as an entry he says "This one's gonna be kinda weird to put in..."

Vector vs raster is such an apples to oranges thing to do

I watched the majority of the video (start to end at 1.5x speed while skipping forward) and it's pretty much just him just making assumptions about a bunch of stuff while reading off of articles and comments

Also not quite actually understanding the tech

the video started off strong with him stating that AVIF is awful or something and then the rest is just a edited down livestream that feels like it goes nowhere

Also JPEG XL has —faster_decoding

If that’s such a big problem

(But it’s not really)

It's a livestream made to look professional, so you belive the facts when they're actually just comments and ideas

> Theo - t3.gg Oh this person... His whole job is having uninformed tech takes

lossy

lossy PNG is kind of a made up thing though

only by interpretation

Lossy PNG is more like near lossless WebP IIRC

it can be as lossy as you want

as in, throw out as much data as you want before losslessly encoding the remaining data

Some non-technical people use the word "compression" for "introduces artifacts". I guess they might be thinking of electric guitar effect pedals.

I had to stop watching this video. First part is OK, but when he goes to the codec benchmarks done by the AVIF team (which are flawed to begin with already) and then adds a solid dose of extra confusion and misinterpretation to those already-flawed plots, it got too cringe for me to keep watching.

don't you want to partner with a famous youtuber and brief him BEFORE he make the video instead of after 😄

It's kind of nuts how he is just assuming that jxl decoding comes at a huge CPU cost just because the compression rate of jxl art is insane so the amount of work the decoder has to do per compressed byte must be enormous.

If you want to make decode speed the main point of criticism, then at least do a proper speed benchmark. Then you'll see that for web images, basically jpeg, webp, avif and jxl all decode fast enough even on relatively old hardware - even old phones can easily decode a few screenfulls of image data in the blink of an eye, in any of those formats. It's just not a big issue.

dynamic range compression?

If famous youtuber does not bother understanding what he is talking about, I believe it is not worth it

so yeah, technically JPEG XL does use "more CPU" but in the grand scheme of things, a few million extra calculations on multi-gigaherz + multicore + pipelineing CPUs really means nothing, oh no my image took 53 microseconds longer

famous youtuber loves making hot takes without understanding them

Putting an X at "Performant (CPU wise)" for jxl is the only major problem I have with this diagram. That and making all the fields just binary, which doesn't really help. I would say general software support for jxl is not that bad, all things considered, and for lossless and lossy compression you can bring a lot more nuance if you don't just consider them boolean things that a codec can either do or not.

like yes, JPEG and AVIF can both do "compression"

what the heck is that meant to mean though

It is his own choice, but it also forces me to ignore him 🤷‍♂️

you ignore him but many don't and the information spread (even if biased of false) will be spread farther and faster than any truth... that's why we could/should preemptively communicate at large scale

JPEG XL doesn't need more anti-jxl media, google's doing enough of that

it's not only lossless, but I removed the noise as well!

You can use a subset of jxl (say, effort 3 vardct) that has the exact same computational complexity as jpeg, except it can be decoded with multithreading. Of course you can also use fancier coding tools and make a jxl that will require more CPU to decode than jpeg, but it will be hard to get cjxl to create a vardct image that fits on your screen and takes a noticeable time to decode.

im guessing there is no `--slower_decode` option

as that would just be dumb

You can do lossless at high effort with -E 3 -g 3, that will be about as slow as it gets and that can get in the range where it takes a full second to decode a screenfull of image. But just don't put something like that on your webpage.

Did a quick and dirty speed comparison (just one image, similar quality across codecs, default encode settings): https://docs.google.com/spreadsheets/d/1U4VZzbLQJuEa4iRk52pFLkWnBIRlUIQw7paBQNjq-RU/edit?usp=sharing

is this MPx / s

yes

eh while "JPEG-XL" *technically* isn't correct I believe it is the least of our worries

fair

This is on my laptop — on a phone it will be slower of course, on a desktop machine it will be faster. Point is: for web images all these codecs are fast enough, and if you're going to say "webp > jxl" because the decode speed of webp is better, then that's a pretty misleading if not just wrong thing to say. Yes, single-thread webp decode is somewhat faster than single-core jxl decode. The difference doesn't matter in practice though. And when using more than one thread, jxl is faster to decode than the other new codecs — and can get even faster than progressive jpeg, if you throw in enough threads. Even low-end phones and budget laptops have 6 or 8 cores nowadays so talking about decode speed without looking at parallelization potential really doesn't make sense anymore.

this particular youtuber doesn't bother to understand *anything* he talks about

on phones it might be better to figure out MPix/joule

https://x.com/jonsneyers/status/1830900176430477407

I guess if you do that, you should also include the energy required for transfer, as well as energy wasted by the user waiting for an image to load to make a navigation decision (e.g. a progressive preview could be help to make a navigation decision 0.1 seconds earlier, which means 0.1 seconds of powering the display can be saved, etc). As Jyrki likes to put it, human time >> screen > radio (transfer) > cpu, i.e. it is a bit silly to zoom in on just the energy going to cpu without looking at the things that are more costly/valuable.

I have a rooted axon 7 if someone wanted to do tests on it [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol) the battery on it is shot tho

I wonder if I could hook up my old Samsung to an external power supply with a high speed power meter

It also has a shot battery, but crucually, it's from before the era where they started gluing phones shut, so I can get at the power pins in the battery compartment.

bench power supplies can often track usage over time,

but yeah it's pretty easy, just need to do the sense pin

making the argument that WebP is better than JPEG XL right now is very easy, though at a features level WebP is clearly amazingly inferior

still hate that non-replaceable batteries are THE standard now...

I don't really care one way or the other since I have the tools, I just don't want to buy a replacement battery for it, could be nice for testing stuff like jxl tho

If you factor in browser support, then of course webp is better than jxl, since "works anywhere" is obviously better than "works only in safari". That's the only argument in favor of webp though, imo. Well, maybe also speed of 8-bit lossless, where webp can still be on the Pareto front at least for some types of image content. But I don't think it won't take long before the limitation to 8-bit becomes too much of a limitation, at some point it will be considered as "lossless" as GIF...

oh maan the number of gifs i've seen with flickery colors, it's too much

oh I need to test the 0.10 series libjxl on my netbook, i forgot about that

"256 colors ought to be enough for everyone" :P

even with modern tools like [gifski](https://gif.ski/) it still is not comparable to modern formats. Gifski does produce nice*r* looking GIFs though

and all the other ones where it's complete banding city

that's the one i use

i keep forgetting about that one, thx

I have seen pixel art artists that only use a dozen colours or so, making GIF viable for them [BigBrain](https://cdn.discordapp.com/emojis/615775892177944627.webp?size=128&quality=lossless&name=BigBrain)

xd they might actually not save much more space by using PNG due to the header size... idk

Ah sorry, I meant for animations xd

ah! yeah ig that works fine. low-palette stuff can still benefit from APNG but GIF is widely supported sooo...

ImageMagick uses palettes when converting to GIF by default while ffmpeg hast to be given many parameters. If done right ffmpeg's output does look better than ImageMagicks though

At least from my limited testing

mostly comes down to using palettegen creating a new palette for every frame iirc

makes filesize HUGE though

i've taken to using imagemagick for gifs as of late and it's been pretty nice

It works well enough, yes

Pixel peeping required, but ffmpeg's output with palette has less banding than IM

ffmpeg without palette is hideous

indeed

its just treating it as rgb8 i think

fixed palette

Most programs nowadays thankfully use palettes, but some pixel art I've seen gets absolutely butchered, probably due to old programs being used by artists

oh, maybe imagemagick is not using local colormaps as i thought? that's a lot of banding

It still looks completely fine at 100%, but pixel peeping shows the difference

pixel art as gif with fixed palette and floyd-steinberg diffusion :P

ffmpeg may be using better dithering

If you want to create this comparison yourself: ``` palette="./palette.png" ffmpeg -i FFmpeg_Logo_original.png FFmpeg_Logo_default.gif ffmpeg -i FFmpeg_Logo_original.png -vf "palettegen" -y $palette ffmpeg -i FFmpeg_Logo_original.png -vf "scale=-1:-1:flags=lanczos,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" -y FFmpeg_Logo_proper.gif magick FFmpeg_Logo_original.png FFmpeg_Logo_magick.gif magick FFmpeg_Logo_magick.gif -background white -gravity north -splice 0x60 -fill black -pointsize 48 -font Impact -gravity north -annotate +0+0 "ImageMagick" FFmpeg_Logo_magick_v2.png magick FFmpeg_Logo_proper.gif -background white -gravity north -splice 0x60 -fill black -pointsize 48 -font Impact -gravity north -annotate +0+0 "FFmpeg with palette" FFmpeg_Logo_proper_v2.png magick FFmpeg_Logo_default.gif -background white -gravity north -splice 0x60 -fill black -pointsize 48 -font Impact -gravity north -annotate +0+0 "FFmpeg without palette" FFmpeg_Logo_default_v2.png magick FFmpeg_Logo_original.png -background white -gravity north -splice 0x60 -fill black -pointsize 48 -font Impact -gravity north -annotate +0+0 "Original" FFmpeg_Logo_original_v2.png montage FFmpeg_Logo_original_v2.png FFmpeg_Logo_magick_v2.png FFmpeg_Logo_default_v2.png FFmpeg_Logo_proper_v2.png -background None -tile 2x2 -geometry +0+0 FFmpeg_Comparison.png ```

You just need to download FFmpeg_Logo_original.png lol

I tried to look into the article where he was getting the idea that AVIF is faster then JXL and it's an article from the AVIF team where in the same article they also claim that libaom is faster then SVT-AV1 and are doing their testing by forcing 96 threads on a 32 core server CPU https://web.dev/articles/avif-updates-2023

like I'm not going crazy this article is completely insane right?‽ like isn't SVT-AV1 widely recognized to be faster then libaom even back in 2023? and correct me if I'm wrong but isn't forcing 96 threads on a 32 core CPU like not make any sense??

`Test set: Kodak (24 images of 768x512)`

theyll try and lie using specially picked files until the results fit the wishlisted conclusion that was decided in advance. shameful given how harmful unintended avif adoption would be for websites and webhosts (even cloudflare generates webp instead of avif at sizes higher than 1-2 megapixels due to the ressource consumption)

about that youtuber video's chart, adding to chromium pushes it 70% overnight and with safari to almost 90%. if jxl stayed in chromium the derivatives wouldve had it enabled for sure since the upkeep cost would be shared at upstream. still, even 98% support wont mean anyone use whatever's pushed by the folks gatekeeping the monoculture

You reminded me, I was going to check if there's been much of a decoding speed increases across releases

wow, I didn't know that. named layers... That's pretty useful. It's like it's designed for image editors... I assume there must be a limit on the number of layers to prevent making a DoS bomb, or some complexity limit of some kind. Otherwise, you could even store undo history by putting each change in a separate named layer...

That article makes little sense in general. That chart of encoding speeds is as useless and confusing as a chart can get. Yes, when doing multithreaded s9 avif encoding it is slightly faster than jxl, webp or mozjpeg encoding — so what? With that setting it also compresses worse than libjpeg-turbo, while still being a lot slower. So why would anyone bother with that? Also default effort cjxl is basically as good as slowest-setting cjxl (for lossy), while there is a substantial gap in compression performance between s6 and s0 avif encoding. Comparing encode speed in isolation from compression performance is kind of ridiculous.

And the image crop vs frame crop thing seems useful too. Maybe there's some corner case that I can't think of right now where it might be ambiguous... but otherwise, I can totally see that working as a way to revert a crop on a phone gallery app.

There are limits in the profiles and levels on the number of pixels that effectively need to be decoded per rendered frame — not really a limit on the number of layers (you can have some number of full-sized layers or a larger number of smaller layers)

We did design jxl for a broad range of use cases, not just web delivery (like webp and avif, which were basically designed by browser devs). Getting a good compressed format for authoring workflows, something that can replace TIFF basically, and that can be used as an interoperable subset of PSD/XCF/etc (image editor internal formats), was one of the goals. Web delivery was always the primary use case, but photography and image authoring were also big ones.

How would vector layers work? Would they just be rasterised

TIFF is really useful for multi page scans where each page can be a different size and dimensions... I don't entirely understand how good jxl is at that kinda thing.

jxl doesn't have vector layers.

it's a raster format.

I know

That’s why I’m asking

Most raster graphics editors don't have vector layers either.

Smart objects?

Few days ago I saw a question on one tech forum, asking how to split such tiffs, because PS does not understand it, and IrfanView reduces 16 bpc to 8 bpc. So I doubt multipage tiff is __really__ useful

I'm more worried about the possibility that, for imageboards and other servers, a maliciously crafted file designed to take a near-infinite amount of time to decode or process is a common concern... Ideally, there should be a very easy way to set time/CPU/memory allocation limits when initializing the decoder/encoder, to make secure handling of jxl files easy for people so that the library (or worse the format) doesn't get a reputation for bringing servers to their knees.

Anything fancy like layers with text or vector graphics, or layer effects, or any of the funkier Photoshop stuff would have to go in some proprietary boxes that get ignored by normal jxl decoders — the main jxl file would just contain rasterized layers.

Yeah, non-raster stuff ought to be kept out of a jxl file or it's no longer a decodeable jxl file.

splines are considered to be raster still, too, right?

So maybe Affinity could replace the internal storage format from PNG to JXL but keep everything else the same?

As in the container .afphoto format

And the layer names I guess could store a GUID that points to data in the external box?

And supporting software can see that and relink the information

That's why we defined Level 5: it has limits on the number of layers / channels / splines etc to keep the decode effort per pixel reasonable. E.g. on the web it would be reasonable for a browser to reject jxl files that don't conform to Level 5.

As long as it's easy to enable that protection in libjxl when initializing an encoder/decoder instance

Layer names are allowed to be up to 1 kb large (1071 bytes is the maximum allowed by the frame header syntax), which should be plenty for some naming convention that includes whatever you need. It should even be enough room to store things like font details+text to store simple text layers in a way that allows an editor like Gimp or Photoshop to make it editable.

Does it have to be UTF-8?

Or can it be arbitrary bytes

As long as libjxl provides an easy way to enable protection from maliciously crafted files, no one can get angry at libjxl for not doing their own due diligence

The bytes can be arbitrary but the spec says they are interpreted as an UTF-8 encoded string.

(jxl-oxide rejects non-utf-8 layer names)

So probably want to use some kind of XML?

Or possibly base64 compressed brotli compressed xml

I personally think there ought to be some kind of watchdog that tries to detect if the decoder or encoder is not passing control back to the caller for too long or if memory usage is ballooning past a configurable limit.

Agreed

If I max out a level 5 bitstream how much processing does it need?

It's just nice to have guarantees when it comes to worst case scenarios.

especially for an image codec

Due to all the complex extra coding modes, it’s way easier to craft deliberately slow bitstream

Versus something like JPEG

where decoding speed is roughly related to just the size of the image

Can I just make every pixel use all the coding tools, enable all post processing and have a bunch of 64-nested MA nodes?

Chrome just gives every tab its own process with some memory limit, and if image decoding takes more than that it just crashes the tab. That kind of works well enough in practice, imo.

These are the limits currently defined. So you can't have arbitrarily large MA trees or anything like that.

But it would lead to inaccessible forum\imageboard pages?

Chrome is... extremely unusual to say the least, with it's very sophisticated and mature sandbox design. When other projects begin to adopt libjxl, it might be embarrassing or create regrettable first impressions if the integration of libjxl results in an entire computer and every program running on it freezing and becoming unusable because of runaway memory use. Most processes do not have any protection from infinite memory use like Chrome does.

If there's a nice and easy way to set certain guarantees during library initialization, then at least no one can blame the library for not doing due diligence and providing a way to prevent that.

anything that allows user uploaded images should do some input sanitizing anyway — generally you'll decode images in a sandboxed environment, downscale them if the dimensions are too large, strip exif etc (which could create privacy issues if it contains things like GPS coordinates), and re-encode them in some format browsers support. If you have a forum/imageboard that allows users to just upload whatever they want and other users get to see that in an <img> tag, that's not very secure at all...

I guess writing a simple malloc wrapper that limits memory use could arguably be considered easy but it's still something that I don't see most projects looking to integrate libjxl likely doing.

But also some sort of time limit would be nice too, to detect if libjxl is hanging and not passing control back to the caller by returning an error or a partial decode in a reasonable response time.

There's this (the fuzzer uses that): https://github.com/libjxl/libjxl/blob/main/tools/tracking_memory_manager.h

How much overhead does this entail? If not significant , maybe it should become default? If a lot, nevermind

You have to benchmark to be sure but probably close to no overhead at all.

Unless multiple threads are allocating at the same time. Then it will have a lot of overhead.

You could avoid that overhead though, if the encoder/decoder was aware of the limit you want to enforce. Because then it could split the limit up across multiple threads.

Having the caller enforce the limit is not as efficient as having the codec enforce it.

If the caller enforces it by wrapping malloc then every call to malloc needs to be serialized instead of parallel.

sadface

Another solution could be making the threads allocate bigger blocks and reusing them instead of allocating / reallocating them

Yes, that's why I'm thinking about some limitation to the browser image decoder that aborts when memory consumption is larger than some defined limit, and does not crash whole tab

Because imageboard's users will definitely post such files

Or a CLICK THIS LINK FOR FREE whatever, which sends you to a malicious JXL

we certainly don’t want another android wallpaper crash or ForcedEntry

If libjxl calls malloc from multiple threads in parallel, then libjxl needs to be aware of and enforce the memory limit. Otherwise, you lose parallel malloc.

Maybe there's a clever way to avoid serializing malloc that I'm not aware of.

decode in a sandboxed environment, yes... image editors, vips, and other projects and libraries that want to integrate libjxl, and even operating systems, don't always have access to a convenient sandbox and personally I think it's always nice when these sort of things are made more convenient for people to avoid any manner of ugly situations.

what do browsers currently do if they get a png that decodes to a huge image?

It is far less destructive, because if that malicious jxl is just part of a page, browser will try to show it without any action from user

I think they just keep going until the computer or browser process dies... But I haven't tested.

Ooh, a png zip bomb

Just curious if it is possible to ask libjxl to use as much ram as <some value> and just exit if it is impossible to decode image using this limitation

Is it possible to tune the decoder to slow down but use less memory if it gets close to the RAM limit?

I just think it's always nice, in a warm and fuzzy sort of way, when security is made obvious and straightforward and convenient. in practice what ends up happening is it's inconvenient and forgotten until it seriously causes problems and big drama.

Like if it’s a simple “pass True for extra security” vs “if you want security you need to implement these 5 interfaces yourself”

It's refreshing when you use something that's designed with limits and guarantees and stuff like that in mind from the beginning in a convenient and obvious way

there are a lot of ways to make a web page that will use a lot of resources or crash the browser tab — I'd say javascript is a bigger risk in that regard than image decoding. With the new "no-abort" updates in libjxl, you should see a broken image icon instead of a crashed browser tab when there's an image that causes OOM during decode.

Oh yeah, totally. I've said multiple times on this server already that I believe it's really bad that Javascript is not designed to ask for permission first for 99% of what it does.

I'm not worried about browsers because they have very robust sandboxing and isolation for everything these days

The jxl decoder memory usage is more or less proportional to the number of threads and to some extent the image dimensions.

I'm more worried about the random open source coder that decides to integrate libjxl into their image library project or image gallery/editor, and one day an image comes along that causes everyone's computer and every process on it to suddenly freeze for 20 minutes

Yeah, I'm sad that not enough people are aware that it's literally just 1 guy and his team, the lead tech of the webp project, who unilaterally told the entire world to our faces that there's just "not enough interest from the boader ecosystem to justify including jxl"

To Apple's face, to Google's face, Meta, Shopify, Intel, and all the other giant firms in the comments sections before he said that

It's so outstandingly, cartoonishly ludicrous that it makes me sad that almost no one seems to know the actual story

It's weird how people keep saying that that Microsoft patent is probably a problem for jxl even though Microsoft never claimed it owns any patents relevant for jxl. Meanwhile, for av1/avif there are actual claims by a patent troll (https://www.sisvel.com/licensing-programmes/audio-and-video-coding-decoding/video-coding-platform-av1/#tab-licence-terms) but everyone seems to completely ignore that and considers it not a problem at all.

Hopefully the Apple cameraJXL rumours come true

Yeah, I remember seeing a web page selling AV1 patent licenses for an AV1 patent pool... Maybe this is the one I remember...

AV1 has an actual patent pool selling licenses to use AV1...

What the heck

…..

Some day there should be a Netflix documentary about this or something, it's a pretty funky story as far as tech / office politics stories go

You're right, that is pretty ridiculous that the same people saying not to use jxl because of patents are saying to use AVIF instead... There has never been anything even remotely close to a patent claim or question on jxl

Is this enforced at all?

Anyway I don't think the sisvel nonsense should be a reason to consider av1/avif non-royalty-free or anything like that, I don't want to spread FUD about it. Patent trolling is annoying enough as it is, no need to feed the trolls. But I'm just saying, the situation for jxl is basically as good as it gets, nobody is making any claims (fingers crossed that it stays that way), yet people keep speculating that this is secretly the big reason for Chrome's decision. If this was really a concern, I'm pretty sure the avif proponents at Chrome would have been happy to have an actual valid argument to remove jxl, instead of having to come up with excuses.

No idea. They claim 62 companies are paying them royalties for VP9 and/or AV1. No idea if that's true. I'm sure that if they would ask Cloudinary to pay, we would just call their bluff, let them litigate and make sure they lose. But not all companies take principled positions on these things, since it can often be cheaper to just pay some license fees than to pay the lawyers.

Microsoft did not ignore it

That's why AVIF support was years late

I agree with that too. I don't think anyone should take it seriously, but it's certainly a lot more serious than whatever people are imagining for JPXL...

Patents are a really bad and really ridiculous idea to begin with. I don't usually like getting this political, but I think it's pretty sad that it's even a thing.

Patents used to be a good thing, back in the 18th century when it was a balanced trade-off: companies could turn their innovative trade secrets into publicly available information in return for a limited-time monopoly — 20 years was a reasonable time window back in the days when the inventions were things like the steam engine. Now it is just a tool companies use to make more profit while society doesn't really gain anything (patents are formulated in obfuscated, very generic legalese that doesn't really help anyone understand the actual ideas) and innovation effectively gets stiffled instead of promoted — not to mention that 20 years is a crazy long time window in a modern economy, in particular in the software industry.

I don't even know if companies still make profits with patents... lawyers and consulting firms do (and patent offices too 😆 )

Some countries, like france, do at least not acknowledge patents on software, which is good

The patent troll companies get money from royalties so presumably it is directly profitable. For most companies, patents are not for making profits directly but to have ammo to kill small competitors and/or to defend themselves against big competitors trying to kill them. But yes, it's mostly lawyers who benefit from the whole thing.

https://www.frandroid.com/produits-android/2324474_jpeg-xl-cette-image-ne-pese-que-quelques-octets-et-pourtant-lavenir-de-son-format-est-incertain

https://www.macg.co/logiciels/2024/09/le-jpeg-xl-permet-de-faire-de-lart-avec-quelques-octets-145763

https://github.com/mozilla/standards-positions/pull/1064

> A safe, fast, and battle-tested Rust decoder from the original team could make Why do they qualify this with "from the original team?"

Are they specifically trying to imply that tirr's jxl-oxide is somehow inadequate or not good enough? It's good enough the author of jxl-winthumb prefers it over libjxl

Also, why rust? Why not something like https://github.com/google/wuffs

Mozilla's take seems kind of arbitrary

Let's continue in <#803574970180829194> to avoid doubling the discussion

Of all the images to see in an article, I didn't expect that one

LOL

Reminds me of

https://tenor.com/view/aqours-rikakoaida-lovelive-gif-19343056

eternal bullying

Wuffs don't document well enough the language to write a decoder, and the main team have no plan to implement jxl in a foreseeable future. They prefer to capitalize on their existing decoders https://github.com/google/wuffs/tree/main/std

And even if it shouldn't be a practical limit for web images, wuffs can not handle buffers bigger than max uint16 pixels

I think it is designed for simpler things than something like the jxl codec.

Do you think it would be impossible to express a decoder in the wuffs language? Might be

Impossible probably not, but at first glance it seems more suitable for relatively simple things like lzw or qoi. But also: in terms of ecosystem size / amount of scrutiny / maturity, Rust seems like a better choice than Wuffs which is still in 0.x and has this disclaimer on its front page: "The compiler undoubtedly has bugs. Assertion checking needs more rigor, especially around side effects and aliasing, and being sufficiently well specified to allow alternative implementations. Lots of detail needs work, but the broad brushstrokes are there."

is this the original or is it like https://x.com/trumpdraws ?

that's the original

https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust

JPEG**-**XL <:PeepoDiamondSword:805394101340078092>

JPEG + XL

does Jon Sneyers work for google

or cloudinary?

i can't remember

cloudinary

makes sense

<:Cloudinary:806630933242445904>

honestly I think "JPEG-XL" looks cooler then "JPEG XL" so I don't mind too much, also it seems to be something that some people have done in the past when talking prior JPEG standards as well so this isn't exclusive to JPEG XL