JPEG XL

> too good to be free

can't wait until a couple years when everyone has forgotten heif and is talking big about vcif

I know apple and others will take a vvc keyframe and make it an image

It might beat avif and jxl

It will be utterly useless tho

People will laud it as the greatest image format regardless

no

1. Licensing Basically kills any adoption in any browser, windows (without paying for a plugin), or freeware/oss software 2. Lossless and reverse compatibility I can't see vvc doing better than lossless jxl at least in size/speed and ofc it can't losslessly recompress jpeg

I mean if you coded some mitm app you could

Like a context option in the windows action bar "open as jpeg"

That called a program to convert it to jpeg, put that in temp, then open it with your application of choice

Either that or server side conversion

Which we already have for stuff like jpg and webp so not a big issue

i think someone in the av1 server encoded a still with vvc and it looked pretty good

too bad licensing will probably suck again

It is because it is mainly used by Apple <:kekw:808717074305122316>

That was before my grubby little hands starting experimenting with AV1 proper intra.

The amount of progress AV1 in intra only has made in that regard is actually staggering.

also smh at people discounting jon's article because he's one of the jpeg xl creators

they could just run the comparisons themself

Yeah. If I say JXL is good, then that means it is good. <:kekw:808717074305122316>

For a photographer centric website, I expect those people care about having high fidelity than web use case (good looking & appeal). It makes me think they are some hobbyist / amateur photographer.

Indeed.

Like, you see the people talking about HW encoders/decoders? You can build one for JXL as well <:kekw:808717074305122316>

You can, sure. Though we can't guarantee anyone will. By contrast, HEVC IP already exists out in the wild. Camera companies had to implement it to support HDR, and to make 4k video space efficient to actually use. As a result, they could use the same tech for image capture pretty much for free.

I don't promise anything 😛 I think if *I* do a GPU implementation, it will start as a tech demo very likely in CUDA (because it's 10x easier for me) and then I'll ask someone else to build it in spirv -- I am already learning too many things at the same time 😛

(although rust-gpu might make me change my mind on that)

update: maybe I could use Sycl...

Jxl vulkan implementation pls.. 🤤

mh... is there a reason to use Vulkan rather than OpenCL?

opencl often requires extra drivers installed to work (which may be proprietary on linux) while vulkan compute should work with any good vulkan driver afaik

In my experience with blender OpenCL is the hell

isn't there drivers for vulkan stuff too?

IIRC you can basically rely on any good GPU-related driver except Intel's being proprietary

and from what I can see running opencl on android is a lot easier.. as well as using things like fp16 in opencl

Blender opencl doesn't work properly on amd cards.

You got something a little wrong

Jpeg wasn't created almost 40 years ago

it was created almost 30 years ago

Jpeg in 1982 would be funny

Yep, however, this would not be unusual, since the DCT technique was already known and published in 1972

https://translate.google.com/translate?sl=it&tl=en&u=https://www.creativemotions.it/jpg-vs-jpeg/

JPEG was created from 1987 to 1991, spec published in 1992

https://youtu.be/5tJ5z7UATk8

Does anyone speak Russian here? I don't

<:FoxNo:786214945892990976>

Basic information about the format, nothing special. Like, you didn't know about jpeg xl? Now you do. <:CatSmile:805382488293244929>

https://www.shoot.be/nieuws/189392/nieuwe-jpeg-xl-standaard-komt-eraan-en-zorgt-voor-kleinere-beeldbestanden/

First time I see something appear on a Belgian website

https://www.docma.info/blog/jpeg-xl-oh-nein-nicht-noch-ein-jpeg-nachfolger

00:25:30 https://twitter.com/SciFactPodcast/status/1418335909766864899

if i understood the date he mentioned at start

eighteen 2 thousand 21

i heard that now

gatherings barbecues

what they are saying

i don't understand sorry but my english isn't good

i was salty there were a choices

were turn off my computer

ah it's available in mp3 for free

thanks for listening

i heard made on 25th 2020

so jon made an article on christmas

he said GHIF sorry ggif

lazy friendliness

legacy he said

it said in desktop the image are so wide and on smartphone the capacity is way less

at 34:00 until 36:00 you should listen

at 37:30 there's something interesting i'll write in offtopic

it ended only that is one minute and 30 of gibberish now is 39:00 gone to offtopic

https://avif.io/blog/comparisons/avif-vs-jpegxl/

> Although AVIF is newer than JXL, AVIF has been slightly more widely adopted by browsers.

The AV1 bitstream was frozen in 2018, the AVIF container spec was finalized in February 2019

The jxl core bitstream was frozen in January 2021, the file format was finalized in April 2021

I don't really understand how you can claim that AVIF is newer than JXL in any way

right av1 image encoding even in 2016 existed

A big part of JXL development (all of the collaborative effort after the fuif and pik proposals were submitted) happened _after_ avif's payload was already finalized

> Despite being around for two years, it hasn't been fully supported by default by any browser and lacks even experimental support on mobile. huh?

ugh i don't like that site

my cynical brain thinks they want their .io domain (relatively expensive) to stay relevant

the homepage says avif is based on "VP-10 codec technology" and is "a better version of PNG"

also i don't get why anyone would want to manually convert more than a few images. you can't fit avif.io or squoosh into a toolchain. at least squoosh supports lots of codecs and lets you compare easily...

> There is no other codec that seems as promising as AVIF

We need more articles written by people who are not too biased and who know what they're talking about

Sure, I already tweeted it to them too: https://twitter.com/jonsneyers/status/1418845212596744195?s=19

As I wrote before, it's a bad thing that articles with no understanding of how to properly compare or even encode images, or very little knowledge of formats and their features, usually quite often get cited by others as a factor of superiority and victory of a certain format

I wonder what made him think that avif is more recent than jxl when actually avif is about 3 years older.

Yes, that article by Josh Stoik is a good example - but I cannot really blame people, there just aren't any recent good sources saying stuff about it

Or even statements like these, which mostly refer to AV1 but not always to AVIF

> AVIF is being developed by the most influential technology companies. And this applies to AV1, but not all changes to AV1 are as good for AVIF and as far as I can see AVIF is rather being developed on a residual principle, none of these companies develop or improve specifically AVIF itself as an image codec

https://twitter.com/jaffathecake/status/1418878745579069449

Btw, about low fidelity images that look good at a certain distance or not in full resolution or on a small screen with high resolution, I also do not support and do not understand why formats should be developed in this direction and be worse in fidelity even than old formats. Yes, it's good when it's possible to get even more savings and lower bandwidth costs, but would it be good at the sacrifice of less fidelity at the price of more fake quality? It's almost like making products cheaper by reducing their health benefits or repairability, but instead using a more flashy and attractive look or various flavor enhancers (which is already happening) It is also bad for the near future, as it happened in the days of the first digital photo and video cameras, shooting became cheaper and the quality was considered sufficient, but now this quality and all filmed materials are much worse than the old film ones (which can be restored or digitized in very good quality)

Also an example of fake high resolution and upscalers, which are now increasingly used for photos in smartphones that look good on small screens, but at full resolution it is something strange: <https://www.reddit.com/r/pics/comments/ocfst0/protesters_in_cologne_germany_raising_awareness/> (and probably not a very pleasant composition for everyone)

So, for me there are limits when this kind of savings at the cost of fidelity or fake quality is not worth it (maybe for some images, but not as a general direction), besides the speed of the Internet every year in the world is also rising, and the increase in the resolution of photos and images is not that fast anymore

If the screen has "too many" pixels (e.g. a phone with a 4K screen) in terms of what the eye can resolve, then for web delivery it makes perfect sense to send images at a resolution that is lower than 1:1, e.g. send images in Full HD instead of 4K if you know they are viewed on a 5 inch screen and zooming is not a thing in your use case.

That makes more sense to me than to send same-filesize very low fidelity images at native resolution, in that case.

so resuming, jpeg xl permits resolution higher than 16000x1600 and 8100x4000 (4100), jpeg xl can scale of resolution so serve an image that is big on a 4k screen and a small image for a phone, jpeg xl use butteraugli distance metric, jpeg xl looks better at quality after 75, so jpeg xl cover all qualities and is a complete codec

hardware decoding is not in avif, neither in av1 vlc, few devices support it and anyway images don't use HW decoding. Is not useful now, not ready now.

Whoa that is a quite extreme case, the photo has basically been vectorized and the people are turned into uncanny valley early 2000s computer game graphics....

It looks weird and ugly.

AI upscaling taken beyond the point where it somewhat works

These are some upscalers that are used in smartphones for marketing megapixels

upscaling is a bit of an extreme way to cheat with megapixels

a more subtle form is to do a lot of 'signal processing' that does a lot of median blur and stuff like that

Really? Are phones getting that fast to do upscaling?

I have never seen any phone doing upscaling

https://ai.googleblog.com/2016/11/enhance-raisr-sharp-images-with-machine.html

Yes, many have separate AI hardware units for this, also for combining multiple photos to improve the quality or night photos

Raisr in gcam works only when taking photos on zoom mode

raisr is from 2016, I imagine things have been taken further since then

Raisr doesn't make any weird artifacts. (Atleast on gcam)

if it's limited to 2x or 3x upsampling of reasonably good input images, then I guess weirdness can be avoided

if you start doing things like 5x upsampling of already poor input images (already processed and compressed), then there's a problem

so, since avif.io exists, I was wondering about jxl.io

https://jxl.io/

it's apparently a non-jxl related page with not much content besides basically a fancy business card

<:Thonk:805904896879493180> http://jpegxl.io/

Lol, why do they do that instead of just also making a jxl converter?

W T H

It takes 3 minutes with full multi core

it seems the file has errors

firefox says

does anyone managed to convert a file without errors on that converter?

https://tipsitaliani.altervista.org/jpeg-xl-twitter/

https://tipsitaliani.altervista.org/jpeg-xl-all-information/

https://tipsitaliani.altervista.org/jpeg-xl-state-on-07-07-2021-is-it-any-ready/

I updated the font

There are problem viewing on mobile

Which converter?

Probably mixing it up with JPEG XR or something.

the one avif.io site

JPEG XR is from 2006 (standardized afterwards in 2009-2012 but the bitstream was already frozen and used in Windows Vista)

I think he just went by the dates of the blogposts about avif and jxl that he could find, or something

on chrome the rendering is broke

Because AVIF is newer and better than JXL. <:YEP:808828808127971399>

https://twitter.com/jschmitz97/status/1419035827653554181?s=19

The guy means well, just made some mistakes. I hope the next version of the article will be better 😅

Meanwhile, if someone feels like helping him with putting a wasm libjxl online, I assume he wouldn't object: https://twitter.com/jschmitz97/status/1419036360044912642?s=19

jpegxl.io redirecting to avif.io :/

it baffles me how as a society we are pushing for more and more pixels for better quality, but at the same time pushing for delivering those more pixels at lower and lower quality... feels like marketing that gets in the way of user experience (battery life, prices, ...)

<@!710762823986446367> Hello, i see that https://squoosh.app/ still does not have the speed setting from 1 to 9, is this normal? In may there is a github commit for that when i ask the question previously.

<@231086792315633664> do all of the speed numbers do something in JXL now?

I thought 1-3 did nothing

now the effort start to 1 and go to 9, 7 is default speed and near best quality

Ah cool, I didn't realise it had changed

Can you file in issue on Squoosh so we remember to update it?

1 and 2 only do something different for lossless atm, iirc, for lossy more or less 1==2==3 atm

Hm, is it worth exposing then?

on squoosh, probably not - very fast encoding is not really what you're looking for in squoosh

those speeds are more for when you quickly want to losslessly save an image in gimp/photoshop, when you're still editing

Yes, my aim is to change the number on squoosh, fast encoding is not very usefull, and having the lastest encoder compilation. Also having same effort numbers than encoder, 7 by default for users because this is the default quality. I need to be the reference to compare quality vs avif and jpeg.

this squoosh version don’t even say if the jxl is lossless or lossy Yes But im talking about the input jxl file Also no lossless jpg transcode implemented in input and output and no signaling of lossless jpg transcode for input

<@416586441058025472> are you talking about squoosh.app or the cli tool?

Squoosh app should display if the jxl is lossless or Not

Should do only for jxl

And add lossless jpg transcode mention in input and in encoding

Like redo huffman

Is difficult But why Not

Like veluca could help you supporting those files and to recognize what type of jxl is

Lossy modular Not sure if is useful to display

Also proper apng and mobile support for squooshapp But thats Not a priority

Doing a little Ask Me Anything: https://www.reddit.com/r/AMA/comments/orcn11/i_am_a_cocreator_of_jpeg_xl_jxl_a_new_image/

(going to sleep right now though)

https://avif.io/blog/comparisons/avif-vs-jpegxl/

The guy did update the article

Conclusion is still the same though: > Full support from Chrome is a massive win for AVIF and suggested that the industry is moving towards this spirited son of a video codec as the next mainstream standard.We think, although JPEG XL has a broader feature set, it is AVIF most people should look to as the following definite image format for the web.

> There is one major issue remaining when it comes to implementing these formats. > ```html > <picture> > <source src="image.avif" type="image/avif"> > <source src="image.jxl" type="image/jxl"> > <source src="image.webp" type="image/webp"> > <source src="image.jpg" type="image/jpeg"> > </picture> > ``` > Due to the fact that every browser that supports image/jxl will also support image/avif, no browser will ever select the image.jxl source as written. The other way around, in order to actually benefit from JPEG XL, it must beat every other format, a problem compounded by the fact that source elements actually require srcset rather than src. In contrast, WebP only needs to surpass the original JPEG/PNG source in order to be useful. We recommend Josh's article on Blobfolio for a live comparison of both formats or to experiment with the formats yourself, on sites like squoosh.app from Google. can't you just put jxl first, and for images where avif beats jxl, just don't serve the jxl version at all?

With that reasoning, you can also say something like this: > Full support from literally *all* browsers is a massive win for GIF and suggests that the industry is moving towards this elegant daughter of CompuServe as the invincible mainstream standard. We think, although new codecs have a broader feature set, it is GIF most people should look to as the definitive image and video format for the web.

tbh it seems that he's more about hoarding up fancy domains, writing some articles what barely make sense and hogging up funding than actually doing proper job

notice "Searching for an investor." in his tweet. my gut feeling is it's not what proper researched would do

Yep. Or you can drop the whole picture srcset thing and just serve different things depending on the `Accept` header, picking the best supported codec.

Yeah that sounded fishy to me too. First buy the domain, then wait for someone to pay you to do something useful with it? 🤔

I guess that's how all the nice domains are always already taken

tbf .io is not good idea to use anyway

Call me old-fashioned but I first want to have something to put on the domain before I get the domain

What is .io supposed to mean? Input output?

indian ocean or something

> The Internet country code top-level domain .io is assigned to the British Indian Ocean Territory. yeah.

I like my country's tld, .be

Hm, someone already took http://tobeornotto.be/

Btw, we can put more stuff on jpegxl.info

You can make an entire subpage of your own if you want, with whatever info you think is useful

I am paying for that domain name but the page belongs to the community

.io for online encoders is pretty fine, especially considering that any 3-4 letter names are already taken in all popular domain zones

That is, if there are pull requests to change the front page, I want to check it first, but if someone wants to make a jpegxl.info/mycorner, I am happy to give them write access for that

Too bad git doesn't have per-folder permissions, but I don't mind, I can trust people not to do bad stuff (and revoke permissions and revert stuff if needed)

Sure - I wonder who would want to "invest" in that though. I don't see a page with some frontend for a wasm version of a foss encoder become a very profitable product.

As in, what stops me from copying it, minus the ads, and putting it on jpegxl.info?

Maybe with the further addition of some paid encoding plans on the server side, like <https://letsenhance.io/>

I think libjxl.io is still available: https://www.namecheap.com/domains/registration/results/?domain=libjxl.io

I ended up using it just for spider-mar.io (not that I am doing much with that)

...

Again? <:Thonk:805904896879493180> https://twitter.com/SciFactPodcast/status/1419922603158884355

that's not a question

yes, all you people being paid to work on JPEG-XL, you should find jobs and become bald

https://www.reddit.com/r/AMA/comments/orcn11/comment/h6r0l1a/

I wondered why the hostility...

It's because of this post from last week: https://www.reddit.com/r/compression/comments/ooh8cs/random_data_and_lossless_compression/

The guy claimed he had spent many years on making this wonderful compression method that can compress anything down to 66 bytes.

Only it's not feasible because it takes a lot of time and memory

I commented about the pigeonhole principle and now he's angry at me.

i read one of the comments in the ama about pronunciation. I think it would be cool to have an official pronunciation in the spec if it does not already exist, like ping for png <https://www.w3.org/TR/PNG-Introduction.html>

yeah but since jay x l is already a popular pronunciation it should be easy

i want to be able to link someone the original document in 30 years time about an official pronunciation

im hoping progress will continue to be made and there will be a newer format in 2050

i feel they will always have different things each one is better at, i dont think any of them will be necessarily "beaten" by the other

Guess we have to go with jixel then!

i doubt italians can pronounce jay ixs elleh

probably ji ix el or ji ics elle is shorter

veluca how jxl should be pronounced in italian <@!179701849576833024>

I usually go with jay ics el

ho delle foto in jay ixs elle

sounds bad

le mie foto sono in jay ixs el

lol

džiksel :v)

if all goes well, people won't have to think about which image format to use anymore, and then maybe the pronunciation will just be "image" (or whatever the translation of "image" is in your language)

If You Say ho le immagini in Jay ix elle

Is bad

You are right

Ho le immagini in Ji ix elle

Is un spellable

ah elle in italian is with an open e

ˈɛlle

https://www.reddit.com/r/AMA/comments/orcn11/comment/h6r0l1a/ I have to admit, I do enjoy trolling trolls.

Sigh he is commenting on stuff from months ago too: https://www.reddit.com/r/cellular_automata/comments/mebb9r/comment/h6t7iwg/

doesnt seem like he enjoyed your criticism on his work

ech tbh i dont like current overuse of turning completeness as phrase too

It's the right term when you're distinguishing special-purpose machines from universal general-purpose machines, imo.

It's probably just the Apple fanboys, I suppose...

honestly i think you're being a little pedantic, and i'm not an apple fanboy. not being able to run arbitrary code is an issue, but imo that's outside the scope of what the concept of a turing machine is meant to distinguish

it's not the term I'd have used either

is there a better term for this?

I like to honor Turing for coming up with the notion of universality of computation which enabled general-purpose computers in the first place.

The theoretical notion of Turing completeness is not very relevant practically though. Printers that can handle PostScript are Turing complete, but as a general-purpose computer they suck in practice because the i/o is very inconvenient. Same with the Rule 110 cellular automaton.

I don't know any better term to distinguish universal/general-purpose from non-universal/special-purpose though.

no physical object is Turing complete 😛 I'd like to avoid Turing completeness for anything that is not a programming language or CPU or similar -- in this case, I'd just say it's very locked down, and for things like ASICs I'd say they are not general-purpose

https://www.theregister.com/AMP/2021/07/31/iso_paywall_battle/?__twitter_impression=true

non-AMP link: https://www.theregister.com/2021/07/31/iso_paywall_battle/

https://www.reddit.com/r/programming/comments/ovjc75/tech_spec_experts_seek_allies_to_tear_down_iso/

trending jpeg xl articles with the page written

discussion on 4chan 28 JULY 2021 i don't understand all trannyfox devs to stop 41%'ing and finally add support. that means mozilla firefox is not sponsorizing avif? what this people is trying to say?

also link to that

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

Can I send after i should lunch

https://boards.4channel.org/g//thread/82729462/why-are-they-trying-so-hard-to-push-this-garbage

ugh https://en.wikipedia.org/wiki/Triple_parentheses

wow that meme got its own wikipedia article

https://korii.slate.fr/tech/technologie-image-format-jpeg-xl-remplacant-jpg-compression-poids-web-bande-passante

Two sentences not rehashed from somewhere else, both quite wrong.

That first sentence just needs the "et vice-versa" removed.

Second sentence maybe was meant to be about the codec being royalty-free, which is not the case with HEIC. There are open source HEIC implementations, e.g. libheif with x265. AVIF is just like jxl both royalty-free and has open source implementations (not sure though if the best avif implementation is open source atm, but that's a different question).

hm, no commenting system

maybe they accept e-mails

well AVIF isn't royalty free if you listen to sisvel <:kekw:808717074305122316>

Also not if you listen to Nokia

Though in both cases I think the claims are kind of bogus and they'll likely avoid litigation to avoid getting the patents invalidated, but IANAL and I didn't even read those patents

I stopped listening to Nokia in 2011

(burning platform memo, killing MeeGo despite the success of the N9)

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

Could someone go through this channel and add a selection of nice blogposts to the jpegxl.info page?

It's way too much my own old blogposts there right now

blog jpeg xl personal list

> **plonk420** > someone tell them about JXL https://www.techspot.com/article/2299-image-file-formats/

Yep, an article where Jpeg XL was supposed to be, but it wasn't mentioned <:SadOrange:806131742636507177>

At least the site has a comments section

https://fin.afterdawn.com/uutiset/artikkeli.cfm/2021/08/02/tiedat-iso-standardit-ne-ovat-maksumuurin-takana-ja-tahan-halutaan-nyt-muutos something in Finnish, <@532010383041363969>

wow

Finnish journalist made a comparison to scientific publications

authors donate their work to an institution that then consequently makes profit with it

I found one comment worth mentioning

"If we don't do something, soon it will be forbidden to lend tools to your neighbour as it reduces profits of tool manufacturers."

After Jon has fixed the paywalling ISO standards, let's then remove passports, visas and apostilles?

> most hated entity in the world JPEG? You must be dreaming. JPEG is so dominant because most liked using it more than anything else. JPEG XL is much better JPEG, it both beats the old JPEG as well as the formats you mentioned in lossless mode.

level of a.. exploded

JPEG XL is much better JPEG

what?

What

4chan article

anyway i added date on spanish jxl

is the only one that is done correctly by now

i destroyed in en and i did a bad italian

another comment i hate is this

>no one needs a new format Yes, I do need a ~50% more efficient lossless format. I also do want a displayable format that can save 14bit per channel images from my camera, many browsers and image viewers can't show the current RAW images right. > we will be using PNG JPG I don't think so, PNG will switch to JXL and JPEG probably also over time. > MP3 Increasingly Opus or AAC already. Some voice chats at some time partly used mp3, that's gone. Various streaming services and video containers used mp3, also usually gone. It takes a while, but are you still using DivX / XviD? Nope.

a good one though is this

Also, >Link? I have several: https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg >In most cases, you’re better off encoding animations with a video codec instead of an image codec designed for stills. https://encode.su/threads/3515-JPEG-XL-release-candidate?s=0776b8a76919412954adcd369776fe29&p=67492&viewfull=1#post67492 >Making animations use less memory is nice, but I think on the web, for animation you need a full-blown video codec https://news.ycombinator.com/item?id=27582304 >Anyway, I think that animation is in any case best done with video codecs (this is what video codecs are made for) There were also a few more, perhaps even more in-depth, elsewhere (bug trackers, reddit or twitter), but I can't be bothered looking them up right now.

another good is that

>>82830312 Spending one minute to encode a 1080p screenshot isn't what most people would choose to do. Sure, you'd do it for content you'd care about, such as your manga releases, but not for random meme images spammed all over the place. Modular has a lot of space to improve anyway. The current cjxl doesn't fully utilize it in neither speed nor efficiency. >>82830326 > isn't what most people would choose to do The part with "choose" is the main issue, people wouldn't know what to do. Their smartphone app, browser script, browser webassembly or the server-side stack however can know. At which point they'll notice basically nothing, the file is "getting sent" "uploaded" or "processed" on the server - in modern times often without any status messages. It just happens.

....

SOURCE

Those are actually 2 posts one yesterday and one today night in a 4chan server site

these are principal comments, most useful, annoying

can you stop copypasting stuff and instead link posts

one is the one scope linked, one i found it on 24 hours jpeg xl

but is completely different

i can link the one i found

https://boards.4channel.org/g/thread/82816369/lets-talk-about-the-upcoming-image-filetype#p82830326

https://boards.4channel.org/g/thread/82814858#p82815524

read first the second

https://discord.com/channels/794206087879852103/794206170445119489/872836837192912897

https://www.reddit.com/r/jpegxl/comments/oxp5df/does_anyone_else_think_it_would_be_annoying/

please say me thanks

well i wasn't aware that there's thread going on so thx for that but you spam too much stuff anyway

i wonder if it's the same guy or someone else reusing these arguments

Same guy

> So, I made a thread over in the /g/ board of 4chan talking about this same topic. ah yes.

jxl Q&A

I think you forgot <#840831132009365514>

https://twitter.com/dtcreports/status/1423417290737991681

> The baseline version of the format is intended to be available royalty-free ???

From "tech" consultants, you can't really expect well informed well written opinions <:kekw:808717074305122316>

https://www.robadagrafici.net/la-grande-guerra-dei-formati-immagine-webp-vs-jpegxl-vs-avif/

yes this is pog, i've included in my thread <#822105409312653333>

<https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1271898-firefox-92-to-try-again-with-avif-image-support-by-default/page2>

I'd reply, but I don't have the energy to xD

Far too slow <:kekw:808717074305122316>

Has he tried AVIF lossless or CJXL speed 7 and below?

If he considers jxl encoding too slow to be practical, then I wonder what he thinks about avif encoding

The fastest useful avif encoding (i.e. not worse than webp) is imo about one order of magnitude slower than cjxl -e 6

Yeah. On average in my tests, `cjxl -e 6` is usually 3-3,5x faster than `aomenc's --cpu-used=6` per thread on medium sizes images. On bigger images, this can be upped to 5-8x slower per thread, so IMO, it's not even fair, so your statement is correct. Even counting the fact that aomenc still needs quite a bit of SIMD, the speed difference is rather large.

I didn't, but as I said... No energy 🤣

I mean I understand some people prefer "blurry" pictures like AVIF, but saying that JPEG XL is too slow and as the same time saying AVIF will be better…

That plot says a lot about what this person knows about image quality assessment

https://c.tenor.com/dOIgT2fBRvMAAAAM/this-much-quite.gif

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

Experiments with n=1 test subjects are statistically not very relevant. Also the selection of test images does not seem to be very representative (looking at the images on that website, I see very few photos, for example).

what is this graph even supposed to show?

i mean i can create a jxl encoder that just returns a 20 byte image no where near what the actual image is supposed to be but it will always be the smallest

He presumably encoded the images at a quality he considered good

But that's still a rather subjective thing, and something that is inherently not byte-precise

So if you make an avif that is 99k and a jxl that is 100k, it's a bit silly to call that 1-0 for avif.

Yet that's basically what he did.

none of these sites ever give the data they use to create these graphs

only the final output

would be nice to see that plus what options they used to encode the images

yes, it seems a relevant article regarding this would be: https://www.newstatesman.com/blogs/the-staggers/2011/12/issue-essay-line-dawkins

> Why throw away most of the information by splitting a continuous variable into two discontinuous categories: above and below the ‘line’?

Convert any image to pbm to get a visualization of what thresholding does to information 😅

Maybe... Though now I am chairing the JPEG adhoc group on assessment of image codecs, I should maybe not write opinionated blogposts on the topic for now.

https://lobste.rs/s/oexwrw/low_bandwidth_images

I found it i re share on r av1

lobste.rs is p comfy tbh

unfortunately ruined with my poor language and lack of a software adoption page

It's not RAISR, it's Super Res Zoom from 2018: https://ai.googleblog.com/2018/10/see-better-and-further-with-super-res.html

Before this, they used raisr

> After Jon has fixed the paywalling ISO standards, let's then remove passports, visas and apostilles? Yes, yes, yes! I'd love to see the world without country borders! Just like Schengen zone, but covering the whole world <:Hypers:808826266060193874>

😄

This actually might happen. Have you heard about https://www.thevenusproject.com, https://www.thezeitgeistmovement.com, https://www.amazon.com/Escaping-Fish-Bowl-Awakening-Freedom-ebook/dp/B0161HS5M0/ (I translated this book from English to Czech BTW) or others?

Ok, that's interesting...

http://ds.jpeg.org/documents/wg1n83043-REQ-JPEG_XL_Use_Cases_and_Requirements.pdf

https://jpegxl.info/

https://github.com/libjxl/libjxl

http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

https://jpeg.org/jpegxl/index.html

https://www.businesswire.com/news/home/20210817005633/en/

https://www.researchgate.net/profile/Noor-A-Khalid/publication/352905043_A_Comparative_Study_on_Lossless_compression_mode_in_WebP_Better_Portable_Graphics_BPG_and_JPEG_XL_Image_Compression_Algorithms/links/60df1c3da6fdccb745fc97b9/A-Comparative-Study-on-Lossless-compression-mode-in-WebP-Better-Portable-Graphics-BPG-and-JPEG-XL-Image-Compression-Algorithms.pdf

https://dither8.xyz/blog/img-future/

Well they didn't use best options for cjxl

I think jxl is usually capable to beat webp on nonphoto too

Of course it will happen -- As an example the idea of apostilles for example is that someone uses an internationally recognized stamp to verify someone's physical signature. Stamps and physical signatures belong more to the past than to the future.

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

Sheesh, as usual, orange site users are some of the most annoying technical people on the internet.

What about 🍀 chan

>technical people

https://www.l-camera-forum.com/topic/323794-jpeg-xl-a-good-idea/

> It says the format is royalty free licensed which is not the same as open source. For me it's not entirely clear whether JPEG XL is a proprietary format or not. All proprietary formats have a stillborn effect so far and disappeared <:Thonk:805904896879493180>

https://jpegxl.info/ > FOSS and royalty-free

and just after saying: > JPEG XL has a open source reference implementation according to the web site https://jpeg.org/jpegxl/

which has a link to the source code

I don't know why did I register... I'm not even a Leica user 😄

But, this post is not shown to other users, perhaps some kind of anti-spam protection

from dpreview comments <:kekw:808717074305122316>

Yep, I've seen it 😃

https://youtu.be/ggHkgsSg7vg

https://lobste.rs/s/bx4m9g/why_webkit_supports_avif_safari_does_not

https://www.reddit.com/r/jpegxl/comments/pdx4e8/jpeg_xl_developer_usage/hatdpwv/?utm_source=reddit&utm_medium=web2x&context=3

Your reddit comments are not jxl coverage fab

So the Word coverage in english do not means that

Thanks for downvoting

Ill report to JPEG xl users

So basically you dont want links that are My blog

My comment

<:peepoLove:698857674804297748>

As long my comment dont get deleted im fine how many downvote i need in an hour or day to reddit delete my comment

Anyway there Is a backup

--use_new_heuristics

no i didn't used it.

also cursed than i renamed cjxl to cjxlimproveall

It won't get deleted, it will probably get hidden and people will have to expand it to see what it says

> 3. Is there anything I need to be carefully [sic] by using this? Do not execute fabiorug's commands!

yes, it is explicitly marked as such!

yes -p maybe inflates file sizes, is very risky to use in a nightly build until libjxl get 1.0 and maybe not

the reason why you're getting downvoted is that what you said is completely unrelated to what they were asking

-wb-'s answer is much better as it actually answers what the OP was asking

I know

I was only writing random things while waiting for wb

?

what

why the hell would you do that?

and anyway even the devs answered that part

https://encode.su/threads/3397-JPEG-XL-vs-AVIF/page5

you're supposed to downvote comments that aren't relevant to the discussion so downvoting was appropriate in this case

Is permitted to talk about origin of JPEG XL in coverage without discussion

History of fuif

Maybe this Is <#805176455658733570>

Anyway mistaken

why don't you just post the link? why are you posting screenshots when you can just post a link?

https://github.com/cloudinary/fuif#readme

I thinks it better fits <#794206087879852106> because FUIF is now part of JPEG XL

https://twitter.com/GoogleOSS/status/1435272912500662285

https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html

Congrats with the nice article, <@795684063032901642> !

It's pretty cool, but it's hard to appreciate the value of this as when all the demonstrations in the article show the JXL loading in about 0.5 seconds 😆

Huh, the demo videos are replaced with "Stay tuned for videos showing progressive JPEG XL in action."?

There were some wrong images in the videos, namely when the green checkmark appeared, accidently it was not the final image but the smoothed DC imaged that appeared. When I saw that I immediately produced corrected videos. However changing the videos in the blog post was not possible immediately, because I'm not the one in control of uploading them and changing the links in the blog post. Therefore we put that sentence as a replacement. I will post here as soon as they are up again...

Making the JXL loading fast in the demo video was a conscious decision, because we expect that loading that fast is the typical use case. I understand that this way it is harder to perceive in the videos what is going on, but the point I was trying to get across is how a real life experience is when loading these images. I first played around making animated webp animations. (Of course anitmated JXL would be also an option here), but then opted for making videos instead because you can easily pause them. So to inspect what is really going on in these demonstrations, I suggest loading the videos once and then use the pause button to look how the intermediate stages look like. (For this, the videos need to go live again, of course, which will happen soon hopefully...)

Yea, my take away from that is "wow JXL loads fast!" and it was very hard to differentiate the value that salience mapping provides

I suppose that's the sort of thing that would be more valuable on very slow connections

(e.g. mobile)

on broadband I can't see an average user noticing the difference

with the entire image just being there

The goal of progressive loading is that one hardly notices and it shouldn't be distrating and irritating at all. It is a little paradoxical making a demonstration about it pointing people towards what is going on. Ideally even on a slower connection the user looks first at the salient parts that are already loaded completely. Of course for a really really slow connection the user will be able to pick up what parts are already fully loaded and which parts have still bits missing

Or as an alternative, it is also possible to attach two videos, with normal speed and with a very slow and maybe with a zoom part, to better see the difference in quality when loading For example something like this https://youtu.be/inQxEBn831w

Since it happens not only when the connection is slow, but also with very slow sites at least to a certain client and I myself have faced this

What also can happen is that you're on the road / in a train and the connection just drops or reduces to 2G while you're browsing. If that happens, you'll basically be stuck with whatever partial images are available at that point.

The videos in the blog post on progressive jxl are back up (and now it is the correct ones): https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html

Cool!

It's a bit hard to see what is going on tbh, since the image is quite large (for the web)

Looking at the groups, it must be about 11-12 megapixels

So in a 720p youtube video, a lot of the difference between upsampled dc and final image gets lost

It doesn't help that the nonsalient parts are also blurry

I mean it's good to convey the message "it's subtle and you don't even notice"

But it's not so good if you want to actually see what's going on 😅

I'd love to be able to do a live demo by using webdev tools to throttle network speed and then load an actual jxl image in an actual browser

Yes, it is best viewed on a 4k monitor full screen. You can pause. Experiences with animated webp at different speed showed that chrome skips frames for animated webps if the images are of the size we are considering

A click-through gallery style to demonstrate the effect might also be nice, but I agree once it is implemented seeing it live under throttled condition will be the most realistic experience

Also note that in a real-world setting the image loading is such that it is only done a few times during loading and not for every new byte that arrives. We all have experienced that from sequential jpeg, unless the connection is very very slow, we don't see it scrolling down from top to bottom, but rather it gets rendered like 3 times, once with say 20%, one with 60% once with 90% before it completely renders. In this regard the videos are not realistic, but over the long run (think), cpu cost of decoding might get cheap enough to actually render whenever new bytes of the image arrive..

At least Firefox with patches already supports progressive decoding (but other browsers still don't) and yes, in my tests it is very CPU intensive on large images if updates when loading are frequent, and also none of the browsers have support for initial LQIP showing (and this would be useful even on non progressive images)

I recon the LQIP is really what is important for ultra low bandwidth scenarios.

I think it makes sense to render only upsampled DC and final image groups, and if there are intermediate scans, only render those if it has been more than 300ms since last render or something like that.

We can do built-in LQIP with progressive DC (which is used by default at the lower qualities), but that hasn't even been implemented in the API atm (we don't have paint events before full DC)

Though you could argue that the DC is a high quality LQIP

Also the bitstream can contain Preview frames but I don't think those are shown in any browser atm

btw, the issue with "green" people in intermediate early jpeg scans has been fixed both in firefox and chrome

looking at the second image in the preview of the youtube link above..

It was fixed both in browsers waiting for CbCr DC, and in mozjpeg no longer producing those separate-DC-scans jpegs anymore by default, right?

Also something strange when loading images, I have a pretty fast Internet and no such problems with other sites <:SadOrange:806131742636507177>

yes

Not that it was a huge problem in practice, you have to be unlucky to catch a render at such a spot

But I have seen it in the wild

The thing with 1:16 or 1:32 previews (as you could in principle get from a progressive DC) is that upsampling becomes pretty expensive

And it becomes a bit of an artistic choice of what kind of blurry mess you prefer

Though for big enough images, it might still be useful

For a 11x16 groups image like the example in the saliency blogpost, the 1:16 image (1:2 of the DC) is 176x256 pixels

The 1:32 image would be 88x128, the 1:64 image 44x64

That might still be an almost recognizable face, at 1:32 or 1:64

It might be interesting to see what happens if we take a Squeezed DC frame, and only unsqueeze up to 1:16, 1:32 or 1:64. Then use the fancy 2x, 4x or 8x upsampling to turn it into 1:8, and from there on treat it like DC (so do fancy 8x upsampling again)

If DC takes 10-15% of the whole file, then likely you can get 1:16 in 5% or so, 1:32 in 2% or so and 1:64 in less than 1%

And, still, I pretty often see something like BlurHash and it would be quite useful to have it without additional images, scripts and actions

1:64 is pretty much a blurhash

It can of course never be as fast to load as something that's inlined in the html, since an image is another request, but other than that I think we should in theory be able to show blurhash-like stuff from the first 200 bytes or so of an image with progressive DC

(or a modular image using squeeze, for that matter)

On the front page of HN, but not much commentary or upvotes to stay there for long https://news.ycombinator.com/item?id=28468284

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

ok at least there is a prominent suggestion to use jxl

> Put all the images as single frames into a video file. Write a custom program that lets you browse the images from the video frame-by-frame. > All the advantages of modern video encoding tech but with images. what if they're different resolutions...?

> Wait, sorry, I was reading the chart wrong. LZPM is the king, though it's not open, it seems. <:Thonk:805904896879493180>

well the graph is kinda confusing at a glance

i think it's supposed to be lower is better

since compression ratio is x size

Note that lossless pik and jxl -e 3 are pretty much the same thing

"lossless pik", nice <:HaDog:805390049033191445>

Also, yes, this image is better compressed by WebP, but still, selecting some rare images that are less efficient compressed in JXL does not really change that it is better overall, especially since JXL lossless has a lot more room for improvement But, it would be nice to have a set with similar screenshots containing text, although to collect enough images is not so easy and also difficult that the text on them usually contains advertising, offensive language and other non-neutral things