JPEG XL

<@!794205442175402004> hell yeah, built-in blurhash!

We're not talking about one image loading off of the fastest connection

We're talking about multiple images on a website, like up to 20 onscreen at the same time, and we're talking about bandwidth varying from a garbage ISP in a developing country to the fastest fiber

Also while I think having an end-user-centric view is generally good for the web, you have to understand that bandwidth is a thing that does matter for servers. The reason clients don't have to worry about it, is that effectively servers are paying the bill.

(though with mobile data plans, it is often also the client who pays the bill, and a 50% reduction in image sizes probably translates to a 30-40% overall bandwidth reduction and mobile data money saved for a typical web page)

https://www.biorxiv.org/content/10.1101/2021.05.29.445828v1.full.pdf&ved=2ahUKEwjHsb-ii_fwAhXR_KQKHdXhB3Y4ChAWMAB6BAgGEAI&usg=AOvVaw0xiZnkoDDIHooqi61gBv_H

That link doesn't seem to work

ugh

https://www.biorxiv.org/content/10.1101/2021.05.29.445828v1.full.pdf

Will read

What's going on at compression rate 8:1? it's strange no?

wouldn't you want medical imagery to be mathematically lossless?

Lossless j2k (inside a DICOM container) is the typical thing used in medical imagery atm, afaik

well this is not *exactly* medical data though 😄

and the thing is, it's so much data that they couldn't possibly store it all with lossless (especially once they switch to not-just-the-H1-part)

Praise & support from the Cloudflare CDN & one of my predictions is coming true (looking into performance). https://github.com/mozilla/standards-positions/issues/522#issuecomment-852891626

This discord has all the experts of image compression 😅

https://boards.4channel.org/g/thread/82004109

The folks on /g/ have taken note of the Adobe thing, and are talking amongst themselves.

> There is literally no reason to ever use a new image format for the rest of my life.

nice discussion

Lol someone posted a bunch of random noise as an image to try to prove jxl was bad

Of course jxl won't do well on random noise it's random noise

This is the image BTW ^

Weak.

Not even using noise synthesis smh

it's apparently to waste space on 4chan's servers as protest lmao

kinda funny but i doubt it'll do much

likewise

I think lossy modular worked kind of on that

But I think it's too bad to be actually useful

Plus not being worked on actively compared to vardct or modular (lossless)

Lossy modular is actually used for encoding of DC and alpha, but yes, vardct in general works better. For some images, lossy modular might work better though.

There are quite a few ways to do lossy in modular btw

There's Squeeze+quantizing the residuals

There's lossy delta palette

There's using a predictor (e.g. gradient or weighted) and quantizing the residuals

Currently we do the first for alpha and for DC at low quality targets and the last for DC at high quality targets

For non-photo images I think lossy delta palette can be good (and maybe in the future vardct with better use of splines and patches)

what is HDR \:S

Another article from the same author on the same site as last time but this time more about jxl: https://www.root.cz/clanky/ani-heic-ani-avif-ale-jpeg-xl-bude-nastupcem-stareho-jpegu/

a tldr for those of us that don't know Polish? 😛

Translated from Czech to English: https://translate.google.com/translate?sl=cs&tl=en&u=https://www.root.cz/clanky/ani-heic-ani-avif-ale-jpeg-xl-bude-nastupcem-stareho-jpegu/

er, Czeck 😛

oh, so translate does a decent job there?

Basically the author mentions the competitors and hopes for jxl to become the successor of legacy JPEG.

I can't check the translation because Google Translate says something about weird behaviour of my computer or my network and doesn't translate… 😜

> For example, the combination of Rawtherapee counting everything internally with 32bit / channel accuracy and JPEG XL can save 32bit / channel, is a cannon on a sparrow, but at the same time a lot of space for possible future adjustments of images that you will simply never do with 8bit JPEG. give you a histogram.

🤔

what is a cannon on a sparrow? sounds like a Czech proverb or something 🙂

so it's overkill basically

yeah it probably is — likely 24-bit floats are enough in practice for all authoring workflows, it's just that 32-bit floats happen to be *significantly* easier to work with on any cpu 🙂

also: better safe than sorry

anyway, nice article, thanks for the pointer, <@!792428046497611796> !

https://blog.sesse.net/blog/tech/2021-06-09-00-15_encoding_avif_from_perl.html

> Unfortunately, I am unable to find a setting where AVIF 4:4:4 consistently outperforms regular JPEG 4:4:4 (even with libjpeg); it's fantastic at lower bitrates, but I want visual lossless, and at those bitrates, it's either smoothing way too much structure or using way too may bits. So next out is probably trying JPEG XL, or maybe figuring out how to hook up mozjpeg…

That's what I've been annoyed about since lossy WebP regarding any image format based on a video codec.

https://boards.4channel.org/g/thread/82004109/jpeg-xl-endorsedsupported-by-adobe

https://dbohdan.com/wiki/jpeg-xl

https://www.smashingmagazine.com/2021/06/smashing-podcast-episode-39/

Also, very heavily compressed preview <:SadOrange:806131742636507177>

https://news.ycombinator.com/item?id=27559748

https://news.ycombinator.com/item?id=27577328 also heh

many people posted links to a 10 month? old comparison of jpeg xl vs webp

that comparison is a lot more unfavorable to jpeg xl than a recent comparison

please consider upvoting my link to a more recent comparison so that it would occur at earliest moment in the discussion

the comment starts 'Please up-vote this.'

haha, I'm not an expert on social media 😄

I'll reformulate the request

"Check it out with your own eyes with the most recent comparison site for WebP, AVIF and JPEG XL:"

true, also not for some other exotic kinds of JPEGs, but for your typical camera pictures it's not going to be an issue

[Ouch](https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#us-open-tennis-2010-1st-round-046&WEBP=s&JXL=s&subset1) – that’s gonna replace Vézelay Basilique and Air Force Chapel as my personal test-improvements link…

TBH, it never even occurred to me to test against anything else but AVIF…

jxl is super in this image

other codecs are very bad

it's one of those images where "Big" is 0.5 bpp

It's an image where smoothing the flat areas isn't very problematic and webp/avif win by doing edges without ringing at that low bpp

Would be interesting to see how the current jxl does on it

with new build, i need to do an animate ^^

And with 75% of resolution is WAY better.

Adding a resize option for avoiding very low quality is a very good solution. Here file size is 1% of png !

An other smart optimisation is to encode the 50% center of picture with a better quality than edge, because center is WAY more important in picture than the edge. For example here -d7 in center and -d9 in edge.

Another possible tweak: face detection. People pay LOTS of attention to faces, so the AQ should give a bit more bits to them than other areas.

Yes, for the future encoder, face detection is a HUGE performance gap for visual quality, with low detection complexity. eyes and mouth need visual lossless encoding everywhere, it's a very small pixel surface.

our JPEG XL competition entry had face detection and boosted faces by 20 % in adaptive quantization

but it had many other problems 😄

competition entry?

Presumably for the JPEG XL call for proposals.

so PIK?

PIK + several kludges

To be fair the jxl is more than 2kb smaller

look at my file, it's not good enough, even with last build.

<https://www.reddit.com/r/programming/comments/o4u8fp/jpeg_xl_would_be_turingcomplete_via_rule_110/>

I don't have a Hacker News account, could someone post there my Gist about enabling JPEG XL in Edge?

https://news.ycombinator.com/item?id=27579742

And here's my gist: https://gist.github.com/ziemek99/6295222469218427bb160cf849cdaa0c

done

Edge on Linux is still in testing phase, those who have it installed will probably know how to adapt those instructions for Linux...

And I don't have access to a "proper" Linux (with GUI), I've only got CLI in WSL2.

Thanks! 😃

By the way while you're here <@!794205442175402004>, I've browsed HN a bit and stumbled upon an article about Green Pass QR codes. I can't make this sucker smaller in JXL than Pingo-optimized PNG...

https://gir.st/blog/img/greenpass-demo.png

PNG (Pingo): 2,167 bytes JXL (first command): 2,249 bytes JXL (added `--patches=0`): 2,161 bytes JXL (added `-P 0`): 2,158 bytes

try --patches=0

Command: `cjxl greenpass-demo.png greenpass-demo.jxl -m -s 9 -I 1 --override_bitdepth=1 -v` (`-g 3 -E 3` weren't any helpful)

patches detects some stuff here but it isn't helpful

`--patches=1`: ```Read 350x350 image, 18.7 MP/s Encoding [Modular, lossless, tortoise], 2 threads. Compressed to 2249 bytes (0.147 bpp). 350 x 350, 0.22 MP/s [0.22, 0.22], 1 reps, 2 threads. Average butteraugli iters: 0.00 Total layer bits headers 0.538885% 95 Total layer bits TOC 0.096432% 17 Total layer bits quant tables 0.005672% 1 Total layer bits dictionary 1.968348% 347 [c/i: 2.00 | hst: 6 | ex: 6 | h+c+e: 40.532] Total layer bits modularGlobal 95.047932% 16756 [c/i: 8.00 | hst: 33 | ex: 0 | h+c+e: 2090.367] Total layer bits modularTree 2.342731% 413 [c/i: 3.00 | hst: 11 | ex: 14 | h+c+e: 52.716] Total image size 17629 [c/i: 13.00 | hst: 51 | ex: 20 | h+c+e: 2183.616] Allocations: 671 (max bytes in use: 6.380992E+06)```

`--patches=0`: ```Read 350x350 image, 21.8 MP/s Encoding [Modular, lossless, tortoise], 2 threads. Compressed to 2161 bytes (0.141 bpp). 350 x 350, 0.25 MP/s [0.25, 0.25], 1 reps, 2 threads. Average butteraugli iters: 0.00 Total layer bits headers 0.526559% 91 Total layer bits TOC 0.121514% 21 Total layer bits quant tables 0.005786% 1 Total layer bits modularGlobal 96.956371% 16756 [c/i: 8.00 | hst: 33 | ex: 0 | h+c+e: 2090.367] Total layer bits modularTree 2.389770% 413 [c/i: 3.00 | hst: 11 | ex: 14 | h+c+e: 52.716] Total image size 17282 [c/i: 11.00 | hst: 45 | ex: 14 | h+c+e: 2143.083] Allocations: 378 (max bytes in use: 4.465085E+06)```

Disabling patches helped indeed, thanks!

-P 0 trims off 3 more bytes

yes

same happens with PNG vs JPEG on an image like that

at some point I hope we can have heuristics to detect this kind of thing, and use lossless by default when it is better than lossy

I mean you can of course just always try both, but that would slow down encoding a huge amount

also there can be cases when part of the image is best done with lossy and another part is best done with lossless

and we can do that - this is exactly what multi-frame still images are designed for

this is where jxl can really shine imo, because no other codec can do that atm

webp also has two modes but they cannot be mixed in a still image

avif doesn't really have good lossless

and of course jpeg / png are single-mode so they certainly can't mix things

when I have time, I'm going to try to make a quick heuristic to detect/extract parts that are better done with lossless (doesn't even have to be fully lossless, could do what we do now for text patches: quantize colors a bit, nobody needs 256 shades of gray for nicely anti-aliased black on white text, just a few shades is fine)

Back again to the QR code for a while: PNG 2,167 -> JXL 2,158. 9 bytes of a difference. Could JXL encode it even better?

QR codes consist of lots of squares, maybe they could be paletted or patched?

might be worth signalling a custom upscaler that is just nearest neighbor, then encode the 1:4 image (if that can be made to produce exactly the same result)

no way the encoder is going to try something like that though

Those are an exception, not the rule

You can encode the logo with VarDCT or lossy Modular

By the way here's that QR code, encoded at `-d 15`. It switches between patches enabled and disabled.

If we look at the QR code's structure...

https://upload.wikimedia.org/wikipedia/commons/thumb/1/1d/QR_Code_Structure_Example_3.svg/2560px-QR_Code_Structure_Example_3.svg.png

...it seems like the patch heuristics detected: - all 3 position blocks - only 2 alignment blocks - some lonely squares

Here's the difference between patched and non-patched version, made in GIMP.

possibly you could also create a funky palette that has multiple indices that correspond to white and black, in such a way that you can basically encode only the topleft pixel of every little square, and the others are derived implicitly: e.g. have index 0-6 for black and 7-13 for white, where you use 0 and 7 for the topleft pixels, the other pixels check if NW has a "bottomright" index (6 or 13), if yes then you have a new topleft pixel to encode (using a histogram that contains values 0 and 7 only, costing about 1 bit), if no then they make a diagonal gradient, i.e. they get value {0,8}+i+j at subposition (i,j) from the topleft pixel, which can probably be expressed in a small MA tree so it can be done with zero entropy

(the above is for 4x4 squares, the approach generalizes to other square sizes)

The current patches heuristic is only going to find patches close to the clean white background

I'm not surprised since I've seen your messages about it, I'm just making reference materials for the future when you finally decide to improve patches.

Is the QR code still working at d15?

Back in 2016, I was playing with QR codes a lot. If each module has 6×6 pixels and the code is saved to JPEG with Q 10 (just for the purpose of testing), it's still perfectly readable.

Why is there a face

Because I wanted to make something very special. And it worked – I became a Czech record holder: https://translate.google.com/translate?sl=cs&tl=en&u=https://www.mozaikar.cz/nejobsahlejsi-2d-kod-z-mozaiky-aneb-jak-se-stat-ceskym-rekordmanem/ 😜

Black/white is a pure luma signal with max contrast, so any codec/encoder will try to preserve that as much as possible

If you make the blocks 8px so they're aligned with DC, you won't be able to destroy them with jpeg / jpeg xl no matter what you do

I know. I used 6×6 on purpose to test readability.

7x7 or 5x5 might be slightly more challenging

I was concerned for readability because I was planning to make a physical mosaic of the QR code. So with low quality JPEG I was kinda simulating worse appearance.

https://www.html.it/22/06/2021/jpeg-xl

<@!416586441058025472>, maybe you can tell us what's going on there… 🙂

is copied from wikipedia italy

OK. The knowledge is spreading…

the site is pretty famous

it talks about javascript

those things

https://tipsitaliani.altervista.org/how-is-the-codec-jxl/

https://tipsitaliani.altervista.org/reason-to-use-jpeg-xl/

small blogging i did, i fixed now, if you want to add sources you can

i've read bluesword post, i was inspired by that

new blog post:

https://tipsitaliani.altervista.org/how-to-run-jxl-and-what-to-focus-and-which-encoder-at-what-q-prefer/

https://youtu.be/lG1aPFvUKBY

I left a comment to ask for English subtitles 😅

i enabled automatic captions from youtube settings and they don't appear

I assume a video needs enough views before they send it to the AI for transcription/translation

your video translated

his older videos have captions so you probably just need to wait 👍

It would be nice to have manual captions though, auto captions tend to be rather bad imo

the video is JPEG XL: The Next Generation "Alien Technology From The Future" by Jon Sneyers [ IMAGE READY ]

do you understand last captions

LOL ASAJ

This video covers basic information about graphical formats and features of the new JXL format. Nothing special.

There is also a Russian-language article about "JPEG XL would be Turing-complete" https://habr.com/ru/company/itsumma/blog/564370/

Even i, i would 0,95 bpp but is not convenient for the space to in every image

i guess 0.391 bpp - 1.024 bpp 0.808 bpp - 0.924 bpp is the bitrate range when jpeg xl can perfom good now

0.174 - 0.313 bpp is where avif perform best

My impression on jxl vs avif (given current encoders) is roughly as follows: - avif can do what q30 mozjpeg can do in 50% fewer bytes. It brings maybe 30% improvement compared to the previous generarion (webp) at this operating point (low fidelity, high appeal). - jxl can do what q70 mozjpeg can do in 50% fewer bytes. It is 30% smaller than avif and twice as fast to encode at this point (comparing encode speed at practical settings for both - of course they can all be slower or faster). So it does bring 30% improvement over the previous generation (avif) at this operating point (medium fidelity 'web image quality') - jxl can do what q90 jpeg can do in 60% fewer bytes. It is 50% smaller than avif and 3x as fast to encode. It brings a 50% improvement over the previous generation (avif) at this operating point (high fidelity web, consumer-grade photo storage) - jxl can do what q97 jpeg can do in 66% fewer bytes (3x smaller). It is 70% smaller than avif and 3x as fast to encode. It brings a 66% improvement over the previous generation (jpeg) at this operating point (very high fidelity photo archival)

At the q50 point, jxl and avif are roughly equivalent and are both 20% better than webp, 30% better than jpeg.

In lossless, jxl is better than anything else though lossless webp is still quite attractive in the 8-bit case because it has a good encode speed vs density trade-off.

The above are "my impressions". To make things more convincing, it would be good if we could back that up with benchmark results.

Does anyone have time/cpu power to do a comparison? <@111445179587624960> you did great work for lossless, maybe you could also try a lossy comparison?

One way would be to see what file size you need in various codecs to reach a certain Butteraugli score

For the highest fidelity point (q97, visually completely lossless), Butteraugli max norm is maybe the most relevant - the first number `butteraugli_main` returns

For the q70 or q90 point, the pnorm is more useful (the second number butteraugli_main returns)

wb what is your impression of this, only for autism people or something that people can use with libjxl v0.3.7-169-g1f7445a win_x64 2021.06.26 https://discord.com/channels/794206087879852103/840831132009365514/858261886499160074

interesting your comment thanks for being so explanative

Is still to choose qualities based on resolution, to make the encoder work different based on resolution a good thing or is better to consider artifact?

.... lossless usually is 42% reduction even with -s 9 -E 3 not that impressive yesterday i posted this

this being offtopic as is screenshots windows 11

For the web, what mostly matters is images that are not huge - smaller than 2 megapixels or so

you don't need a large amount of memory for those, unless you try to do a lot of encodes in parallel

you can just do encode, record filesize, decode, compute butteraugli score, record those to a file, delete the encoded/decoded file

or use benchmark_xl which does things in memory

i posted other settings much more complicated, i don't even know even if they work and if i can encode with that.

https://discord.com/channels/794206087879852103/840831132009365514/858287668571013130

jon probably don't agree

he say all images should be 2 mpx and weight 2 gb each

1000000 bpp

and not shoot with a smartphone

and not present any blurring

also the quality should be higher than what you can see

if you do the benchmark, you choose :). I recommend taking large images and downscaling them like 4x so even if they were not very high quality to begin with, they are basically lossless.

I could maybe Will try to make a script to do it automatically so it is not much manual work :smile:

I think the Eclipseo/WebP2 comparison is fine for that, although it would be nice to have a description and source code for how to do such comparisons for other people. Because encoders can update/improve quite often, it might also be a good idea to update/change the test dataset, my suggestion is to use different images from <https://unsplash.com>, although they are lossy but usually enough quality, especially if using 2x/4x downscaling, for art and anime sources I think it is possible to use some frames from CCA4 anime from Netflix - Sol Levante <https://netflixtechblog.com/bringing-4k-and-hdr-to-anime-at-netflix-with-sol-levante-fa68105067cd> <http://download.opencontent.netflix.com/?prefix=SolLevante/>

For sizes based on Butteraugli in my opinion this is a better option than the one based on BPG Qx, but this could be interpreted as a bias towards Jpeg XL (because it uses and tuned for this metric)

How many Cloudinary Credits do you offer as compensation? 😄

Could compare against butteraugli-tuned avif?

Heh, I don't have the power to hand those out, but I can ask

Another approach would be to take an image, compress it using different codecs at the fidelity you would want to use on your own website, then compare sizes.

does cloudinary support altervista italia

i don't pay altervista italia

so i do not know

Don't forget to share us your script 😉 I have some difficulty to use correctly the scripts of eclipseo ^^

https://twitter.com/stshank/status/1408840409355194371?s=19

FLIF has also already been replaced by Jpeg XL, as a format for storing rarely requested images? In addition, JXL can also be used for Jpeg <https://cloudinary.com/blog/flif_the_new_lossless_image_format_that_outperforms_png_webp_and_bpg>

We never used flif internally for storing rarely requested images

Jxl could perhaps be used internally for jpeg recompression, not sure if it's really worth it since it's our customers who pay for their storage 😅

Maybe an opt-in near-lossless jxl recompression when uploading big PSD/TIFF files would make more sense. With that you can save like 95% of storage and upload time.

Ooh, how good is JPEG-XL as a JPEG encoder actually?

Hmm, because without support in browsers I thought that's how FLIF was used (like Dropbox did for Jpeg)

Is it better than mozjpg?

Not by cloudinary. It's too slow to make that useful imo.

How do you mean? We don't currently have that in cjxl.

I see.

We didn't even implement forward ycbcr yet 😅

But I guess Cloudinary needs to support multilayer JXLs before this can happen. ;)

Yup, something like this: https://discord.com/channels/794206087879852103/803645746661425173/858416509780623460 https://discord.com/channels/794206087879852103/803645746661425173/858419637506015242

What is altervista

basically how people can create a public site without paying

is only for spanish and italian

and is basically wordpress

translated

and with all localizations you can download

and is of mondadori so books and berlusconi pizza mafia

sorry i'm reading nonciclopedia

Does Google search brings up your altervista site?

no

So is it useless unless you share its link to your friends?

I have written some scripts for benchmarking and something like "benchmark_xl" on rust to generate the data, but i can't get avif tune butteraugli to work. bash script runs the 'metric' tool for every png in folder, which encodes the image via cmd, decodes it to png, evaluates butteraugli score and writes everything to csv https://github.com/EugeneVert/image_bench/blob/main/plot.ipynb

this type the post did not makeit like the av1 10 seconds

no because i didn't have enough upvotes

or at least one comments that isn't mine

It's because of your links. I too had same experience when posting kernel logs on arch Linux sub reddit when using del.dog domain.

i will not do more spam

jon can choose content

cloudinary, (mega)thread for tutorial

and there is another admin called bitflag

basically reddit does racism

mai are you from Asia?

You could use netlify and a static site blog. That's what I do.

Also buy a domain

Nice

https://medium.com/codex/webp-avif-and-jpeg-xl-better-image-formats-for-websites-31df8e48c507

> For the time being though, the lack of browser support and VERY early state of the specification means I would hold off on even trying to support it. All my current tests show around four times the size of AVIF despite claims that it matches it. I don’t know if the tools I have access to for conversion are at fault, or if it’s just the bleeding edge nature of it. I’m hopeful, but I’m also not holding my breath in antici…. PATION. 🤔 > From this we can tell that for now, JXL is not worth even trying to deploy, but that’s because the converters and encoders are still in a very primitive state. In practice it is supposed to eventually match or surpass AVIF. Time will tell if this is true, but for now I’d say do NOT attempt to deploy JXL. Wait and see. Give it time to mature as a technology. It might be another dead end failed attempt by the JPEG akin to JPEG 2000, it might be the greatest format ever. We don’t know yet and the tools to give it a fair shake just don’t exist as of the time I’m writing this. 30 June 2021.

was just about to point that out, something's messed up there

> Lossless Source PNG: 6,664k > TinyPNG.COM : 645k > 5% Lossy JPEG: 2,000k > 15% Lossy JPEG : 1,174k > 5% Lossy WEBP : 1,127k > CloudConvert WEBP : 817k > “default” AVIF : 1,254k > “default” JXL : 4,561k > The “default” ones are that of various online converters, the size shown being the average of at least three different ones. I hope that's not his metric, cause that would be fairly ridiculous

It seems so, as well as strange conclusions about the maturity of encoders by the size of encoded images with default settings

what metric exactly are they using for the 5% lossy, and 15% lossy?

also not very useful if it doesnt show all of the outputs...

Yes, and let's not forget to add a death threat in the appendix. <:ugly:805106754668068868>

<:pepegun:659513552033415188>

what?

also isnt the default settings for avif very low quality

What I was saying is that we maybe shouldn't all go attack him on how wrong his testing methods are.

oh yeah of course

i thought you meant that he put a death threat in the appendix of his article or something

Yes, but I think one person to tell should be enough, no reason to mobilize the whole server. ;)

well i tweeted at him :P

<@456226577798135808> I understood what you meant. No issue with your English, just a little warning that there might be some people on a large server who could misinterpret something like that. But I'm generally not a fan of *promotion* to defend a product or company some like and other don't (even if the latter are in the wrong).

It seems very strange to me that you feel the urge to write an article about modern image codecs, yet at the same time you don't understand that lossy compression is about the fidelity vs bpp curve.

I wonder if we would make -d 10 the default instead of -d 1, he would think it's a great and mature codec now.

It can be even worse when such articles get more popularity and many people refer to them than other honest, detailed comparisons

I guess this article use jxl d1.0 s 7 and avif q24-26 s6 for default setting.

Also, the author mentions online converters, and there is no way to know what options were used, it could even be lossless, also jxl versions could be very old

Like: <http://libwebpjs.appspot.com/jpegxl/>

. Also: <https://kornel.ski/en/faircomparison>

"5% lossy" is also something weird to say. Does that mean q95? Does he think that q85 means 15% of the image is "lost" and 85% is "kept"? It really doesn't work that way...

> Compare images only at qualities you'd actually use. Codecs are optimized for real-world use cases and may perform very poorly outside sensible quality range. > > Choosing lowest quality may seem like a clever idea to make differences obvious, but actually it makes benchmarks irrelevant. It's like running a Formula 1 race in a muddy field: proves that tractors are faster than race cars.

kornel, I love you

That second paragraph is very much true. Looking nice at 0.1 bpp is good for tractors, but being great at 0.5-1.5 bpp is what matters for race cars.

https://tipsitaliani.altervista.org/what-is-jpeg-xl-status/

https://www.newscientist.com/article/2282648-streamlined-jpeg-xl-images-could-cut-global-data-use-by-30-per-cent/amp/?__twitter_impression=true

i can't read the whole article but are images even 30% of global bandwidth?

Images are 60% of the median web page weight

"Global bandwidth" is an exaggeration because of course netflix and youtube and games are a big chunk of that

Yeah, think video uses about 60%+ of total bandwidth

Guess "average website" would have been a better use

But for typical web browsing traffic, 60% for images is probably about right

Median website

The average website has 0.something videos

The median website has 0 videos

Hm, true I guess

Sadly I can't really take articles like that serious when there's a mistake like that <:cheems:720670067091570719>

Meh, I haven't read it yet, but it's not exactly academic literature anyway, might as well have a not-quite-correct sensational headline instead of a boring nuanced and correct title

ah they thought i was a creator of jpeg xl

haahah

and they decided to make a sensational title like wb said

sorry for causing this wb

i twitted 4 tweet in a jon sneyers post do i have permissions to do

You don't need permission to tweet, it's hard to understand what you mean though, at least for me

ah it wasn't based off my tweet or not? mystery

Nah it was based on an interview I did last week

maybe i don't want my things to be spread

Another 4chan discussion. I don't know how many this makes now. Might stop linking them from now on, as it is the same points, going in a circle, again and again.

https://boards.4channel.org/g/thread/82328540/the-web-is-saved-jpegxl

This was linked before

can they discuss anything without insulting each other?

It's 4chan, what else did you expect? <:kekw:808717074305122316>

Nope, this one is actually new

someone posted a screenshot

Where?

in this server

I mean exactly where, link to the message

there isn't

I’m not surprised, I’m just disappointed. 😁

seems like more agreement and less naysayers than previously

but kinda yes. I'd say posting these is still worth it, as usually coverage is just same jxl marketing material going in circles too

no webp2 would be integrated in google products, youtube etc

WebP2 is not going to happen anytime soon imo, and it will have to bring some real improvement if it wants to get adoption when avif and jxl are already out there.

Also, libwebp2 recently had many changes to the AV1 encoder So maybe they are considering the option of using AV1 instead of the entirely new format

For now yes (except that some parts are used as a basis for lossy WebP2), but if they achieve similar results by improving AV1 encoder, then maybe creating a completely separate lossy Webp2 variant will make even less sense

https://morioh.com/p/28d552f53163

coverage jpeg xl

yeah. pretty short and neat article

<https://reddit.com/r/science/comments/odtsoa/improvements_to_the_ubiquitous_jpeg_image_format/>

Wow, lots of comments too

Wee need to add windows binary in release tab on github, nobody will compile it to test it.

comments about jpeg xl download

DAMMIT

this font rendering a bit strange

are you on linux?

No, that's normal font rendering, I'm using Chrome in Windows

Looks like it's because this is a paywalled article, but it's still good that it has generated such a lot of discussion and popularity

works for me?

https://www.reddit.com/r/technology/comments/odtt1n/streamlined_jpeg_xl_images_could_cut_global_data/

Yes, but this is a fairly short review article, it's interesting when less in-depth and detailed articles (also with paid access) or blogposts can get very popular, when others can be almost unnoticed

It all depends on the size of the audience that these articles have. NewScientist is pretty big.

But, even with that kind of audience, any of the posts can be unpopular and unnoticed, like with just a couple of comments and low views

This is also one of the reasons why I would prefer to have someone else do the lossy comparison, because both comparisons from one person look more biased (besides I have been called a JXL fanatic several times already)

do you have something like scripts for comparisons you do

No, but for lossy I think it's a very good start for other comparisons (probably with some improvements and changes) <https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_07_01/index.html> But I haven't looked at the source code and don't know if all the necessary scripts are available

And I think <@!493871605408071681> knows better about that

There is a link to python scripts on that page https://github.com/eclipseo/image-comparison-sources

<https://www.derstandard.at/story/2000127956467/nach-fast-30-jahren-neuer-bildstandard-jpeg-xl-soll-jpg>

https://translate.google.com/translate?sl=auto&tl=en&u=https://www.chip.pl/2021/07/jpeg-xl-format-zdjeci-kompresja/

two parts article with Facebook and Instagram will be happy. They will be able to massacre our photos even more

https://translate.google.com/translate?sl=auto&tl=en&u=https://www.focus.pl/artykul/nowy-lepszy-format-plikow-jpeg-moze-ograniczyc-transfer-danych-w-internecie-nawet-o-30-proc international in polish language focus

<@!416586441058025472> finally some non-social-media coverage in Polish! Last articles exclusively about <:JXL:805850130203934781> in Polish were from 2018 and were really outdated... How did you find them?

google last 24 hours "jpeg xl"

i'm reading another one i'll post another comments when i read all

Thanks for the tip 😃

i search it many times

don't show all, you should download

the source is this https://www.wykop.pl/link/6177751/jpeg-xl-zmniejszy-ruch-w-swiatowym-internecie-az-o-25-30/

Who is Damien Carrier? Isn't that <@!794205442175402004>'s pic?

I believe it is

but cropped

Haha maybe they copy the picture from my google sheet documentation 😆 i'm not a developer.

https://twitter.com/petapixel/status/1412827728051535879

https://translate.google.com/translate?hl=&sl=de&tl=en&u=https%3A%2F%2Fwww.derstandard.at%2Fconsent%2Ftcf%2Fstory%2F2000127956467%2Fnach-fast-30-jahren-neuer-bildstandard-jpeg-xl-soll-jpg

this posted five times with even the translation in a .txt

I was searching for it in this Discord server and didn't find it, so I posted it.

It might be better to post only URLs and not .txt to be able to search and thus avoid repeated posts.

I clicked the link. But translation doesn't work. I had to use Fabians txt

...

Translation.txt is der standard site giga.txt is the comment in a polish like reddit from another polish site

There is another called ew.txt But i dont know the source

Im sorry

<https://www.reddit.com/r/explainlikeimfive/comments/odxmzg/eli5_what_is_jpegxl/>

i'm making my comment also

how is so far?

too complex, i want to add more about the quality.

i'll remove filters don't use

BACKUP of all comments+mine

i don't think the comment is too long.

maybe the mod think is

jpeg xl encoder can use some super complex magic🪄 squeeze your image, image quality still look great and file size less than old format.

thanks for feedback deleted the part filters

fabian is p good entropy source ngl

Dont understand

For a subreddit like that, you should refrain from specifying any encoder options. No one is going to explain encoder options to a 5yr old.

People are focusing more on the lossless jpeg conversion

Vardct lossy and modular lossless are really good

Vardct I don't know but it's much better than jpeg

Modular I've heard figures of 30 to 50% better than optimized PNG

yeah, sometimes i wish they wouldn't as much, or at least explain it better. i've had to explain to a couple people already that not _every_ jxl file can be converted losslessly into a jpeg 😨

It's not the most impressive part of jxl IMO

If you're looking for lossless jpeg compression only, lepton is ~1% better than jxl (tho I think it's slower)

Someone in $benchmarks claims lepton is faster than jxl

maybe to compress

(but that's likely just an artefact)

to decompress (to bytes or to pixels) should be the opposite

well lepton files can't be opened directly by anything. for a website i'd rather use lossless jpeg->jxl since for clients that support jxl i can serve them the jxl directly, saving cpu time (for me) and bandwidth. maybe lepton could work if it's like an app where you could ship a lepton decoder.

Lepton is worse than jxl for any typical uses for an average user

It's purpose built for servers serving jpegs and storing smaller lepton files and or archival

In the end IMO it's just an open sourced component of Dropbox, and it doesn't seem to be growing much beyond that

https://boards.4channel.org/g/thread/82380648

o ye i remember this one but it wasn't like fully jxl centered so i was like whatever

<:Thonk:805904896879493180>

If JPEG XL is adopted by web browsers without concurrent adoption in image viewers, comic/manga readers, operating systems, and editing suites, they will surely hate it too.

yep. universal adoption is important for good experience

Agreed. Feel free to do feature requests in all software that deals with images!

http://personal-view.com/talks/discussion/25819/jpeg-xl-another-guys-want-free-income

<:WhatThe:806133036059197491>

https://ieeexplore.ieee.org/document/9467224?denied=

Behind a paywall though, does anyone have access to the article?

<:Thonk:805904896879493180>

https://www.fotopolis.pl/newsy-sprzetowe/programy-graficzne-i-upgrade-sprzetu/34961-jpeg-xl-czy-zdetronizuje-jpeg-a-to-najbardziej-obiecujacy-kandydat-na-nowy-standard

I think he is confused and compares the 20% jpeg recompression gain with HEIC's claimed 50% gain

But 11.

He read up to 10, put something in bold, and arrived at a conclusion

https://m.habr.com/ru/company/itsumma/blog/564370/

Have these peeps ever encoded an image using an HEVC encoder?

Like, most of them are not properly tuned for intra...

Not all people even know how to change quality in encoders

If you have an iPhone, you can get HEIC easily

deepl.com is a VERY good translator.

to me it doesn't look about original

he just doesn't like jpeg xl

and think is only a derivate of jpeg

and is fine as opinion

even i, don't like jpeg xl images at 33,2 kb

ah i were using 24/02/2021 encoder

and i weren't resizing

https://youtu.be/hPhWOSCFF_A?t=850

I'm pretty sure green lantern hacker from custom firmware could add jxl to canon quickly 😄

https://www.libertyrpf.com/p/154-video-game-pricing-amazon-book

https://www.dpreview.com/news/5829652105/jpeg-xl-image-format-promises-smaller-files-backwards-compatibility-and-more

lots of pro-HEIF comments 😨

if I point to the bit of equivalence theory that I mentioned in the help for `--photon_noise`, I think it will possibly enrage a few

some people on the site are not very keen on equivalence

(https://doi.org/10.1117/1.OE.57.11.110801)

Bruh, do these people even understand how HW decoders work?

nope

Like, good luck HW decoding tons of intra only 4:4:4 images <:kekw:808717074305122316>

random related questions: any idea of the power usage benefits of using CPU vs GPU vs an ASIC for decoding images?

There's only one sentence about it not using hardware. Not sure what you mean.

probably the comments

for example https://www.dpreview.com/news/5829652105/jpeg-xl-image-format-promises-smaller-files-backwards-compatibility-and-more?comment=9711955227

It depends on the platform and how easy software decoding is and frame resolution. For example, in video, on a dekstop with a modern CPU and dedicated GPU, at lower resolutions(1080p-1440p), it is often more efficient to actually software decode rather than to HW decode since the ASIC on the GPU needs lots of bandwidth, and as such, the memory needs to be woken up and clocked up, which consumes a lot of power vs just the CPU. For images, it is likely the same thing: it is usually more efficient to use the CPU to load tons of little images at once than to try and use the HW decoder if there is even one. For very large images, that might change. For mobile devices, it is usually better to use an ASIC due to much lower base power requirements during encoding. As for decoding, it depends on the size of the image again, but on a phone with lots of large pictures, it might be quite useful to do the thumbnails on the CPU, but aid the main image rendering by doing it on the ASIC. As for CPU vs GPU, it depends on how demanding the processes are and if zero copy can be used: decoding a normal AV1 video for example is quite easy on a good CPU. Add in noise synthesis however and you become single-threaded bottlenecked. In that case, it is actually worth it to use the GPU over even a SIMDed implementation of grain synth. Stuff like CDEF and loop restoration incur a too high latency penalty/performance to be worth doing on GPU. On weaker CPUs, such as on the Xbox One, it would be worth it to just accelerate most of the most decoding processes onto the GPU if possible since the CPU is just anemic.

This would likely be the same for images: if your CPU is weak or you have very large images with demanding features(such as noise synthesis), ask for help from the GPU.

at least in theory, most codecs I am aware of should be very well suited for running on GPU

(except perhaps some aspects of noise synthesis)

most images end up on the GPU sooner or later anyway

I'd expect (from random estimates I found around on the internet) that on mobile devices moving the post-entropy-decoding stages to GPU would reduce power consumption 5-10x and 10-100x improve latency (of that chunk)

I'm not sure how an asic would compare

(I'm talking about decoding only)

The main problem is if the latency penalty is worth the extra throughput. For example, on my 3700X, using libplacebo for GPU accelerated rendering of AV1 was actually no faster or slower while consuming more power because the GPU was being spun up. Well, unless grain synthesis was thrown into the mix.

readed all

mhhh that sounds to me like subpar gpu implementation (although IDK much about AV1 details)

On mobile devices where CPUs aren't as overpowered and dedicated GPUs are not a thing, it would be worth it indeed.

From what I know about dav1dplay and libplacebo(using VK), it is actually very efficient. The main reason that the tradeoff was not worth it IIRC is that the less demanding parts like CDEF and loop restoration that could be easily ported to GPU compute were already so fast in SIMD that adding an extra step actually made the decoding less efficient.

so I don't know how the GPU implementation you are talking about works, but ideally, I'd want a GPU impl to just never communicate with the CPU once it gets the initial data...

(well, except to say "I'm done!")

if you need to do CPU -> GPU -> CPU (for CDEF/...) -> GPU (for display) then it's not going to be fast, yes 😛

I think video is a bit different than images in terms of the advantages of decoding on the GPU, unless it is a set of many identical images in terms of parameters and resolution

why would that matter?

And this could be the same problem as for example for WebP https://youtu.be/MBVBfLdh984?t=705

hardware != GPU

I see. That might be why then: the libplacebo renderer is not a full renderer replacement like the AV1 Xbox One GPU decoder. It does do zero-copy processing, but only at the end of the pipeline for CDEF/LR/grain synthesis.

Now, if only I could actually build the Xbone implementation of that, we would go somewhere.

And as far as I know, at the time there were already ASIC VP8 decoders and anyway WebP is still decoded only by software

yeah I'm not that convinced about hw decoding for images either

but there are different opinions... and also it's true that webp is a lot faster than avif/jxl in software, so there's that

Also AV1 as a video format could be less power consuming on Xbox and such an implementation makes sense but I'm not sure it would be as beneficial for AVIF

https://twitter.com/PascalMassimino/status/1286200838311022592

https://twitter.com/PascalMassimino/status/1207822279826120704

BTW Veluca, if you were to build a GPU assisted decoder, please make it using VK Compute 😅

Why do people like heif so much

Are they ignorant entirely of it's license and technical shortcomings?

The visible 512x512 boundaries on Apple's implementation should be enough to turn off anyone from heif

It should be on retina

If you zoom it should be on small screens

Heif also isn't a lossless solution

many were saying it would be easy/free to implement using a hardware hevc decoder, never mind that firefox and chrome don't and probably never will play hevc

If you're talking about a camera format, then avif is better

It can do lossless?

I would wager it's not much better than png

ugh the comments have gone further downhill