JPEG XL

is that good

Funnily enough, there's not a 1.0 version yet.

like you will add a mode in this year or when you want

I think if you want to do that, you should use image editing software to do denoising and plastification or whatever effect you're looking for, and then encode the result of that.

what is plastification what plugins there are

I don't consider it the scope of an encoder to make an image look better than the original

like to you an image

that weight 52 kb and was re encode from a 93 kb jpeg is bad?

Hey, filtering should always be done by the software, not the encoder purposefully trying to make an image better.

maybe fb could do based on the size?

on the resolution?

is really needed?

what fb has expressed?

I didn't think that would even be possible. The original image is as good of quality as you will get. Each time you re-encode it, there is going to be some loss of quality. Though JXL does a better job of reducing the losses over time.

with cavif rs it looks like orange the image when you re encode

but aom has sharpening that helps some images to get lower file sizes

why not go in that direction?

aomenc/rav1e/SVT-AV1 do not do sharpening...

why not go in that direction?

fb needs lossy

internet needs lossy

The purpose of lossy compression is to reduce bpp without introducing visible artifacts

That jxl can do quite well

ah to png

The purpose of lossy is not to introduce visible differences like smoothing or sharpening, even if you like those differences

when jxl to jxl

this i think is important to the average user

also microsoft needs to update the decoder

at the moment neither xnview or imageglass update anything

<@!794205442175402004> For public share, the last "stable" commit is on main/0.3.7/0.4.0 branch?

main is the most recent, 0.4.0 is the most stable

i update my sheet for new jxl user 🙂 if i forgot some software, ask me. https://docs.google.com/spreadsheets/d/1bTeraUXIl-nGM8c53IdURxmJbabX9eXqPZwVSynoH9U

Why documentation jxl tab is empty?

important parts of lossy WebP are defined in RFC 6386 (lossless bitstream and some other parts are however just a tech reports by Google)

Yes, VP8 is a standard, but how it's hacked into an image format is not a standard, I don't even know if there's a document describing lossy webp. For lossless webp there's a description that is kind of detailed but not quite a spec, for VP8 there's a real spec, and for the muxing of alpha and VP8 and stuff like that, I think there's only code, no detailed description or spec.

Ah wait there is a 'container spec' on the webp website, it is kind of speccy

I used the lossless webp bitstream description as the model on what jpeg xl spec should look like

that is why we got C-ish description instead of the commonly used algol/pascal-like description of what happens at decoding

usually it is frowned upon by the standards people -- to have any reflection of implementation in the spec

but hey, it is 3x less work and much easier to get right

Yes, that I like

The lossless webp description is a good description, it's not really enough to do an independent implementation from that alone though

I think more stuff should be like webp bitstream description 🙂 ... there are deficiencies, too, like no conformance set

there was an independent implementation in 2012 or so

2014

by some people related to ffmpeg

they found a bug in the spec 😄

(or actually spec was correct and we had added the bug later to code but in a way that it affected encoding and coding the same)

changing the spec was 100x easier at that time than changing the implementations 😄

WebP lossless is a very simple codec in comparison to JPEG XL

I designed it alone -- including all the reasearch -- in six months and three weeks or something like that

I think it's mostly things like "Note: Older readers may not support files using the lossless format." and "Note: Older readers may not support files using the extended format." that are not so nice for interoperability

in webp lossless?

uffffffffff

I don't know of these 😄

Also https://datatracker.ietf.org/doc/html/draft-zern-webp-01

https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification#abstract

interesting the image/webp submission

for image/jxl they put it in as provisional until standardization is ready

I wonder what it would mean for image/webp

Hey, *I also use* Windows as a daily driver... just like 99% of people I know. I only use Linux in form of command-line WSL 2.

This is about devs from the Jpeg XL team or people who can write and maintain a WIC decoder

That'll slow down the adoption since lots of ppl use Windows.

Maybe set up a <#806522208692207617> for this project's maintainer to update it? https://github.com/mirillis/jpegxl-wic

It's a commercial company, I don't think it would be interested in that other than the support in its products <https://mirillis.com/> So maybe this would be better: <https://github.com/saschanaz/jxl-winthumb/issues/3> (as already mentioned)

Yes But if Windows 11 doesnt exist how we do

I'm Windows user, But I just mind which image encoder can get great lossy quality for drawing content(anime).

Could also just fork it, I suppose?

Also, if it's so hard to get support for Jpeg XL (which has objective advantages over AVIF in certain areas), how hard will it be for WebP2? 🤔

nhw codec is better

nhw pulsar

Nhw better? How?

we provided Chrome with an information package -- they will be digesting it for some time

one part was the feedback that Sami collected here 😄

Just joking

Well, if I would have know that making AVIF look superior to JXL gives higher chances of seeing fully-featured JXL in Chrome by default, then I would have written something different. :/

So would it be a good idea to "hire" a new core dev member who uses primarily Win? 🙂

I don't think it necessarily needs to be a new 'core dev', in the sense that they don't need to be involved with the internals of libjxl, it's more about integration, making/maintaining plugins, example applications, helping others with using the libjxl api.

For example <@!239702523559018497> isn't a core dev, but still made good integration with Firefox.

<@239702523559018497> do you have an idea of how things will proceed with firefox jxl support? Are you planning to make icc profiles and animation work?

Also, what is the process to get it enabled-by-default?

Speaking of color profiles: when could I stop using `cs_tinysrgb` in `f_jxl`? I've just tested it and it hasn't been fixed yet 🙁

Right, that issue with IM creating not-quite-sRGB pngs...

I need to compile good infos in that tab 🙂

I don't know how AOM observes JPEG XL, but the last time they were involved in a comparison was in JPEG XL competition in autumn 2018

There, AVIF won over every other codec, including both pik and FUIF

it could be that this is still the basic mental model of AVIF vs. JPEG XL at AOM, and it can be refreshing for them to read opinions that it could be otherwise

if they observe or believe that AVIF is better or even roughly the same (i.e., same generation) with JPEG XL, they will only see that JPEG XL will divide the market and create confusion

if we are able to bring info that JPEG XL is actually one generation ahead of AVIF, then they might have more interest in it

we have been really bad in comparing the codecs (JPEG XL vs. AVIF) for several reasons

Basis is built by really strong minds -- lzham performance was a huge inspiration for me in compression work

I consider the delta palette is one the poorly understood gems -- it will solve many problems existing previously with pixel crisp images containing some gradients or some photographic elements

ktx2 basis ETCIS i compressed a screenshot

https://deploy-preview-1017--squoosh.netlify.app/

i wonder what version of webp2 they are using on squoosh. did they updated it

basis didn't impress me with the first image that I looked (against jpeg xl)

why is jpeg xl a beta?

compression mode is good compression

i had 4 kb images with it

it edited the icon

so it made like a frame

jon don't like in this way

but the image could be usable if basis improve

or if jpeg xl at same bitrate has a smoother image

aom didn't impress me for screenshots

https://discord.com/channels/794206087879852103/803574970180829194/851465015763795968

or for this type of image

with cavif rs it looks like orange the image when you re encode but aom has sharpening that helps some images to get lower file sizes

My feeling from most comparisons or requirements of the Web community is that a very high priority goes to low bpp and what efficiency codec/format can show there (even if in practice it will not be so used), and all other aspects are considered to a lesser extent, Jpeg XL has stronger all other sides (for me much more useful, but I am not the majority opinion), but low bpp its weak side

I sometimes play boardgames who works on AV1, I could ask his opinion...

- Low bpp is easier to promote, easier to show significant visual improvements and traffic savings in marketing articles, even regular users are more likely to compare codecs at low bitrates - Encoding/decoding speed is not always fully taken into account, if it is slow it is justified by the fact that encoders haven't yet reached maturity and needed optimizations, as well as acceptance that each more modern format may be hundreds more complex and slower than previous ones - Progressivity, ordinary users usually don't even know what it is and how it affects perception, so they don't think it's necessary, also there are no studies that prove it's always useful, also the Web world already considers it proper to use separate LQIP images - Ultra-high resolution in a single image and color depth is not considered necessary for the Web - Lossless is also usually not considered a high priority since it does not create much Web traffic and is mainly needed for UI, graphs and such (where lossy formats are not very effective)

yes like me that i did q 63.52 new heuristics p1 and said amazing quality

even if the compression was only about webp

it wasn't incredible

and the colors were desaturated

plus other distortions artifacts that i don't noticed

but i guess scope is talking about fb

I don't think jxl is a generation ahead of AVIF, maybe 1/3rd of a generation but certainly not a full one. I think the main difference is that jxl was designed as a still image codec for software decoding, while avif is a video codec designed for hardware decode, hacked into an image format.

generation means ~30 %

I think it might be a full generation (or at least 75% of one) in the higher quality

in visually lossless or 'camera quality', I consider it is often 2x more bits required for AVIF

some weird corner just gets extremely blurry in AVIF

supposedly AVIF needs to decide about filter strength at 64x64 resolution whereas AVIF gets guidance from adaptive quantization + an 8x8 control field for it

that alone might be a 15-20 % difference in mid and high quality

it becomes a difficult decision to decide filtering a 64x64 when the alternatives then are dct artefacts or blurry details

it seems to me that so far avifenc has opted more on the blurry side

(I don't really know what I am talking about, I didn't read the spec, didn't write the code for AV1/AVIF)

Yes, if you split it up like that, then you could say jxl is a generation ahead at high fidelity and maybe same-gen at low fidelity

probably worse tbh - but that's OK with me

I say 'maybe' same gen at low fidelity because the current encoder is not there yet, but I do think the bitstream should be as capable of doing well there as avif's (but we'll only know for sure once we have an encoder that demonstrates it)

About the shared decoder, is it possible to apply all the optimizations from libjpeg_turbo or will it have to be mostly rewritten? <https://github.com/mozilla/standards-positions/issues/522#issuecomment-856035731>

FWIW, here’s a repeat of the POV on new formats of a big news site (although treat it like a personal one), serving all types of imagery, sometimes as a main subject, much more often as auxiliary to textual content: 1. All are exciting, possible fragmentation being more of a headache for image resizers 2. UI is for CSS/SVG, raster imagery has little use there (lossless is useless) 3. Lack of proper progressive in AVIF may be a blocker for using it in certain contexts (hero, fullscreen etc.): JXL win here is massive 4. Only lowest possible bpp matters: you go as low as possible until it starts to look shit and then you take a small step back. Any other attitude is a waste of your, but mostly, your readers’ time and money*. Would be a pity to have to decide upfront that only hero images are served as JXL, because AVIF is leaner while looking good in majority of other cases. 5. Having a way of targeting that quality independently of the individual image’s makeup would be a godsend (added bonus: lower q the higher the dpr, higher q on wider gamut etc.) 6. Nobody is spending time choosing best encoder and its settings per-image: encoders are not used directly, they are mediated by the resizer service. We understand the burden of providing targeted quality rendition per render, so would be willing to take some compute hit ourselves (there is ample time for preprocessing our-side if that could help inform resizers in their job of knowing what needs to be done to attain target quality) I have no idea if any tech in the encoder could help with pt. 6. But I can’t see resizer services being freely (read: cheaply) willing to create tens of prerenders just to check how to hit the target quality per-render… * that would also be my personal advice for a photographer’s website, nevermind the site where photography is not the main subject

I’m also an amateur photographer, but the non-web use case(s) here is so different. Here JXL is way ahead of AVIF, I suppose, but I also do not care about it **that** much.

we already have SIMDified iDCT and YCbCr to RGB, basically we have everything to decode a jpeg bitstream to DCT coefficients in the encoder (which then spends effort on better entropy coding it) and everything to convert DCT coefficients is already in the decoder. So you'd just have to add some of the jpeg parsing to the decoder and the rest is there already.

Only thing we don't have yet is a streaming jpeg parser, so it also works for progressive. (Currently the encoder expects full input available)

Regarding pt 6, I think that's where cjxl is miles ahead of any avif encoder (or jpeg/webp/j2k encoder for that matter).

Cjxl has a perceptual target and pretty consistently obtains it, reaching a perceptually consistent result without human intervention.

It only works well in the medium to high fidelity range though (I'd say reliable for d0.5 to d4), at lower fidelity human assessment is still needed to figure out if it's acceptable-ish or crap

Any other encoder either takes a bitrate as target (a certain bpp goal) or (most commonly) a quantizer scaling (the thing they call 'quality').

The problem with bpp or quantizer settings is that while it is a scale where "more means better", it is not an absolute scale. For some images, 0.5 bpp is fine, while for others 3 bpp is needed. For some images, -q 50 is fine while for others -q 85 is needed.

You can do trial and error with perceptual metrics to work around this, and that's exactly what advanced image services have been doing (e.g. the q_auto in Cloudinary does something like that, and there are others that also do something like that)

Trial and error is feasible with JPEG, but not with AVIF, where encoding is expensive enough to make one encode per image kind of the most you can afford (if it is affordable at all, even)

This is a property of an encoder, not a bitstream. Theoretically you could make a 'dumb' jxl encoder or you could make an avif encoder that also does reach a perceptual target consistently.

But at the moment, cjxl is the only thing that does it, it's a pioneering encoder in that way, and I don't think we can expect something similar for other codecs anytime soon - it took a lot of effort (mostly by the pik team) to get it where it is now.

I think this is _the_ killer feature of the jxl encoder from the operational perspective of a content provider

AVIF might be better at low bpp, if you can do manual encoding, with squoosh or something, and have the time (so money, because human time is not cheap) to find that sweet spot for every image.

But if you need automated image encoding, and you want to "set it and forget it", then atm AVIF is risky (if you set it too low, you will get a fraction of images that are going to be crap)

Yes, it's a very useful thing that works very well, maybe not ideal for some non-photographic images (but it's tunable), and there's nothing like it that works better (other than fully encoding a lot of images before reaching the right value of some metric)

_I think this is the killer feature of the jxl encoder from the operational perspective of a content provider_ 👍 In my humblest of opinions this should be advertised and dissected in blogposts and videos even more than progressive mode or JPEG redelivery. For “my” (mass) use-case, the most important improvements to JXL would be better quality at low bpp and better perceptual quality targetting at low bpp, then.

This is a pretty big advantage, especially if the decoder has the same speed and features (although I don't think everyone will get rid of libjpeg_turbo very soon, but still) So I think it's worth the investment to be one of the first priorities

Yes, if we can make that work, we could 'sell' libjxl as an upgrade for libjpeg(-turbo), with a different api (inevitably, we have things like alpha, hdr, animation that do not fit into the libjpeg api) but which can read both jpeg and jxl

we could call it libjpeg-ultra or something like that

(kidding, let’s not)

There are a bunch of applications that basically ship a copy of libjpeg-turbo: both firefox and chrome do that, lots of android apps (if they care about jpeg decode speed, since the system libjpeg-turbo can be quite old and poorly optimized for ARM), many games, etc

Also Messengers with billions users

From the pov of binary size, it's a compelling idea to upgrade from libjpeg to libjxl, get a whole new codec, for a binary increase from 150 KB for libjpeg-turbo to maybe 200 KB for libjxl, so net cost only 50 KB

Maybe with some effort we can even match the libjpeg-turbo binary size

There is stuff in libjpeg-turbo that nobody really uses but it's there and they cannot remove it without breaking the api. Like decoding a jpeg to a buffer that uses 256-color palette...

(that was useful in the 90s, when many video cards were still doing the 1 byte per pixel thing to save memory and trade colors for more resolution, basically)

200kb is the size *in the chrome APK*

It's ridiculous to have a jpeg decoder doing that though

not necessarily the same

If it is 200kb in chrome then it can be 200kb in another app too, no?

Of course that is libjxl_dec only

If you also need encode, it's a different story

We haven't really tried reducing encoder binary size yet, have we?

It does probably add quite a bit of bytes. Could reduce it by not having all encode paths (e.g. only support up to effort 7 and input color restricted to an enum colorspace)

it's complicated

Anyway, there are a lot of applications that only need decode, not encode

And those who do need encode, likely care less about binary size

Yes, for that we'd also need to have a jpeg encoder in there... For which we actually also basically have all the code already anyway

It's a bit weird that browsers have a jpeg and png encoder imo. Maybe that needs to be revisited at some point...

No, and also doesn't read it

it's quite a bit of work, mostly 'plumbing'. Making it decode jpeg _progressively_ is probably the trickiest part.

it might be helpful for Chrome and AOM to believe there is a generation difference if more comparisons like this were made available: https://twitter.com/jyzg/status/1402555421337006084

"This is what happens when I tried JPEG XL and AVIF on the Kodak image corpus."

"This is what happens when I tried JPEG XL and AVIF on my vacation image."

etc.

people believe that AVIF is magical and works

but its artefacts at around 1 bpp are worse than what a JPEG XL image looks like after a further twitter's lossy jpeg compression

AVIF removes textures and paints the sky in bit odd way

No no. That is just to set the bpp target

That flat part of the dune on the right becomes plastic instead of sand with avif

I think Jpeg XL should be promoted more on photographic and sites with high-resolution images or where image quality close to the original is very important, because even with this loss of detail average sites usually don't bother

<https://github.com/eclipseo/eclipseo.github.io>

> image quality close to the original Also some non-photographic images site need this jxl features. 🙂

What does a plot like that even mean?

It seems to assume lossy compression has only one quality and they all correspond to the same fidelity

on this image also at 0.3 bpp jxl is vastly superior

Originally, they didn't know which bitrates to use so they let BPG to decide. That was a bad decision and the effort still suffers from it. For some images 'big' bitrates are still too low for accetable quality. I made an attempt to convince WebP team to renormalize the bitrates in a reasonable way, but they preferred not to touch the methodology -- just replicate it.

https://twitter.com/jonsneyers/status/1402577815506149378?s=19

I wonder what people actually want in this regard, so I started a poll

I find that about 90 % of people related to image quality are comfortable using the same ssim-score as a proof of same quality

Yes, but avif is going to be more impressive at the last one.

It's funny: I haven't met any perceptual metric designer yet who really trusts any objective metric, it's kind of common knowledge e.g. within JPEG that objective metrics can be good for catching bugs but are to be taken with several grains of salt for doing actual image quality assessment, but in more devops-like circles, objective metrics are assumed to be flawless and subjective assessment is met with scepticism.

I think it would be better for everyone to vote on Twitter to summarize and make the results more public/popular

If you don't want to make a twitter account, feel free to react to this message with 1️⃣ 2️⃣ 3️⃣ 4️⃣ , but otherwise, yes, what Scope said.

I cannot vote on my own poll but as I have probably said a few times (here or in blogposts etc), I would personally prefer 2️⃣

Maybe (though I don't know how much it really helps with the not-so-popular tags and limited time voting)

On the other hand, about voting, the preferences in this discord and the preferences of random outsiders can be very different 🤔

Why not 2️⃣ > 3️⃣ ?

i like the focus on psnr jpeg xl is having

even at speed 1 the psnr is sometimes comparable to webp2 at medium bitrates

that doesn't mean nothing

but jpeg xl is good

as jon saw in discord av1 image

the encoder currently don't demostrate anything

That's an interesting nuance. Better fidelity on desktop where bw is usually not that much of an issue, better size (without sacrificing but also without improving fidelity) on mobile where bw is an issue

webp2 set at q50

29310

jxl 27,3 KB (27.980 byte)

Focus on psnr? Are you trying to troll? 😅

on speed higher than 1 psnr is rather good

aom focuses on vmaf

webp2 uses same approach

this image was the setting i highlighted speed 1

JPEG XL v0.3.7-31bbdcd7

WEBP2 v0.1.0-a0bc155

https://forum.doom9.org/showthread.php?t=174300&page=22

Psnr is not a perceptual metric and jxl explicitly doesn't focus on it, in fact it deliberately does things that are bad for psnr, like thrashing the blue

128 kbps mp3 aren't good

LAME does have some settings to extend the highs. But generally, the idea is that wasting 'bits" on sounds that are usually masked or otherwise inaudible means fewer bits where they might be more important and overall the sound can be worse. (When people hear compression artifacts, it's usually not a loss of highs that they notice/hear.).

Very hard to answer that without knowing what baseline is it relative to? My specific case: 1.8–2️⃣ Internet average pic size/quality: 3️⃣ –3.5?

baseline is what you do now, which indeed is different things for different people

(a lot of sites are still serving basically unoptimized images, they could get same fidelity, much lower sizes now already by properly resizing their images and switching to mozjpeg and webp instead of uploading images straight from camera or from Photoshop saved at high quality, but I am assuming most people who answer that poll are already doing something sensible now)

You know, I believe aq-mode=1 and chroma-deltaquant should become the default for aomenc in AVIF since it provides a large psycho-visual boost while not touching anything else.

I think I may have already linked and said this but I believe the over-reliance on “objective” metrics to be a manifestation of the streetlight effect: https://www.discovermagazine.com/the-sciences/why-scientific-studies-are-so-often-wrong-the-streetlight-effect

Maybe 10bit also worth open on default mode?

Is enable-chroma-deltaq=1 now works on images w/ alpha?

when you can assign a number to something, it’s very tempting to see it as “objective” and give it ultimate precedence, without much consideration for what the number actually means or represents

I would like that to be the case, but that will not happen as there is a noticeable encoding/decoding performance deficit when switching to 10b.

Yes, but you should only enable chroma-deltaq on color stuff, not alpha stuff as not to break the process.

> avifenc -a color:enable-chroma-deltaq=1

For example: `-a tune=butteraugli -a aq-mode=1 -a color:enable-chroma-deltaq=1`

Also, from my observation, aq-mode=1 does not work well for anime content, it leads to larger file size and a smoother image?

same time 🙂

Well, that is to be expected since it is a variance based aq-mode(which means large flat blocks will be given more bpp), but it actually works well in that regard, preventing nasty artifacts or overblurring of some other stuff.

what do *you* use to produce AVIF images? I've heard the recommendation of `--min 0 --max 63 --a end-usage=q -a cq-level=quality --tune=ssim`

That works well, but while --tune=ssim works well to preserve more detail on photographic images, it butchers color, which is why I always use `-a tune=butteraugli` now.

also, any thoughts on when to 420 and when not to 420?

Never chroma-subsample, unless the source is already in 4:2:0.

heh

But for now tune=butteraugli only support 8bit.

Yeah. Hopefully, I'll get that fixed as well.

our AVIF colleagues recommend to ~always `-y 420` IIRC

For low fidelity, 420 is likely better

I do not believe from my own testing experience. It might prevent more artifacts, but it butches color performance even more when you do chroma-subsampling at low bpp.

also -- any practical experience on the difference between `-s 0` - `-s 6`?

Also with `--min 63 --max 63` (when min=max) encoding should be much faster

Well it is image dependent if you can get away with 420 or not, sometimes just doing 420 already destroys something too important before you even start compressing

and while I'm on a roll... `svt-av1`, `rav1e` or `libaom`? 😛

`-s 0` is for absolute maximum efficiency, so not feasible to use in the real world using aomenc since it throws speed out of the water. For practical purposes, I usually pick `-s 4` As for which encoder, while I'd like to recommend rav1e, it seems to have some issues regarding YCbCr color performance in still_image mode for some images. For pure image quality, libaom. If you want to use something faster than `-s 6` in aomenc, I'd recommend switching to SVT-AV1 instead.

But for the ~90% of images where 420 itself is not too destructive, I think for both jpeg and avif (and heic) you get better quality/density by doing 420, at least at the low end (at higher fidelity it's something else)

Our experience (from a while back) is that svt is best at speed 7, and aurora is even better

I mean, how much do you feel `-s 0` improves things over `-s 6`, if you don't care about time?

That is something that I've not experimentally measured since I have started the encoding tests today, but from anecdotal evidence, anything below `-s 2` or `-s 3` gets negligible gains below that, unless at extreme low bpp where every millipercent matters xD

fair enough

I haven't seem much of a difference in the higher quality settings

(anecdotally)

But yeah, now you understand why I prefer using CJXL for images 😛

a bit faster? 😛

and I think it can get in ~1bpp what AVIF can get in 1.4 or so

Speed is not the only consideration. It's also complexity from the encoder side, tradeoffs, having to deal with non-psycho-visual aided "Quality" settings, in which `-d --distance` works exceptionally well, and feature set.

I really don't like having to pick a specific quantizer setting for example, I just want a quality know, and deal with it.

I also like to not have banding from 8bpc quantization, while cjxl does everything in 24-32-bit, bypassing the problem entirely.

It also has noise synthesis, which makes its low bpp performance in photographic images quite a bit stronger, like AV1 grain synthesis.

In my test, For non-photographic images, If I want find best lossy quality on different images, avif quantizer is difficult to control quality, jxl butteraugli and heuristic is more stable to control quality, so I very look forward vardct can implement some improve for non-photographic images. 🙂

In the end, I do believe AVIF can carve out its niche(extremely strong animation performance and good all around performance if tuned well, especially at low bpp).

However, JPEG-XL has been designed from the ground up as a next generation image format, and it is better suited to images overall than AVIF.

JPEG XL Alien Technology From The Future! 😛

And this is not a joke, although I did not compare the latest builds (maybe something has changed), but after certain updates encoding with the constant quantizer was noticeably faster than with the variable quantizer

I mean, to be fair, encoding at such low file sizes is indeed very fast.

This is just an example, the main thing is that they are equal

I see 🤔

And with `aq-mode=1` I also had worse quality on some art content, so it's not a very universal option for everything

Conclusion: we need jpeg xl

Conclusion: We need every encoder to get better 😛

what is the best command line (or a good commandline) for avifenc ?

how do you observe improvements due to butteraugli?

Thank you for reminding!!! 🙂

in guetzli we noticed that often just going to a lower quality when starting from yuv420 sources gave better compromises with yuv444

yuv420 quantization noise in chromacity plane goes twice as far, and some red quantization noise can be quite visible far apart

recompressing can increase this quantization and make it a big issue -- even when the image itself doesn't have yuv444 information in it

possibly this is less of an issue in a more advanced codec like AVIF than it is for JPEG

For me I use like this, I think BlueSwordM know more about av1 knowledge. > avifenc --min 10 --max 10 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=10 -a color:aq-mode=1 -a color:enable-chroma-deltaq=1 -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=8 // default tune psnr // -a color:denoise-noise-level=8 for photo // -a color:denoise-noise-level=5 for drawing // default 1/13/6 // --cicp 2/2/8 ycocg // --cicp 2/2/6 ycbcr

Yeah, I think something like this: `avifenc --min X --max X -d 10 -a color:denoise-noise-level=5 -a color:enable-dnl-denoising=0 -a color:enable-chroma-deltaq=1` Maybe sometimes without: `denoise-noise-level/enable-dnl-denoising` And with : `tune=butteraugli/ssim` `aq-mode=1`

what would you use for the same cjxl spell?

(for the roughly same purpose)

In my opinion there is not much I can change for lossy in cjxl other than the quality and speed settings

And even in the speed settings I usually don't touch other values besides `-s 7` and `-s 8`, `-s 9` is too slow and doesn't give better results (and can also be worse sometimes) If we talk about the correlation with AVIF quality settings, it's hard to compare and very much depends on the content

In my test, avifenc end-usage=q quality compare jxl -d, just a sample data not too much accurate. (use maxButteraugli_jxl, 3Norm, 9Norm, dssim, ssimulacra adjust) > q7~q15 -s4 near cjxl -d 0.5~1.0 -s7 > q15~q22 -s4 near cjxl -d 1.3 ~ 1.45 -s7 > q22~q28 -s4 near cjxl -d 1.6 ~ 1.9 -s7

I tried to improve my response on mozilla's standard track -- https://github.com/mozilla/standards-positions/issues/522#issuecomment-853919129

When it become bullism? <:kekw:808717074305122316>

How to contact Vimeo dev and convince they use jxl? https://medium.com/vimeo-engineering-blog/upgrading-images-on-vimeo-620f79da8605

jxl isn't meant for them

unless you do

JPEG XL v0.3.7-31bbdcd7 -d 3.02577 -s 4 --faster_decoding=3 --use_new_heuristics

jpeg xl can waste bits

because isn't optimized for quantizers or for slower speeds

In Daala IRC, but this is useless until JXL support is not enabled in browsers by default

well, them wanting to use it would give a datapoint to browsers 😛

However, about JXL magic settings, such people exist https://discord.com/channels/794206087879852103/840831132009365514/852171018198056990

So, theoretically not for 100% of users the default encoding settings are enough for lossy 🤔

Finetuners are gonna finetune. Most people won't bother (or cannot bother since they don't get much control over encoder settings — applications with write support rarely expose all the detailed knobs and dials that the encoder has)

Yes, and for JXL lossy it can be both good and bad at the same time, it is good if the default settings/encoder choices are the most optimal and give the best quality, but if not and there is no way for users to improve something

There is always a way: use cjxl or your own encoder directly. But in many cases someone else makes the decision, not the user, and that someone else is an automated system, like the resize/recompression that twitter, facebook, whatsapp etc do: no user control at all, you get what they do with the image and that's it.

In image editors you likely get a quality slider but that's about it (in some you might get a bit more control, maybe behind some 'advanced' button)

I think jxl is an opportunity for companies like facebook and twitter to get rid of their reputation as "ruining the images" if they use jxl mostly to get a better / more consistent fidelity, not to save more bandwidth

-d 3,02577 -s 4 --faster_decoding=3 --use_new_heuristics

b- 77520,3 ƨ- 4 3=ϱniboɔɘb_ɿɘɟƨɒʇ-- ƨɔiɟƨiɿuɘ⑁_wɘn_ɘƨu-- 🪄

i can do the same at s 7

but i will get worse compression

so not 0.227 bpp

for screenshots

image quality probably won't be noticeable the improvement

because this settings is already high quality than webp for 99% of users i think

if you want to tune every single image you can

but i don't think jpeg xl will be better than webp and avif at 0.227 bpp

better visually looking

webp2 is good also

jpeg xl at the moment is good for the reasons you all gave, but at the end generation loss, algorithm they don't seem particularly interesting

because we do not know many things

at also quality when you specify a distance is not written in cjxl

You mean the mapping between -d and -q?

About distance quality(just-noticeable-error) you can see this, > from Jyrki Alakuijala comment > -d 4.1 means that you accept errors that are 4.1x what I consider just-noticeable-error. > at -d 1.0 you would get exactly what I consider just-noticeable-errors.

So far, looks like 92% wants at least the same fidelity (not lower fidelity with still good appeal), 45% wants higher fidelity

libvips 8.11 is out and includes jpeg-xl support https://twitter.com/jcupitt65/status/1402932085304791045

<:Hypers:808826266060193874>

perhaps tweet with @twitter ?

what does it mean? what would be the ideal solution here?

the first generation of digital tv was strictly worse than the end-stage of analog tv, they used the advance for shipping more channels instead of better or even the same quality

probably windows *developers*, but ... 😄

(we should also package the WIC plugin if we can, I guess)

Having windows package is nice. Is it possible to add jpegxl plugin in windows store? like they do with av1.

I *think* that has to officially come from M$

no in windows store, in windows update

windows sun valley should have jpeg xl

I don't thik there is al limit on third parts app

Also with "new windows" store will be integrated with a package manager, distribuite jxl in this manner will be fantastic

Spoiler, the package manager will be a copy of apt-get, the autor of apt-get spoke about it some time ago

well, the thing is that plugins like the AV1/AVIF ones use some non-public API IIRC

Oh, seem I have blurred memory

Any infos if camera and smartphone manufacturers would adopt JPEG-XL? Would the force the JPEG brand help?

Only because there were not many alternatives at the time for 10b output.

Now that JPEG-XL is here, that might change soon™️

Jpeg xl is simply Not made for 10 year old computer

Its processing is heavy 32 bit

4 minute for a kitten 16 mpx image and 3.254 mb ram consumption

With new architecture probably will use 6 GB

Correct me if I'm wrong, but shouldn't 32-bit float actually be faster to process than 24-bit int?

why would it be faster?

not that 24-bit int exists, you'd use 32-bit ints

24-bit int doesn't align well with CPU registers

Would 32-bit int be faster than 32-bit float?

depends on what you need to do with them 😛

addition? sure. multiplication? depends. division? slower

although for image stuff division is not so common

so often they'd be faster... but with simd archs, have some interesting limitations in weird places

> some interesting limitations in weird places Which ones for example?

IIRC fixpoint multiplications are different on arm and x86

Where and how can I learn more about such weird quirks of low-level implementation details?

So?

WHOAAAAA Which settings did you use? `-s 7` VarDCT shouldn't be taking *that* long, I've tested it on a 19 MPix image and it took only a couple of seconds on an 8-year-old Dell Latitude E6330...

probably modular with weird options

modular encoding is still pretty slow at effort > 3

kitten is also quite slower than -s 7

all I know I learned from https://developer.arm.com/architectures/instruction-sets/intrinsics/ and similar Intel info xD

He uses a VERY old laptop

I think first generation i core

An old enough laptop has a weaker cpu than a cheap phone

i used -d 0.048176 -s 8

with JPEG XL v0.3.7-31bbdcd7

it says encoding to d 0.100

but i have to verify it

<@416586441058025472> what are your computer specs again?

new linux image viewer: https://www.reddit.com/r/linux/comments/nxj1xt/image_roll_my_new_simple_and_fast_gtk_image i asked about avif/jxl support

i3 330m 4 gb ram

this was the best you could have in laptop in 2009

799 euros i paid

dual core still

Perhaps you don't have enough memory to do encoding of large images with the current cjxl

If it starts using swap space then no way it is going to have reasonable speed

Also it could help to switch to an OS that doesn't eat half your RAM itself

probably not 😛

I think the rpi has a weaker single-core cpu but it has 4 of them, probably still weaker overall

the pi 4 is pretty slow

8GB RAM will help though, Fabian's 4GB laptop likely starts swap thrashing on big image encoding

Clockspeed is only part of the story, it's more about cache, pipelining/throughput, simd instructions, etc

Hm, how come there are no ARM results on https://openbenchmarking.org/test/pts/jpegxl-decode&eval=3bf51333cfa7b617571e31ae4e2833d0be552161#metrics ?

I wonder if buying a 1000 euro laptop every 10 years or a 500 euro laptop every 5 years is a better strategy on average

Taking warranty, chances of accidents etc into account: cheaper one more regularly is better

Even without that, it's probably better on average

Flagship models are always more expensive than they can be, they need to amortize the development cost somewhere and they cannot do it on the low/medium end devices because that market is too competitive

Probably a good strategy is to get a cheap desktop pc to do your compute on, and then a cheap laptop for when desktop is inconvenient. Can share drives over the network and keep a shell (or even remote X) to the desktop open so the laptop doesn't have to do much compute.

I have a phone (pretty modern ARM), an OpenPandora (ancient armv7), and an rpi4 which I somehow cannot get to work

Don't remember, whatever they suggest. Haven't spent much effort on it yet, could be I just used a bad sd card or whatever

I have a working rp4

and also a working rpi3 but it's hooked up to work as a wireless speaker 😛

with JXL I remember it wasn't so good xD

raspbian

and, well, it works, but...

IIRC it's like 3x slower than my phone

even with neon, the rpi just doesn't have that much computing power

Rpi aims at cheap and weak, good for hobby projects but not exactly a number cruncher

that depends on who you are 😆

it's probably enough for *my* personal website for at least a few more years

Serving a static website does not require a lot of compute, I'd think, it's probably more important what kind of uplink and ping you have...

When your entire website fits in RAM (as is the case for a typical personal website), and it's just static stuff, then likely only the network is a bottleneck

well, the CPU *can* become a bottleneck, but it takes... a while

this website does use a RPI like device (have not found what board it is using) But you can optimize your website. The website got quite some traffic while running on a PV+Battery <https://solar.lowtechmagazine.com/about.html>

Interesting

BTW, I've packaged jpegxl for Fedora F33-F35. It will be used as a dependency by AOM for the new butteraugli tuning

I'm curious if using JPEG XL instead of dithered PNGs on that website would help in terms of both filesize and quality...

How are Chrome politics looking today?

I managed to build qimgv for win64 with jxl/avif support. Good viewer. If anyone is interested, you can get it here https://github.com/eddiezato/eddiezato.github.io/releases/download/bin/qimgv_win64_v092a2g9a5f8d7.7z

Here's a data point on the kinds of fidelity targets our customers have. <@!532010383041363969> We have a `q_auto` feature, which takes an optional fidelity target (`best`, `good`, `eco`, `low`), where the default is `good` if save-data is false, `eco` if save-data is true (but the default can be overridden, e.g. someone who cares a lot about fidelity will set their images to `best`, someone who cares a lot about bandwidth will set it to `eco` (so also if save-data is false) or to `low`. For most codecs this involves search and heuristics; for jxl I will just do a simple mapping (at the moment it's `best` -> d1 (q90), `good` -> d1.9 (q80), `eco` -> d2.8 (q70), `low` -> d3.7 (q60). To get an idea of what kinds of targets we end up producing: looking at a bit over 57 million image encodes that were done by our biggest customers on June 1st, we had 56% of them at `good`, 19% of them at `eco`, 17% at `best`, and 8% at `low`.

I consider jxl clearly being better than avif for `good` and `best`, avif being better for `low`, and I'm not sure about `eco`.

avif doesn't work

error 11 or something

Do you remember my guide for permanently enabling JPEG XL in MS Edge 91? https://discord.com/channels/794206087879852103/803574970180829194/848009313196703745

Now I've just made it into an easily shareable gist! 😃 https://gist.github.com/ziemek99/6295222469218427bb160cf849cdaa0c

I *believe* I can now accept PRs to https://github.com/mirillis/jpegxl-wic - so if some of you feels inclined to (a) update the version of libjxl or (b) send something like an AppVeyor configuration...

How did you get permissions for that?

hacking

it's a secret! 😛

(Jan asked xD)

https://chromium.googlesource.com/chromium/src/+/b951d2523bfb922aaa9298f765ead69eddf0c2e8

jxl landing behind a flag in android chrome!

> Attempts to further reduce build size didn't produce significant > results: for example, removing support for multi-threaded decoding (not > used in chrome) -> only -0.5 KiB. 🤔

So there are no plans to support multi-threading in browsers, even for decoding a large single image, since it's harder to predict and properly allocate threads for that?

Chome doesn't do that atm with other codecs, afaik. <@795684063032901642> do you know more about this?

I'm a bit surprised that getting rid of all multithreading is only 0.5kb decoder size reduction - I would have expected a bit more, but that would perhaps require bigger code changes (replacing currently-parallelized things with hardcoded single-threaded variants, simplifying some of the stuff that is complicated only to allow parallelization)

Also, why would multi-threading not be used in Chrome for image codecs even though video decoders can use all of the threads if necessary?

One argument could be that typically you have only one video playing at a time, while there can be many images on a page

I see. Now the question is: can page loading multi-threading(chunked loading, or one thread per element) still be done?

If one thread per image is done, then multi-threading per image isn't as needed.

image codecs are made for bigger size

I don't know much about the internals of browsers but I would expect multiple threads to be used when there are multiple images

so video codecs have not usefulness

Maybe it's for tomorrow in chrome canary? <:Hypers:808826266060193874>

likely - or else the day after, I guess

that's definitely true

it's not a hard limitation, just a question of implementing it

Does it use one thread per image or one thread total for all image decoding?

I just noticed that there is a JXL flag available in Firefox beta, but apparently it doesn't do anything...

Good start.

In my experiments with simple photographs JPEG XL palette mode looks 7x better than 256 color dithered PNG, and is 50 % of the filesize. With simple graphics you get less difference, but you get more guarantees that it doesn't look terrible.

I wonder if a tool that did Mozjpeg, AVIF and JPEG XL at normal bit rates (quality 85-95) and show with flipping the differences would create more awareness of the problems in AVIF

I observe Mozjpeg being pretty competitive against AVIF -- and Guetzli even more so around quality 90

normal bit rates on the web are not 85-95, more like 65-85

65 bpp isn't too bad

do you have a link?

last time I sampled it, I found two hills in the histogram, one at 75-80 and another at 85-95, median looked at something like 80-85

(I used imagemagick's identify to measure quality)

lowest site was running at quality 60 (now when I looked that site again, they had upgraded to 72)

imagemagick identify is not necessarily very accurate for things that aren't encoded with default quant tables from libjpeg-turbo or IM itself

Roughly speaking, our q_auto low corresponds to a median of q64, eco to a median of q70, good to a median of q79, best to a median of q91 (in libjpeg-turbo terms). By volume, we do ~7% low, ~18% eco, ~61% good, ~13% best.

(it might end up doing anything between q40 and q95, depending on the image itself, but those are roughly the medians for each fidelity point)

you know what you are doing and can drive the quality down to a sufficient but low level

not everyone knows about it, and for example image's on MIT's website were compressed at quality 99 last time I looked

ah yes that does happen, people also upload stuff straight from their camera to their homepage as a way too large q97 sequential jpeg

but that sort of thing shouldn't be typical of most browsing — bigger websites and social media shouldn't be doing that (it still does happen, it's basically our sales team's job to find them 😅 )

anyway, while the _current_ (well-optimized) web is serving images at roughly the fidelity of libjpeg q65-q85, I hope that with jxl we can bring that fidelity to the libjpeg q80-q95 range while reducing the bandwidth to that of libjpeg q40-q70.

Nah, let's keep the data rates of libjpeg q65-q85 and have Q90-Q95+ fidelity with JXL <:Stonks:806137886726553651>

I'm in favor of that, but the people who pay the bandwidth bills probably don't agree 🙂

My opinion is known, so I will repeat it 😜: that would be a waste for (almost) no gain. And apart from [progressive font](https://www.w3.org/TR/PFE-evaluation/) loading, browsers need to be able to load shape data progressively and dependent on font-size, too.

I think it would be nice to have more auto-adjusting of fidelity based on network conditions, user preference, and target display/medium. That way we could have very high-fidelity images when it makes sense (say when you're browsing at home on a fast network with a good monitor, or when you want to print a web page, and lower fidelity ones when that makes more sense (when you're on a slower network, on a device with a small high-density screen, when you're paying for mobile data, etc).

letting it be not so much a web author decision to serve everyone the same fidelity regardless of what they actually want/need

The Steam game distribution platform doesn't seem to process user data in announcements, guides, artwork. Often devs upload hi-res PNGs and users have to download those to read an announcement even when the display size is much smaller.

browsers could even do smart things like when you're just scrolling quickly through a timeline, it gets the low fidelity versions, but when you stop at a certain image, maybe start pinch-to-zoom on it, then probably you want the high fidelity version

sounds like they should be updating to Cloudinary (or whatever other similar service). Just passing user-generated content along is the easiest thing to do (also in terms of security risks for their own infrastructure), but it's not the best thing to do...

Yes, that's why I mention it. Although, I realize bandwidth is probably less of a concern for them overall given that users are downloading GBs of game data anyway.

when i need new build of jxl

bandwidth is always a concern - even netflix is concerned about the bandwidth of their still images

Surely Instagram is more concerned about images than Steam. But yes, even as a user I don't like downloading a 15 MB image just to read a paragraph about a game update.

even if you don't care about the bandwidth cost itself, just the slower user experience is a cost too

(it means less transactions/sales/ad income, simple as that)

They do optimize content on store pages at least, just not in community posts.

in bandwidth, the user is still more expensive than computers (for waiting), a human is roughly 1000x the cost of a computer and a cable

if someone computes otherwise, they will be repelling users

the services that grow fastest, have most users to click on ads or products, will survive the 'evolution' of web services -- and not necessarily those who save the most money on their cpu or bandwidth bills

I think Chrome (93.0.4542.2) has some kind of memory leak/issue when playing animated JXL. If someone could confirm:

Chrome reports a RAM usage of over 800 MB for a tab playing this JXL and it takes several seconds until it runs without pausing.

APNG and WebP both run fine with each at a mere 28 MB usage:

<https://cdn.discordapp.com/attachments/803574970180829194/855214208635502622/animatin_test.png> <https://cdn.discordapp.com/attachments/803574970180829194/855214220446138388/animatin_test.webp>

ah, we know about the problem with memory, and we're working on fixing it

as for the speed, that's a different issue

one which I'm not 100% sure about

btw, VP9 (aka. a video codec) uses around 90 MB and the file size is also larger than even WebP. Plus the image looks ugly in Chrome. <#805007255061790730>

it's mostly still image with moving parts so that makes sense

Looking at the top 20 cloudinary customers (aggregated over just one day so not fully representative and certainly not taking into account seasonal effects), I see 1 that uses q_auto:low for most images, 11 that use q_auto:eco for most images, 3 that use q_auto:good and 5 that use q_auto:best.