JPEG XL

<https://i.4cdn.org/g/1631379073887.png>

you should tell them that

I do not write anything on 4chan, twitter and the like, but sometimes I come across some discussions that I can read

Also, many encoders in comparisons on certain sets (like photos at GDC) were very much optimized only for those sets and did not show similar results on other sets, even photographic ones, and were ineffective on artificial images, except for some like EMMA and BMF

So, all intra? LMAO

if they're different resolutions then technically this still works but only for some codecs

most inter-codecs won't work with this

which defeats the point

but sicne htey're anime screenshots I can guess they're mostly 1280x720 or 1920x1080

which means that they could just sort by resolution

and yes they could take 1920x1080, concatenate them together, and compress with something like H.264

but since the shots themselves are all different you lose most of the value you gain from lossy video, which is inter-prediction

the only way this works if you use ffv1 but dont' set `-g 1` in ffmpeg

i think it's the container that contains the variable res

i believe mkv/webm supports variable res

but ofcourse not a single encoded stream

i dont think any encoder supports that

but if it's just an intra-only video based image container/format, avif basically does that

and hey if it's all in a single file you can save space on the container headers

the advantage would be using something like ffv1's non-intra capabilities

ffv1 has a quirk where the prediction is all intra but it doesn't have to flush the arithmetic coder between frames

so you can have ffv1 "p-frames" so to speak

which are really I-frames but they're not self-contained because the arithmetic coder is not flushed

for archival this is discouraged, which is why they suggest `-g:v 1`

(`-g` sets the GOP size. setting it to 1 frame makes it truly intra in this case)

Hmm, WebP2 has about the same compression as JXL in this image, most likely because it also uses tiles/groups, while WebP encodes the whole image Although, WebP2 has more options for tile control: `` -tile_shape <int> ...... tile shape (0=128, 1=256, 2=512, 3=wide, default=4)`` Also, for JXL even larger group sizes didn't make sense, because the efficiency wouldn't improve noticeably, but the memory requirement would increase and parallelization wouldn't work?

We have -g which is basically the same (0 is 128, 1 is 256, 2 is 512 and 3 is 1024)

The largest group setting is 1 MP per group

So if you have an image that is more MP than you have cores, it should still benefit nicely from parallel decode

Yes, but I mean even larger group sizes or the full width or even the whole image Although, perhaps it would make sense to have an option to encode the whole image or by width, but only for something like fast modes with LZ77 (but the format can no longer be changed) or with the current group sizes can theoretically achieve the same compression?

We didn't want to allow full width because we wanted all bitstreams to be in principle decodable with bounded memory requirements

(Though when Squeeze or Delta palette are used, that's likely not really true anyway)

Patches don't care about group boundaries though, so if there's repetition, it should be possible to use patches instead of having to rely on full-width tiles and lz77

Polish Wikipedia article is about to get a bit of a rewrite 😃 https://translate.google.com/translate?sl=auto&tl=en&u=https://pl.wikipedia.org/wiki/Wikipedysta:ZiemekZ/JPEG_XL

https://www.meetup.com/Toronto-Web-Performance-Group/events/280848011/

> A PNG retrospective by Thomas Boutell (@boutell) > The web's got so much interesting history, esp with the current group of *legacy* image formats. Thomas will join us to provide a historical perspective of the earlier days of the Portable Network Graphic and so much of what happened in its emergence.

I was a teenager when Burn all GIFs! happened and PNG was created basically overnight, this was a very cool thing to happen and a major milestone in royalty free image formats

See also my fun post celebrating PNG's 20th birthday (Google Translate from Czech to English. Note that the string "And to make matters worse" would be better translated as "Furthermore".): https://www-petrdiblik-cz.translate.goog/gratuluju-k-20-narozeninam-png/?_x_tr_sch=http&_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=cs&_x_tr_pto=nui,elem 😜

https://www.omgubuntu.co.uk/2021/09/thumb-3-12-avif-heif-image-support

Interesting that there are brief descriptions of AVIF and HEIF, but no Jpeg XL

It's mentioned in the title, but yes. I guess there's not much user demand for viewing jxl files yet, given that you'll not likely encounter them in the wild anywhere atm.

Because jxl is added in title after someone asked for it on comment section.

<https://trashbox-ru.translate.goog/link/what-is-jpeg-xl?_x_tr_sl=ru&_x_tr_tl=en> <(https://trashbox.ru/link/what-is-jpeg-xl)>

<:Thonk:805904896879493180>

> Looked at all the pictures in tiny size, my IMHO So again, the most common opinion is that only the smallest size is the best quality indicator > And in order to decode quickly, you need to use hardware decoding, I don't think that the speed of 8k60 fps is 1990 mp/s (nvidia, AMD video cards and new intel graphics) and 4k60 fps - 497 mp/s (phones with mediatek dimensity 1000, 1100, 1200) to whom -that's not enough. > Perhaps according to different Jpeg XL metrics at the avif / heic level. > Perhaps by the difference between the original and the compressed it is even better than avif / heic. > But this is not an indicator at all, I don’t look at the metrics when I look at pictures on the Internet, I also don’t see what the original picture was and, accordingly, how much compressed it differs from the original, I don’t know either, so visual quality is needed, and there are clear leaders. avif and heic. > And by the way, in heic it seems like they should bring in a new h266, then it should be better in quality than avif. <:Thonk:805904896879493180>

And the sad thing is that this commentary is basically a compilation of the most popular opinions about the format from people who are superficially familiar with these formats, but without any in-depth details

Ugh

Well it is true that avif/heic look nicer at the very low bitrates, and it is also true that it's just easier to see artifacts at those bitrates, so I understand why people would think that way...

Even within the JPEG committee there are some people who think that way (mostly video people who also participate in MPEG, but still)

<@826537092669767691> phrased it best: "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."

(from https://kornel.ski/en/faircomparison)

Pretty nice to see translated versions of that

I remember spending a lot of time on designing and discussing that diagram, trying to find a good balance between detail and overview

I'm quite happy with how it turned out, but I dunno how useful it is for someone new to jxl

(to me it all makes perfect sense and is perfectly clear, but I've been knee deep in jxl for years. I wonder how that diagram is seen by someone who never heard about jxl)

Encoded avif in Photoshop? Is it possible. .......

I think so, using plug-ins

Ah. This one.

https://github.com/0xC0000054/avif-format

I hope someone makes plugin for jxl too

novomesk ha ha

Translated, but lossily compressed. Where is it from?

Is it Russian? It's a good starting point for a Russian Wikipedia article… 🙂

I think that if someone has at least some knowledge of raster formats, then the diagram is quite understandable. And it's not always needed to understand everything from every diagram, so no problem here…

Yeah, it's Russian. At one point I wanted to create a Russian article using Wikipedia's auto-translate feature, and then lazily edit to make it readable. But some user already started the auto-translation and didn't finish it, and Wikipedia won't let me start it again. It's unfortunate, but I don't have the effort or time to do it manually. <:PepeSad:815718285877444619>

To be clear, this image isn't translated by me. Perhaps the author will create a Russian article as well, who knows? 😄

This is a content translation tool, not just a draft. I believe it can transfer the entire article design and you only need to edit the text. Just editing the text without rushing was fine with me, because I didn't know how serious I was ready to get about it. Now the article has become somewhat more complicated, that I no longer see myself as competent enough to do it.

BTW, I am native Russian speaker.

Privet comrade <:WhiteFoxSalute:689481667412623385><a:TheOnlyWay:783867474936201246>

Salut, tovarisch ☭

https://www.s-config.com/jxl-jpegxl-and-the-web/

that's an... interesting... testing methodology

Indeed.

Using default cjxl lossless, I get 10kB with that fox logo 😛

Especially with the desire to use only PNG-like images > This is a massive set-back for the image format wars because if these new codecs treat everything as if the file was a photograph, instead of a screenshot, or a vector with limited colors. Then they’ve lost before the war has even started!

" avif cleans jpeg artifacts so it's good"

and testing quality on an already-q80-jpeg is... uhm... questionable?

To be fair, isn't JXL supposed to be good against generational losses?

Jxl to jxl generation losses...

From what I'm seeing, the JXL copy looks the best since it keeps the image the most unfiltered.

Actually <@!263309374775230465> very interesting that he didn't use the lossless JXL to JPG mode 😛

This is even something closer to generational restoration

if you have a q80 jpeg and want to avoid generational loss, you very likely need to either do some filtering on it, or to use lossless JPEG recompression

> - My WebP Bintu-Logo.png.webp is coming in at 31KB! Double the size using the flags -q 85 -m 6 -pass 10 -o. Using CWebP version 1.2.0 > - AVIF Bintu-Logo.png.avif cannot beat PNG and comes in at 20KB using flags –min 0 –max 63 –minalpha 0 –maxalpha 63 -a end-usage=q -a cq-level=18 -a tune=ssim -s 0 -j 1 **also using CWebP version 1.2.0** 🤔

> We’re flexible! We’re willing to try almost anything to make this work! (No, not -q 100 or “Just go lossless” that defeats the purpose unless you can prove yourself against others of the same if not less settings!) <:Thonk:805904896879493180>

Sometimes some knowledge about options and formats can be even more harmful than complete ignorance, because trying to do encoding better than the default settings without understanding how things work leads to results like this

i enjoyed this post

https://c.tenor.com/ZFc20z8DItkAAAAM/facepalm-really.gif

We really need some people to blog about jxl who have a somewhat better understanding of how to evaluate a codec

confusing when lossless on the png they show gives half the size of the png

i think i would prefer lossless with less size than lossy with more size <:Thonk:805904896879493180>

These "which encoder does the best job of cleaning up a q80 jpeg" comparisons are really cringe

Also this (and also the not-so-rare opinion that the speed of encoders does not matter) > Of course much faster then AVIF being the slowest in some cases taking almost a minute to encode. (Or 5-10 minutes for that animated GIF above.) But at the end of the day is that really important? I have a multi-core VPS that idles at 5-10 percent most of the day. With the way the Cron.daily file works is you have 24 hours to make the very best file

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

to me the job of an encoder is always reduce file size

jxl is not making miracles

though he didn't used avif 02 august

> JPG to JXL conversion > ...we’re playing with a legit 8-bit/channel jpg... > Each of the images were decoded BACK to PNG files using their native conversion program for making the file in the first place. dwebp, djxl, and decavif. Then, they were merged using a graphic program and saved as a lossless 24-bit PNG for you the reader to look at. 🤔

yes

without lossless transcode

Makes me wonder if he does it always like that: save original as jpg, then convert jpg to webp/avif/jxl

right

also jxl isn't a line detector

it doesnt' use splines

Nope

If you give it (the pixels of) a q80 jpeg, then it will probably spend a good fraction of the bytes on reproducing artifacts

Since dct artifacts in YCbCr 4:2:0 are kind of expensive to encode in XYB

> You’ll see the JXL actually made it MUCH WORSE with an 85 quality level! Meaning that when it comes to ‘quality’ JXL is using a different scale then native JPG.

https://c.tenor.com/ibwfTRYbgocAAAAM/facepalm.gif

And yep, It may be useful to write some review blogpost about encoding in JXL and how it works for different image formats and what encoding options/modes are better for certain types of images, with examples of why some things don't work or give bad results

That selection of images, sigh...

A basically black and white ex-svg, a low color non-photo animated gif, and a q80 jpeg with mostly non-photo content...

So basically all three are non-photo, and yet he used VarDCT mode...

I guess we need to make cjxl more foolproof - and make it detect such cases and try something else there or at least show a warning saying "you may want to try some other setting too on this image"

Yep, and which again shows the need for something like `separate` option (preferably enabled at least at slow speeds by default), when the encoder can select the correct mode automatically, sad that it was not so easy to implement

Or maybe it's possible to detect non-photo palette and similar PNG images to encode them in lossless by default (instead of `-d 1`)?

https://cloudinary.com/state-of-visual-media-report

Nice, they even quote you! <:BlobYay:806132268186861619>

https://socialcompare.com/en/comparison/image-file-formats

The table indicate no animation support for webp. I think it should be corrected.

yes, also it says no lossless which is also not quite correct

i'll make an account there and suggest some corrections

And transparency

https://samjcreations.blogspot.com/2021/09/plugin-file-jxl-pour-gimp-210-bits-win.html

made a bunch of corrections to that table

https://www.stereovideo.cz/2021/09/27/jpeg-xl-novy-format-pro-kazdeho/

Do you understand Czech?

No, but google translate does

Kind of

The backwards compatibility thing is something we need to explain better, because it looks like people are assuming jxl will just work in old jpeg decoders and that's of course not true.

Add that info to Wikipedia?

updated info version for es and it wikipedia

en was already updated by one user

https://boards.4channel.org/g/thread/83664774/jpgxl

"JPGXL" 🤨

It's either "JPEG XL" or JXL or jxl

It's also "JPEG-XL" and "XL"

the annoying thing about the official name, JPEG XL, is that - It has a space in it - It looks like JPEG XR - It looks JPEG extra large

so I prefer jxl

have the people complaining about no hw decode actually tried decoding jpeg xl in software?

- It looks like legacy JPEG

i like jpeg extra large

> >>83664774 (OP) > >Image dimensions of over a billion (230-1) pixels on each side > Fuck 4K/8K, this format is ready for 1073741K OLED tvs. > >Up to 4100 channels i.e grayscale or RGB, optional alpha, and up to 4096 "extra" channels > You can literally encode the color from space in JPEG XL. > >Support for animated content > Sex gifs now considerably smaller. > > Dare I say absolutely based OK, 4chan is right this time <:kekw:808717074305122316>

>4chan is one person

sometimes it might as well be

well it's obvious there's many people of many differing opinions

it's almost like it's public and on the internet

that thread is still going on heh

JPEG XL mentioned in the Library of Congress's Digital Preservation section: https://www.loc.gov/preservation/digital/formats/fdd/fdd000536.shtml https://www.loc.gov/preservation/digital/formats/fdd/fdd000538.shtml

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

> webp is super fucking gay <:YEP:808828808127971399>

i swear i've seen this thread before

I'm moving the jpegxl.info page to https://github.com/jxl-community/jxl-community.github.io

so it's a bit clearer that it's a community website, not an official libjxl page

that way we don't have to do the google CLA thing

and we can more easily put stuff about jxl there without it necessarily have to be tied to libjxl or without it looking like it is Officially Approved by the libjxl developers

https://github.com/hohMiyazawa/libjxl.github.io

<@!792428046497611796> <@456226577798135808> is it OK if I add a CC-BY license to the jpegxl.info repo?

also I just copied stuff to the new repo, but I couldn't figure out how to keep the commit history when doing that so it's just a fresh copy

sorry about that

i think you can just take the old files and change the git remote

i think you can even do that now

and force push to overwrite the history

ah, I can try that

done

that looks better

Did you accept all hoh commit

Or he first should do a merge request to new repo

accepted all

Probably?

if you object to your contributions getting that license, you should say so, then I guess your commit should be reverted 🙂

I guess adding one `<wbr>` block isn't enough to be able to claim any copyright on that commit. 😄

ok seen

No problem here… 🙂

https://linuxfr.org/news/sortie-de-gimp-2-99-8-version-de-developpement#toc-am%C3%A9lioration-de-la-prise-en-charge-des-formats-de-fichiers--jpeg-xl-psdpsb-et-autres

It is a French translation of https://www.gimp.org/news/2021/10/20/gimp-2-99-8-released/

oh, right, hadn’t realized that they had just directly translated it

this is what popped up in my Google Alerts :p

thanks

https://youtu.be/cY5QNN946QI

GIMP 2.99.8 test: https://www.youtube.com/watch?v=LVK64IT1Jq4

Looks like this person thinks qN means exactly the same thing in all codecs and jxl cannot be compared to other codecs because it uses distance...

If people reason like that, and just do q80 in all codecs and see which file is smallest, they will reach very wrong conclusions

specially considering that Q80 wont' even be the same quality for encoders which do actually use it as a quantizer

https://it.wikipedia.org/wiki/JPEG_XL

it was updated

Version number and software big clean up

you can add to spanish if you ae (are) spanish

æ

"We're very fortunate that the majority of our users are using modern web browsers, so we can serve images in formats like JPEG XL and AVIF to users through a Workers script" https://blog.cloudflare.com/developer-spotlight-nodecraft/

JPEG XL even? 👀

https://discuss.pixls.us/t/jpeg-xl-file-format/25925/22

https://www.ctrl.blog/entry/bitrot-avif-jxl-comparison.html

that log-log plot is terrible to interpret, it should have been some sort of cumulative plot

bitrot resistance is something interesting to consider, but I'm not sure that it's a fundamental job of data compression format; it might well be a job of data *container* format, though (and JPEG XL uses a container, so...)

I think it should be the job of the storage mechanism, either file system or physical device

Playing whack a mole with various file formats vs. just handling it at a lower layer

I agree, but most people don't care (or even don't know) about bit rot so it's still worthy for containers to have some measure against that

most consumers still don't have ECC RAM for what it's worth for example

Yeah, resiliency is good, like how JPEG has restart markers, or UTF-8 can re-synchronise in case of a byte error, both of them being provided by the "container"

But with JXL being group/frame based, it should offer similar resiliency, failing to decode entirely would just be a current limitation

currently the jxl decoder detects and aborts on corrupt input - so it just fails instead of showing what it could show

I wonder how he made it not fail on all corrupted inputs

it shouldn't be too hard to add a decode option for "don't check ANS final state, just show whatever corrupt stuff you have"

that thumbnail is pretty <:BlobYay:806132268186861619>

Why no example images for cases that managed to decode ;_;

it's at least easy at compile time - I believe we even do it for fuzzer builds? (and if we don't, we probably should)

ah, we don't, and that's bad

https://github.com/libjxl/libjxl/pull/925 <- that patch should make $many things not fail

https://jpegxl.io/articles/jpegxl-allrounder/

Heise

https://www.bullfrag.com/all-about-the-jpg-format-and-comparison-between-jpeg-jpg-and-jpeg-xl/

b o t

<:Thonk:805904896879493180> I don't remember JPEG supporting RGB.

Anyway, it is a bot article <:kekw:808717074305122316>

Why do bots write articles now

Articles that don't make much sense

Who wants to read that?

Anyway, yes jpeg/jfif supports RGB, the ycbcr is optional. Jxl can also recompress those jpegs.

It's not great for density, since it does no color decorrelation at all then

But it can do slightly higher quality since R and B don't lose a bit of precision in the color conversion...

yes, it's SEO spam. but sometimes the articles are written by a low-paid worker in a third-world country which is often indistinguishable from bots

could you check this commit

https://en.wikipedia.org/w/index.php?title=JPEG_XL&diff=prev&oldid=1060735386

i deleted a , in the date

ah is called comma

the comma there is correct

So should be re introduced

Anyway to me is an error

Just use "25 December 2020"

In this case comma is not required

And it is more logical order

Wikipedia itself uses this format, as you can see on this page:

Latest revision as of 09:54, **17 December 2021** (edit) (undo)

Did it myself 🙂

As far as I can see, both date formats are already used on the JPEG XL page

i agee

with evey font eve

the comma make supe uneadable

but i'm not english

something something spoken english

so i will accept adding adding on esp evething

25th of december, 2020 december 25, 2020

is ponouned twentyfifth

twentyfiveth

how

the same way 1st isnt onest

ok

https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers#Dates,_months,_and_years

They accept both formats.

But the "25 December 2020" format is listed first 🙂

2020-12-25 is the only format what makes sense

you wouldnt say it though

Dates are confusing. Dec 25 is not the same as Oct 31 when they're dates.

Hex 19 is a less ambiguous way to write that number

thats actually how i say dates because i cant remember month names

https://it.wikipedia.org/wiki/JPEG_XL

i corrected two times see history

for those who asked gimp i wont' add until is in stable

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

who doesn’t like to share their photos as 50 MB files.

https://www.developersumo.com/2021/12/29/jpeg-xl-il-nuovo-standard-per-le-immagini-digitali/

26 minuti fa

https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c23

CEO of SmugMug & Flickr now in support of JXL!

I *somewhat* understand why they locked it. The last few posts were getting spammy... granted they could have just marked them as not relevant.

https://twitter.com/cloudinary/status/1481707613255569408?t=7lHSoIuBHdhzCSI_1ng-gg&s=19

Cloudinary twitter account did a thread on jxl, it could use some retweeting and stuff

one of the tweets [<https://twitter.com/cloudinary/status/1481707618766835713>] links to this article [https://www.newscientist.com/article/2282648-streamlined-jpeg-xl-images-could-cut-global-data-use-by-30-per-cent/] which i can't read in full but i'm very skeptical of the headline claim and beginning with "Improvements to the ubiquitous JPEG image format" is not a good sign

ah, you mentioned that article here https://discord.com/channels/794206087879852103/803574970180829194/861545772318720021

Yeah, weird that they forwarded the misleading claim. Or, I guess not weird in marketing.

Maybe I should have complained

It's not _that_ far from the truth, though. Of course "global data use" is not true, considering how much data goes to video streaming, gaming, etc, but for median web pages it is kind of true. The median web page has zero videos and ~27 images, and ~60% of the transferred bytes of a median web page are in images, which can actually be 50% smaller with jxl.

its distance from the truth is equal to the difference between 30% and the amount that jpeg xl will actually cut global data usage by

What does "global data usage" actually even mean?

Does it include anything transfered digitally over a distance of more than a few meters?

Does it mean "data" as in "mobile data", i.e. bytes transferred over 3G/4G/5G that are counted as "data" (and not voice or text)?

I have no idea what interpretation to give to a phrase like that

But if it's a definition that includes video, even if only video served via websites, then jxl is likely not going to make a big dent in it

Also, if the past is any indication for the future, it is unlikely that better compression will actually lead to less bytes being sent

It is more likely to just lead to more and higher fidelity images

i'd say all data that travels over the public internet

Do you remember that?

Now English Wikipedia article got the exact same big overhaul of "Technical details" as I did in Polish one 😃

https://en.wikipedia.org/wiki/JPEG_XL

Thanks i will do for italian

But there isnt a reason to update now

Jxl isnt popular in Italy

https://moonvy.com/blog/post/2022/next-generation-Image-format-2022/

Aren't AVIF and JXL current gen?

What is a generation anyway

For a web that's stuck on jpeg, png and gif, probably pretty fair to say next generation :p

Modular fairs better, that's q 70

file size?

Larger unfortunately, 151731 bytes

If I try target_size to 133KB, it ends up using close to q60, and the artefacts are rather noticeable

The source picture I found on Twitter, which I ran through jpeg2png

Depends on the content, ideally the encoder would switch between them as needed (Which iirc was the goal of the `--separate` PR)

I don't trust any objective metrics. None of them correlate very well with subjective assessment. I made ssimulacra and I designed it to be useful for jpeg, j2k and webp. It was calibrated/validated for those codecs (at least, for the encoders available 6 years ago). To evaluate new codecs/encoders with it is a kind of extrapolation that is not really justified.

For slightly larger size, VarDCT can also give better results than VarDCT.

For some DCT worst case sample, separate option also can reduce file size inflate issue(avoid DCT worst case). (av1 have DCT mode and palette prediction mode)

i love this part in change calibre font

https://www.theregister.com/2022/02/17/microsoft_ans_patent/

oh fucking hell

didn't we go through this with google

Yes, but Google is reasonable.

Microsoft is not.

Well good luck to Microsoft if they want to claim that their patent covers the use of ANS in JXL

https://github.com/google/pik/blob/2fb44c4834348392d0401ad9bab7cd314d85241e/ans_encode.h

the jxl ANS is basically the same as that, and that code was put on github in 2017

It is on Github, yes?

in before MS claims that since it is on Github, it actually belongs to them.

Haha

https://chromeunboxed.com/jxl-jpeg-xl-new-image-file-type-chrome/

> a file format that maintains a better image quality than the standard JPEG while also keeping the file size smaller with a faster encode/decode to go with it. Is this true though?

Anything about quality and size, yes. Encode speed? Depends on settings. Decode speed? Depends, but in favor of JPEG.

The author seems to indicate that you get all at once, and I just don't think that's been demonstrated.

IIRC JXL can make better use of parallel decode for large images. I don't know if that is implemented though.

JPEX XL decode speed also depends on how fancy the encode is somewhat. A `-e 3` image (generally) decodes faster than an `-e 9 -I 3` one, as it uses less complex bit stream features.

Though in a web usecase the improved density usually makes up for it.

Single-core, jpeg decode is certainly faster than jxl

Multi-threaded, jxl decode can be faster

When we make more optimized decode paths (e.g. using int16 instead of float32), probably we can make single-core jxl decode not that much slower than jpeg decode, at least in some conditions (vardct without extra stuff like epf, patches or noise)

i wonder if libjxl decode is faster than ijg jpeg? not that anyone sensible uses that nowadays

It probably is, at least on avx2 cpus

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

the JPEG -> JXL lossless just takes the JPEG quantization and re-encodes them using JXL's entropy encoding, pmuch

and attaches an extra box to allow reconstruction of the original JPEG file in a bitexact way

skipping the JPEG step in advance and encoding directly to a JXL that can be losslessly "reversed" to a JPEG doesn't gain you anything over just encoding as a JPEG and then using `cjxl --strip` or whatever the thing was

https://jpegxl.info/jxl-architecture-lightbg.svg < There's the "JPEG Compatible" bit, taken that to mean you're basically using the JXL encoder as a more accurate JPEG one, with none of the fancy features

It would save you time, particularly in I/O overhead.

you could always mitigate that with the libraries

encoding to ram with mozjpeg

https://www.youtube.com/watch?v=gWy96OXXVNU

Waifu2x-Extension-GUI update <https://github.com/AaronFeng753/Waifu2x-Extension-GUI><:chad:862625638238257183>

~~Totally didn't see I posted it in the wrong channel <:kekw:910212968405430273>~~

https://cloudinary.com/state-of-visual-media-report

I posted about it on Reddit, and trying to answer questions there: https://www.reddit.com/r/linux/comments/uasx1n/ffmpeg_now_supports_jpeg_xl_should_be_available/

Reminder to self: never ever read Phoronix comments

I love it when people ask me how a new image format compares to a video format, lol.

well if animated jxl can't beat av1 it's clearly worthless

as far as I'm aware animated JXL only exists so feature parity could be claimed over existing formats like animated webp

pretty much, yes

the goal is to match apng/animated webp/gif, perhaps improve a bit upon those, but not to compete with video codecs

the only thing it might be useful for is lossless video, where something like fjxl could probably beat ffv1

we haven't tried to make an animated jxl encoder yet that actually uses the inter-frame possibilities the bitstream has, like cropped frames and patches

oh really

but in general I don't expect any "animated still image format" to be competitive with actual video codecs

at least not for lossy video of natural content

AV1 should be used for the vast majority of videos - except vector. Animated JXL should be used when doing things like a few text/vector slides or graph animations - situations where video encoding is likely to blur text and make graphs more difficult to understand.

I could also see animated JXL being useful for short pixel art animations.

or anything where the inter frame tools of video codecs are not useful, like slideshows of 1 frame per 5 seconds without transitions

It turned into a quite nice comment section, thanks for starting that!

:)

Someone on the reddit thread is spooked by the microsoft patent <https://www.reddit.com/r/linux/comments/uasx1n/ffmpeg_now_supports_jpeg_xl_should_be_available/i687d3e/> but I don't know enough about the situation myself to make a good response.

Patents are stupid (I say even though I have my name on some)

But one thing is clear: a patent that was filed _after_ the thing was invented and published by someone else already, will not survive in court.

I replied in the reddit thread.

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

apparently it was posted 3 days ago on ycombinator and got no press <:kekw:707349424447160400>

https://dev.to/abbeyperini/what-is-jpeg-xl-4n7o

Some of the comments there are indeed quite cringy...

<https://www.phoronix.com/forums/forum/software/desktop-linux/1320748-ffmpeg-lands-jpeg-xl-support?p=1321398#post1321398>

He is saying jxl transcode is not lossless because libjxl decodes jpg in a different way. 🤣

it's a common misconception. somewhat embarrassing though for someone saying things like "What I said is technically accurate, and based on having spent more time on the inside of IJG & libjpeg-derived source code than probably anyone else in this thread." to not know that jpeg decoding is not fully specified.

Good idea! Or more generally, a FAQ.

Feel free to make pull requests for that website btw

Thanks for the reminder, done

it should be bitexact though, should it not?

if JPEG -> JXL -> Pixels doen't match JPEG -> JXL -> JPEG -> Pixels then there's a bug somewhere

no, because JPEG decoding is not fully specified

the JPEG standard gives a range of possibility when decoding

For example, libjpeg uses fairly low precision math, while libjxl uses pretty high precision.

... what? jpeg decoding isn't fully specified?

<:holyfuck:941472932654362676>

like, what

check this out https://github.com/google/knusperli

literally taking advantage of the unspecifiedness to produce better looking output than most decoders

this is compliant? huh

Basically, ignoring precision, any image that could've encoded to the current jpeg you're decoding, is a valid output.

Basically treating lossy encoding as mapping from intervals to values, and allowing the concrete output to be any value in the interval.

oh, interesting, so jpeg decoding really behaves like a preimage

even libjpeg-turbo with different decode settings produces different results, e.g. they have 3 different iDCT implementations and 2 different chroma upsampling implementations, so depending on which you pick you'll get different pixels

~~is the preimage of an open set of jpegs always open~~

btw converting jpeg to png is a lossy process for this reason - there is more information in the dct coeffs than what you get by decoding it with a particular decoder to pixels at a particular bit depth

how does that work with `--strip`

or does that option just skip writing the `jbrd` box with no effect on the encoding

yes

I see

the dct coeffs are still the same, it just doesn't store the bitstream details like what huffman code was used and what progressive scan script etc

also, you don't have to try to make incompatible idct, it can just happen by chance: https://guru.multimedia.cx/the-mpeg124-and-h26123-idct/

personally as a system integrator i would like it much better if images had bit-exact decoding like (modern) videos, but i can see why it might be preferable to decoder implementers to have it not be bit-exact

For video, pixel exact is essential because errors can accumulate otherwise with interframe.

For image, it is desirable but not essential, and there is an advantage in allowing different trade-offs between precision and speed.

In jxl, we try to balance things by having way stronger conformance criteria than the original jpeg (e.g. we have per-pixel peak error bounds, and lossless is lossless), but we still allow some implementation freedom.

What is best jpeg decode tool? I already test `knusperli`, `jpeg-quantsmooth`, `jpeg2png`, probably I miss something?

I haven't test this libjpeg implement, maybe this tool also a good choose? > https://github.com/thorfdbg/libjpeg

The one that gets the most use, so libjpegturbo <:YEP:808828808127971399>

good for what? speed or accuracy or good looking?

Thank you, I think I forgot libjpeg-turbo,😛 and I find a interesting discuss in libjpeg-turbo github. > https://github.com/libjpeg-turbo/libjpeg-turbo/issues/558

Speed not a problem, I want find a accuracy(precision) and have good looking(quality) jpeg decoder.

try knusperli

knusperli etc discussed many times in this discord, e.g. https://discord.com/channels/794206087879852103/805176455658733570/850873138983206912

no objective "best" quality, so correct solution is just to try all of them and see which one you like

https://it.m.wikipedia.org/wiki/JPEG_XL

Can you update this article with the correct information

Is edited two hours ago

https://fileinfo.com/extension/jxl was largely updated yesterday

what a strange way to measure file format popularity

https://fileinfo.com/filetypes/raster_image currently the most popular image format

followed by .BIF by Ventana Medical System

4.6 stars with 21 votes now <:KekDog:884736660376535040>

they sure list some exotic image formats there, wow

like MikuMikuDance Sphere Mapping File

What is an SPH file? 3D model effects file used by MikuMikuDance, a game where players control vocaloid virtual dancing characters; contains a .BMP image but uses the ".sph" extension instead; can used for adding a shiny look to 3D model features such as hair or clothes.

NOTE: To create a SPH file, draw a bitmap (".bmp") image with any graphics editor and rename the file extension to ".sph."

ok I guess that way it's easy to get a long list of image formats

https://fileinfo.com/extension/jpg_large

4.7 stars <:KekDog:884736660376535040>

Wonder if jxl can go to 4.8 <:thinkies:854271204411572236>

that website has great seo lol

Websites like that basically live off of SEO.

I would like to write about jxl-from-tree would someone be willing to be “interviewed” about it and jxl ?

Sure

Thank you! I will post questions privately in next few days.

👍

Recently updated JPEG XL section of JPEG file format Wikipedia article with latest standardisation information https://en.wikipedia.org/wiki/JPEG#JPEG_XL

https://it.wikipedia.org/wiki/JPEG_XL

ok copied you pat

with google tanslate

copy paste

but cited you

though i didn't asked fo pemission

changed also the datas emoving capital lette in italian not necessay

That's alright 👍

jon i fixed the formattation

https://it.wikipedia.org/wiki/JPEG_XL

if anyone italian want to fix but we need to discuss change

also it needs to be good fo mobile

Just realized the italian article doesn't have neither up to one third of the information of the English article

Recently added libjxl wordmark logo (<:JXL:805850130203934781> ) to software section of JPEG XL English and Japanese Wikipedia article. Accordingly, I checked this server message history regarding <:JXL:805850130203934781> and added PD-textlogo and CC0 licence to the file in Wikimedia Commons (PD-textlogo because in my view, wordmark alone isn't eligible for copyright protection and CC0 per message history correspondence with Boaz Lederer https://discord.com/channels/794206087879852103/803574970180829194/822012420612292628) https://en.wikipedia.org/wiki/JPEG_XL#Software

The filename is `libjxl_wordmark.svg` because there is already an unrelated `JXL_logo.svg` for an Atlassian JIRA-related software

I published the interview with _wb__ about JXL Art: https://medium.com/@denisbredelet/jxl-art-a-talk-with-jon-sneyers-7e9fe2dd1a4a

Recently created <:JXL:805850130203934781> article in Indonesian Wikipedia, this is still far from completeness compared to the English edition but at least here is the start https://id.wikipedia.org/wiki/JPEG_XL

https://boards.4channel.org/g/thread/87098962/youd-be-a-fool-not-to-embrace-jpeg-xl-as-the-de

I am not on 4chan but it's interesting to watch what people are saying there. Anyone here active on 4chan? That thread is quite decent for 4chan...

it's more appropriate to say it's decent for the /g/ board

but then again, how the website "works" is different users participate in different threads, but maybe it's more tame for a format war thread

i'm impressed by that marble image

https://hackernoon.com/move-over-jpeg-there-are-new-image-formats-in-town

(I didn't really write that tbh, I just checked if the words they put into my mouth made some amount of sense, lol)

(you can probably tell that some marketing people wrote that and not me. I did try to make sure they're not making me say complete nonsense though)

Yeah. Well some lines are by me, because I had to correct some wrong stuff :)

Hardly the most popular of blogs, but I did write an article on why I think JPEG XL is cool: https://www.frost.cx/2022/why-jpeg-xl

If you didn't write it, you probably shouldn't allow them to put your name on it as the author. Or, at least I wouldn't.

I did review it a few times, and some sentences are written by me. But yeah it's a bit silly, this ghost writing thing...

https://nuvs.tech/en/10911/

I missed that article when it was published

Apparently jpegxl.info is jxl's official website according to him lol

Also he has an almost fabian-level of english grammar

But hey, it's coverage.

Of course he's right that webp and heic do support 4:4:4, but I am also right to say that they don't really support it - having to go to (near) lossless makes webp not competitive with 4:4:4 jpeg, and 4:4:4 heic is technically possible but it doesn't work in e.g. all of the Apple ecosystems, so arguably the de facto heic standard is limited to 4:2:0.

Same with the size limits for heic and avif: sure, you can make files without profile that are larger, and they will typically decode when using software decoders, but you can expect interoperability to be a problem for such files...

On the other hand, you're so popular that people want to publish stuff with you as an author. That's not bad at all! 🙂

https://siipo.la/blog/whats-the-best-lossless-image-format-comparing-png-webp-avif-and-jpeg-xl

`cjxl --help=-E`

(no, there is no such thing)

To compare speeds, you need to look at the whole speed vs density curve

https://it.wikipedia.org/wiki/JPEG_XL

https://es.wikipedia.org/wiki/JPEG_XL

things i have wrote myself

When this would be rewritten by someone who knows how (specs) work

At what stage of standardization like is opportune to do something like this (rewrite)

https://en.m.wikipedia.org/wiki/JPEG

https://it.m.wikipedia.org/wiki/JPEG

I'm curious what is the dev opinion

The color space used by libjxl is XYB, based on the perception of the cones of the human eye, which is more sensitive to green but a concept further extreme. the encoder is optimized for pleasant perceptual degradation across all bitrates. Furthermore, the adaptive quantization is regulated by a metric called butteraugli, invented by google for previous codecs and on which the libjxl encoder calculates the image: not only by seeing the differences in brightness, the VMAF sharpness or only the peak to signal noise PSNR but how certain features are modeled differently in an image. for example mozjpeg and webp but it goes beyond structural differences and is not only focused on the precise preservation of gradients and allows you to adjust other metrics by adapting the values. also certain parts of the image are encoded in lossless or in a modular mode similar to flif, so it suffers less from blocking in screenshots easily.

Bbn

For example i wrote this bullshit

Copy pasted from encode su

Inventing some things also

Is good that luca versari opens jpeg xl Wikipedia and see this

That needs to be completed

With images and such

So what you think about my commits in Wikipedia

Are they draft or they produce something good, something you want to keep for all 2022

<:PepeGlasses:878298516965982308>

https://it.m.wikipedia.org/wiki/JPEG_XL

Now is enough complete

Google keep adding flif information

And pages are in English

I did 100 per cent of this with Google translate

Also i cited jon Sneyers directly without using the notes

As i should do

Is Wikipedia