JPEG XL

Or if the lead was about "JPEG XL site" (without "official" and "unofficial"), would that itself be too risky?

Community is a nice word, actually. It avoids giving the impression that it is officially endorsed by anything, and that it is something by and for the community. Maybe would be good to also link to the github source of the page and encourage people to make pull requests with updates.

Anyone want to make a pull request to do such an update? 😉

Yes, "community" is better, because "unofficial" more often means that the developers are not involved in any way

sounds reasonably

no idea, I don't have anything against it but I don't really know...

I don't mind anonymous commits

https://www.reddit.com/r/firefox/comments/nb770d/jpeg_xl_support_has_been_added_to_firefox_nightly/

beaten by HEIF (and AVIF) at very low bit rates I'm okay with this. I welcome a format that improves quality at high bitrates instead of the popular (bitrate-)race to the bottom we see with video formats (e.g. in YT, AV1 looking much softer and less detailed than H.264). 🥳

To be fair, it's not like YT actually cares about quality <:kekw:808717074305122316>

Plus it seems like we have the best lossless performance out of all the general formats in most image types

When I ssy general formats I just mean formats like avif, heic, webp, and not things that are specifically designed to get extremely good lossless compression

yeah, one downside is that lossless decompression is fairly slow though

In most formats that do both, lossless is slower than lossy to decode (usually just because there's more to entropy-decode, and high-quality lossy also takes longer to decode than low-quality)

Just did a 1h interview with CNET's Stephen Shankland, it'll take a while but there'll be another CNET article on jxl

https://www.wykop.pl/link/6103331/jpeg-xl-na-ans-z-polski-juz-w-chrome-firefox-edge-3x-mniejsze-niz-jpg-hdr/

https://www.lowendtalk.com/discussion/171413/jpeg-xl-better-than-webp

got a bit of a spike of visitors to sneyers.info/jxl/art yesterday and I wondered where it comes from - I don't do the analytics thing but I can still see the referrers in the server logs

Oh, Wykop.pl! It's a Polish counterpart of Digg (it has buttons *wykop* – "dig" and *zakop* – "bury"), but somehow still quite popular. Did you get that result from Google Search? It's rare for foreigners to stumble upon this website.

I guess most don't set the referrer, the majority of hits are "Direct Request"

I believe search engines stopped using referrers many years ago. Most of it is probably from search results.

Yes, probably. Still somehow have a few referrers from www.google.com though

Oh no, that will take a couple of weeks

It's going to be an article about the subject, not just an interview specifically with me. The reporter still needs to do more research and write the article.

ooh hope it's a good article 👀

i hope webp is also mentioned

Yeah, I don't think describing codecs by saying what they are trying to replace is the best kind of description

PNG was historically a GIF replacement but then GIF just became a synonym for animated GIF, which PNG didn't really do in the first 2 decades of its existence

J2K was surely meant to be an upgrade to replace JPEG, but that didn't happen

I changed the description a bit. https://en.wikipedia.org/w/index.php?title=Comparison_of_graphics_file_formats&type=revision&diff=1023462790&oldid=1022548788

Better now? https://en.wikipedia.org/w/index.php?title=Comparison_of_graphics_file_formats&diff=1023589323&oldid=1023462790

Yes, better

That page sure does have some exotic formats on it, lol

maybe it would at some point make sense to split it up in "most important" formats and "exotic / historical" formats according to some criterion. "Has a media type" could be a criterion, for example.

(it's mostly just that the table is so long that it doesn't really give an overview anymore)

But JPEG XL does not currently have an official media type; it is still provisional. And WebP does not yet have an official media type either. So under that criteria both should be removed.

yes maybe that's not the best criterion. Supported in a browser and/or OS?

basically just not things that are _only_ supported in, say, one application from a few decades ago plus ImageMagick

Well, JPEG XL is not yet officially supported in any browser either...

Or maybe the decision could be made based on count of web search results?

Since you can sort on any column, it just needs to have a column for any criterion that people might want to use.

Add column for 'main article', leave empty for ones that don't have one and sort on it by default? (so notable formats go first, alphabetically, followed by the exotic ones?)

Another German article: https://translate.google.com/translate?sl=auto&tl=en&u=https://www.soeren-hentzschel.at/firefox/firefox-unterstutzung-bildformat-jpeg-xl/

It doesn't surprise me. The author just helps people. Useful.

"JPEG" can mean many things, from libjpeg-turbo default `cjpeg` (totally unoptimized) to mozjpeg or guetzli (very optimized)

so "up to 2x better compression than JPEG" can also mean many things, especially since "up to" technically only gives an upper bound, not a lower bound

Even if you specify what exactly "JPEG" means, you still have to define how to measure "better compression", which is where it gets really hard. Do you trust an objective metric? Which one? (they can have very different opinions). Do you do subjective experiments? With what methodology?

In my experience, JXL is competitive with HEIC, and just like AVIF, it tends to be better at the medium to high fidelity bitrates while HEIC/AVIF tend to be better at the ultra-low to low bitrates.

That is with the slow HM encoder for HEIC. With the actually deployed HEIC encoding Apple is doing (which is using small independently coded tiles), it is probably worse than HM.

Image sequences: yes, jxl supports that. Image derivations: kind of. Orientation and cropping can be done in a reversible way.

that's a philosophical discussion I guess

jxl supports multi-frame images where frames can either have a zero duration (then we usually think of them as layers in a composite still image), a non-zero duration (then we usually think of them as frames in an animation), or a timecode (then we usually think of them as photo bursts / sequences)

Can you add examples using timecodes to your coverage test? Or how would one generate them?

Right. We don't currently have any input format for that.

But I would guess that it is more user friendly to allow multiple inputs and commands to set animation duration and timestamps instead of relying on obscure input formats (like ;PSD).

Can the duration differ per frame?

Yes, otherwise you couldn't convert GIF/PNG to JXL. Though I wonder what should happen if you combine zero and non-zero duration frames.

The obvious answer is that an image file in general represents a sequence of multi-page frames, where every nonzero delay represents a transition to the next step in the sequence, and every zero delay represents a transition to the next page within that multi-page frame.

That is specced. Zero duration frames have to be coalesced before showing them.

Zero delay is not used for pages, but for overlays.

For pages we will have to have some convention, like a duration over 1 hour, or whatever

That's kinda sad that it wasn't covered by the spec, like in TIFF: https://discord.com/channels/794206087879852103/794206087879852106/843889410541355068

Pages is basically about when to show frame seeking buttons instead of just playing back

The spec says how to decode the things, not really how to present the result

Last time we talked about that, you said I could decide between non-alpha zero duration and a long duration. ^^ Is this "1h duration" your final word? 😁

Or maybe 1 year, to keep it safe in case someone wants to make a really slow animation

Btw, maybe let's change channels?

Channels are more like guidelines for conversation than actual rules

But this convo is kinda split between here and <#794206170445119489> ^^

we can add a box...

what if i wanna collection of animated images each playing in loop :^)

or a collection of collections <:Thonk:805904896879493180>

lets make it recursive

jokes aside: recursive animation could be actually fun for creative kind of stuff, like jxl art

could do sort of mini movies with some animation looping around then other stuff continuing but yeah im going way offtopic here

<@456226577798135808> <@792428046497611796> dude responded quite quickly and made some constructive criticism, the article with improvements based on that discussion and additional enwiki edits is waiting for review 🙂

JXL gives "up to 3x better compression" than JPG 😄

being default on in major browsers is the current adoption blocker

once that is resolved, there are 1000+ website and image optimization and SEO professionals on the planet who will start carrying the ball

I think we may need to help to do a few examples, but we don't need to move the bulk of the field once a workable solution is there

for %i in (C:\Users\User\Documents\bn2*.jpg) do cjxl -j -s 6 -q 63.52 --epf=2 -p --gaborish=1 --patches=0 --dots=1 --use_new_heuristics %i %i.jx or q 81.9 av1enc are impressive or not?

or we can get even some better results

Pixel camera team decides about such things for Pixel phones, Samsung's camera people decided about it for Samsung phones etc.

also does the tv support jxl

the advantage needs to be compelling and the interoperability needs to be there first

like a samsung qled tv

with tizen

I think viewing will come there first, some cameras will provide both options

jpeg option as a default in cameras will likely disappear 5 years from when the viewing problems have been fully solved in new tech

exactly

there will be devices that have proprietary hardware that cannot even be upgraded because the open source solutions don't have the proprietary drivers

you either use them with "Android 3.11" or don't use them at all

time will fix these problems, and time goes surprisingly quickly

i think you should force samsung like aomedia did

next year you try

I think after browsers, the next step is OS level support and authoring tools (in particular gimp and photoshop).

and samsung what will do if this goes right

is yet that simple?

I think cameras will only start producing jxl once it's easy enough for end-users to open/view a jxl

No. AOSP jxl support is enough.

no also tizen should have jxl

without buying a new tv

is right for users

i did not buy anything

but i think they don't

because of confusion

they are new samsung tv that have a less ram or processor

and also for virus security risking

like jyrki said

jpg and av1 support is authorized through a driver

that usually is a small part of the chip (motherboard) that does hardware decoding

but sure jon knows better than us

i think it should be forced and not like av1

but is wrong

Hardware decode is not really a thing for still images

but still jyrki has said that there is a driver

Browsers is first priority

So what you will do about tv

will you differentiate about the ram

and processor

and serve jpg and jxl

in base of what they have

Also moving to a public github, and then maybe do the plugins in a separate repo and get help from others to fix the issues with them

It's always good for users to get new features just by software upgrade. Unfortunately manufacturers and vendors get no money from that so they don't do it as often as they could. Luckily there's a growing movement towards repairability and longevity of electronics, e.g. in France, EU, USA.

usually tv hasn't a browser with images

and they use webp for ads

Currently the only plugin that actually kind of works is the Qt one, which is one someone else made 😅

so what it depends

on the ram, processor or what samsung what to do?

gdk works pretty okay too though

The gdk-pixbuf and gimp plugins are buggy and incomplete

jyrki has said the driver is not good

they will make a new tv with jxl support

and an allowed driver

gdk ignores icc and doesn't do animation

oooof

Jxl hardware support is not needed for TVs. Need not to worry.

yes but i do not want to convert to png

TV cpus can handle jxl decode just fine

but the software like of the usb

smart tv don't read jxl

no smart tv has jxl

how you will add

the permission

the allowed

That's up to them to do

it needs a driver a good ram

They can use libjxl

a good os

a good cpu

a good version of tyzen

what is needed

Anything with a cpu will do

<:AngryCry:805396146322145301>

more generic than aomedia answer

at least jyri has said it needs a software driver

Not sure what you mean with driver

ah

realzied

Do you have jxl driver on your windows pc?

just an update of the gallery application on samsung stores

that's difficult

first you need login to samsung

then samsung will not do

because they don't want security problems

or some devices low end with no support

Smart tvs will just need to update their image viewer thing to have jxl support, it shouldn't be harder than adding jxl support to a Windows image viewer

but how is feasible according to you

to do a new samsung viewer

or to do a new viewer not authorized

for thirdy part

If you need jxl support on TVs then wait for atleast two years and then shop for new TVs. Many users don't care if their tv support jxl or not

Well probably will take a while before they'll even bother with it, and probably they'll not backport it to older tvs because they need new features to sell new tvs

honest

so just buy a tv and convert to png

and do not open samsung store

or tizen store

to search virus apps or the apps they recommend

when there is a update it will say automatically

also updates arent' necessary

~~Totally didn't try to clean a part of my keyboard and spammed something random~~

my LG TV from 2016 got an update a few days ago

it’s worse now

How

now, it displays its menu when it wakes up and I have to dismiss it, and I have the vague impression that the handling of switching between different HDMI sources might be slightly buggier than it already was

I wonder how much GPL enforcement could help the android update situation

A lot actually.

You can use banking apps with magisk.

That's how I use 😂

I updated en, cs and eo Wikipedia articles. Whoever speaks other languages, it's your turn to update the respective articles. 🙂

link to source code :^)

I've already noticed it some time ago, I can't link the messages directly bc I'm on mobile

That's what I've been doing and that's how I found possible discrepancy between the code and the spec

interesting

Indeed

<@179701849576833024> maybe it's time to revisit it?

Ohhh

<@!416586441058025472> If you aren't sure how to edit the Spanish article, I'd suggest to edit it anyway. And if other editors later think that they can improve it, they can do it…

comunidad is a bad word

a person in a comunidad

at least in italian

as i said before in the deleted message

ok

And if you don't feel like editing it yourself, simply leave it to someone else. No problem.

andare in comunità.

group home in english

right

i won't edit

i wait until spanish recognize the problem

i can't translate sorry

That is actually an off-by-one bug. It's supposed to be 4.

(or the place where it gets tested should have been > and not >=, whatever)

reference frame indices are signalled with 2 bits and have the range 0..3

so you can have 4 of them

yup, sent a fix 🙂

There is always a bug

well maybe at some point we will have a bug-free implementation

but that point is not today

🙂

At some point all remaining bugs will be "features".

https://www.softzone.es/noticias/programas/trucos-activar-jpeg-xl-chrome-firefox-edge/amp/

https://www.soeren-hentzschel.at/firefox/firefox-unterstutzung-bildformat-jpeg-xl/

https://wpguynews.com/the-humble-img-element-and-core-web-vitals/

Damn, I didn't know that I was Jon Sneyers as well <:kekw:808717074305122316>

Some people are so short-sighted to be honest.

The dots in the chart are rather vague, and the lack of granularity can be misleading about the magnitude of differences.

its good for promotional material but shouldnt be quoted as source tbh

and it could be even better as promotional material if it was more detailed and reproducable

tbh idunno. links to benchmarks, links to relevant patents or someone discussing them, or even notes why some things are like they are

it would no longer be single image but i think it'd be better

so that readers aren't left with only claims without being able to see more into concepts what are being compared

a lot of things were obvious and agreeable for me, but i totally see how they may not be for people with different backgrounds

Yes, that table has a lot of [needs reference] left

Some of it is based on all kinds of benchmarks that were done in JPEG, but those are internal documents and I cannot just put those online somewhere publicly.

We do need more public benchmarks and independent feature analyses

Depends on the image

Low fidelity is when everyone can easily see the image is not the same as the original when you put them side by side

Medium fidelity is when that's hard to see in a side by side comparison

High fidelity is when that's hard to see in a fliptest

(but of course these are not strictly defined categories and this is just my interpretation)

Squoosh has both slider and fliptest options

Slider is a bit in between side by side and flip

Yes, well you can go closer or zoom in more and then you're basically testing higher fidelity

Or zoom out and test lower fidelity

Ideally you test at 1:1 screen pixels from a typically viewing distance used for that device/screen, because that would be the most relevant fidelity target

I consider the main task of lossy compression to be reducing the bytesize while maintaining a high fidelity, both for audio and images. It should not require manual comparison or quality selection to set it to a "safe" amount of compression.

Performing well at lower fidelity in the sense of hiding the artifacts well so they are not annoying, is a "nice to have", but I think it's more important to have a "safe setting" with no surprises, that can be used without manual checking, and to get good compression densities at that "safe setting".

that's not *quite* the same though, human vision is pretty scale dependent

we have compare_images somewhere in the jxl source code

can do slider and flip

with three images at a time even 😄

(usually it's compressed A / compressed B / original)

IIRC yes

I think we compile it with LCMS to support LUT monitor profiles

True, and also things get a bit different when pixels are enlarged to big squares

https://media.tenor.com/images/9cb579d693b640a0f11f74c5a3f0a530/tenor.gif

I have to accept defeat and learn to live with the fact that I will never understand what Fabian is talking about.

when new jpeg xl

with more quality options

You want _more_ options?

no

better quality

i don't care if for jpg input it looks upscaled

for %i in (C:\Users\User\Documents\bn2*.jpg) do cjxl -j -s 6 -q 63.52 --epf=2 -p --gaborish=1 --patches=0 --dots=1 --use_new_heuristics %i %i.jxl

as long i can get more png quality

like and higher or lower quantizer

more range

like big quantizer is better

Our goal is to get rid of experimental options and try to let the encoder Just Do Something Good

i need to sum more

i miss demo video of quantizer in youtube

just to see how jpeg xl looks with the terrible hw argos 2.0 superfast preset

in youtube

Jpeg xl is not a video codec

will you upload selection of blocks

with next version of jpeg xl

at s 9 if possible

and -q 63.52 at least and higher lower

who commissioned that ant video

ISO or you made by yourself for scientific purposes?

then upload in your site in an animated jxl

we'll see if we can decode

a 10 mb animated jxl

but the mp4 version with argos 2.0 superfast will be beautiful to see

The blocktype selection video that shows what happens for various fidelity targets?

Could do that as an animated jxl I guess

really

I don't think it will work, my attempts at reverse engineering knowing that it might be badly translated Italian usually fail too 😛

Transcoding human language also creates generation loss

So DeepL will likely not help

Especially if you start with something that is already quite lossy

Knowing Fabian for years through the AV1 server, it's not translation (except sometimes), it's just poor expression of his thoughts or poor understanding of things, but a big desire to communicate about something

Oh no... I think probably my poor english also mess up something... 😢

I wonder why JPEG makes people think about patents

JPEG had arithmetic coding which was patented at the time, but it was optional, nobody implemented it, and for all practical purposes it doesn't really exist

I think the only other patent-encumbered stuff JPEG has done is JPEG XS, which has a very narrow/specific use case and the general public probably doesn't know about that codec at all

English is not the main problem, I also never learn or know English, I understand words and can read, but I can write and form sentences wrong, but at least I try to write understandably

Yep, and I've posted this thread here before

4chan people are so impolite and ignorant, it kind of feels like a children's playground to me

If you want to read very strong opinions based on very weak understanding, it's a good place

But, sometimes there is a much better understanding on 4chan (except obvious trolling) than on some more intellectual platforms

you shouldn't be taking things said there directly tbh. shitposting is sometimes too fun

Reddit, Twitter, Hacker News, personal blogs, other news sites and etc.

And on mypornvid, you can watch Jon talk(not nsfw) 🙂 https://discord.com/channels/794206087879852103/822105409312653333/837941378058813450 https://mypornvid.fun/videos/12/lqi5U6dxeZU/xl-jpg/next-gen-image-format-jpeg-xl

I can't stop laughing. This is very funny.

when it was recorded

May 2019 iirc

That website is very sus. I don't see any nsfw videos.

Compress me harder daddy 🥺 😳 👉 👈 `PIK FUIF` 🍆 💦 🥳

Squeeze those splines, yeah baby yeah! https://c.tenor.com/Yt2_Fb3TD3IAAAAM/austin-powers-mike-myers.gif

Damn, I didn't know that JPEG XL was proprietary garbage.

That's why I can just go into the code and make small modifications by myself, correct?

It's only JPEG-XL when it comes from the Jixèlle region of France. Otherwise it's just sparkling awesome compression.

i don't find jixelle on google

<@!416586441058025472> It's a pun on the pronounciation of "jxl", written in a French-sounding way.

Appellation d'origine protégée

Jixèlle A.O.C. Vintage 2021

https://github.com/GoogleChrome/lighthouse/pull/12535

I'm trying to update the lead of index.html. I used GitHub Desktop and edited the file. What's next? Shall I create a new branch to be able to make a pull request? (I'm not very experienced with versioning. I find it quite complicated, compared e.g. to a wiki.)

What I've been doing is: fork it, create branch from master just for that patch, clone my fork, edit the file, commit, push and then make a pull request to the original repo. And I'm using `git` CLI 😉

I've set up an SSH key (for GitHub and GitLab) and my PGP key (for signing commits with `git commit -S`).

Why da hell is it so complicated? 😖

Just use the web interface for simple edits.

I haven't used it that much, but shouldn't it fully guide you from editing to the pull request and make the rest behind the scenes?

Web interface does the clone/branch/PR for you

Everyone knows these parameters: for %i in (C:\Users\User\Documents\bn2*.jpg) do cjxl -j -s 6 -q 63.52 --epf=2 -p --gaborish=1 --patches=0 --dots=1 --use_new_heuristics %i %i.jxl

It seems this will make a fork. How do these forks work? Are they public? Is it a good idea to keep the fork for editing next time? Or is it OK to delete it afterwards (and make another next time)?

A fork is just your personal version of the git, which you can keep in sync with upstream or you can diverge and make your own thing

Basically in wikipedia editing you always have a single branch, so you have a linear history. In git, you can have multiple branches, and more complicated histories (though in many cases for a single project you also just have a linear history in the end, with branches only temporary for experimentation)

Thanks for your help, <@456226577798135808>, <@456226577798135808>, <@!794205442175402004>. I made a pull request…

that's slightly surprising to me but I guess it follows from something happening at some point that resulted in someone being sued, and that's why now it's there... (pure speculation though)

I think the cla bot is just checking every repo hosted there

I'll continue baseless speculation and assume yes

But doesn't hurt to have a cla signed for contributions

Also to a website

I also assume that I really really don't want to figure it out xD

the main reason why CLAs exist for apache or bsd projects is that otherwise it's always a nightmare to change the license - even just for things like Apache2 to BSD

I guess we need to decide on a license for the website

well, IANAL but suppose someone sends an image to the website that it turns out they didn't have copyright for...

Or just text

Or if they contribute something and then we need to ask their permission whenever we want to do something else with it, like use it in a white paper or whatever

CC BY-SA for the website probably makes most sense, right?

I really really dislike copyright in most (possibly all) of its forms, and all the legal stuff that comes with it, but I guess CLAs are a necessary evil

Copyleft is a nice hack of the copyright system though

I dunno what the google bot wants, I would assume github account ID is enough?

don't ask me, don't need to sign those 😛

for golang stuff i needed google account iirc

which is like.. not actually good requirement

I think you just need an email address that matches the one you do the commit with

just try it and see if it lets you without google account

It doesn't need to be a gmail address, any email address should work

it was over a year so i don't recall exact process

it does ask me to log in to my google account if I try from a private window

that's somewhat disappointing

It's funny that the Name field isn't mandatory (unlike other fields) but if you leave it empty, the form wants you to fill it in. 😜

it's all stupid and imo really shouldn't be required for docs fixes

For a small fix it is of course a bit silly, but what when someone has a substantial contribution, say a full extra page with benchmark results or something like that?

hard to justify when that requires google account and real name

not quite. one can troll and spam without signing CLAs

it's probably just some legal bullshit reasons

it's not necessary at all considering a lot of open source projects don't have them

how would patents even work with docs stuff

patents purpose is to publicly document things on their own so to kill trade secret stuff

I'm just speculating, but probably the reason why it requires a Google account is that whoever developed it just didn't consider the effort of making it work without a Google account worth the benefit 😛

i know the reasons too but that doesn't mean that i like it or that i don't want to oppose it :P

Copyright is an issue in case a relicensing is ever needed - tracking down all copyright holders to get their approval can be nearly impossible after a few years when some of them may have disappeared from github

Like upgrading from CC BY-SA 4.0 to 5.0 if that ever becomes a thing

Facebook now left a comment on Firefox's JXL bug in support of JPEG XL: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18

nice 😄

Wow, that's quite good praise right there

this also got mentioned in the request for position: https://github.com/mozilla/standards-positions/issues/522

https://www.drwindows.de/news/newssplitter-einige-wichtige-firefox-news-der-vergangenen-tage-im-ueberblick

https://www.openmandriva.org/en/news/article/openmandriva-lx-4-3-rc-available-for-testing

<:JXL:805850130203934781>

I honestly don't mind either way 😛

JPEG_XL

JPEG XL JPEG-XL JPEG_XL JPEG*XL JPEG^XL JPEG#XL JPEG@XL JPEG~XL JPEG`XL JPEG+XL JPEG=XL JPEG:XL JPEG;XL JPEG'XL JPEG,XL JPEG/XL JPEG\XL

Nobody wants an extra large JPEG 👀

Only their JPEG extra large

J'ai peg excelle.

G X L

~~PikFUIF+~~

À mon avif, j'ai pègre excelle.

(said the somewhat confused frenchman with a lisp)

> with a lisp ((((À mon) avif), ((j'ai pègre) excelle)).)

https://twitter.com/kornelski/status/1302200119731855360

https://twitter.com/kornelski/status/1302201131909681157

Finally something in Czech but not written by me 😜 https://www.root.cz/zpravicky/openmandriva-lx-4-3-se-blizi-vysla-rc-verze/

I'm still waiting for that moment in Polish, seems like almost nobody else from Poland is interested in JPEG XL (there are barely any articles in my language and most of them were outdated, from ca 2018).

First look at JPEG XL progressive rendering! https://youtu.be/-7k3H2GxE5E?t=1248

More likely DCT preview and incremental decoding

No time to watch it right now, curious though

With full progressive, the whole image would be rendered completely and smoother, but here I can clearly see only sequentially and fully loaded tiles But perhaps because it is not yet fully supported in browsers

It renders each block progressively separately.

Do you mean top-to-bottom or whole-image getting progressively better like progressive JPEG?

Yes, it would be more like a progressive Jpeg, and what is shown is just a DCT preview + sequential tile rendering

I figured that wouldn't be the final rendering style - especially since the browsers don't support it yet and all the image viewers just "pop in" the fully rendered image. Truthfully, not sure how they even got that video of rendering - maybe simulated using the image broken into smaller images?

Perhaps in Chrome this kind of sequential rendering already works, but does not yet support full progressivity

This is how default (non-progressive) jxl can be rendered

Perhaps, but in that video they stated that progressive was not yet implemented in any browsers. Could have been a mistake.

It is not yet implemented in browsers

You can simulate it by truncating a file and decoding it with djxl --allow_partial_file

Oh, so maybe that is how Chrome is rendering non-progressive jxls to "simulate" progressive rendering when the file was not progressively encoded.

That is how Chrome will be rendering it once implemented. That still needs to happen though

well, it's how it will render it *unless* you have a progressive JXL file 😄

I kind of like that way of loading: it combines the best aspects of progressive and incremental. You get a nice preview, but it is still clear what the loading progress is and when you have the final image. Plus it's limited decoder overhead (basically the only extra work is the dc upsampling).

I suspect that is also why it took so long to start - granted it could be bugs not yet fixed as they are working on it. I suspect an actual progressive jxl rendered progressively would probably load faster if not just as fast as the jpeg would in that example. So technically they showed a non-progressive early render without stating it wasn't actually progressive. 😉

Well with defaults, it's not only the DC but also the ACMetadata that gets encoded in the dc groups, which does give you full dc later than if you first do only dc

For that you would need --progressive_dc=1

(forcing a separate dc frame)

did i exaggerate with the issue i opened

However, even this non-progressive rendering in JXL looks pretty good, given that it does not need to do anything extra and will not increase the image size or add complexity in decoding as it may be with progressive

also in this video

jaffathecake

said similar things

say wp2 is hype

jxl is when you want a photo to view on screen size at high quality fidelity

I agree, except in the beginning I think there were some missing blocks which was a bit odd. Maybe wait till all the blocks can be rendered so there are not missing blocks showing.

and not at least possible file size and not based on avif to him it's a bad thing but it ounds a bit bad promising on web

that how i understood

he said on 24:00 if i remember right

obviously in the video he uses English

They don't really talk much about WebP2 - just that they are working on similar features that JXL has rather than being a video format.

Probably some bug, but in practice at typical internet speeds and image sizes all this rendering will happen in less than a second, so it does not change something much, in the video it is intentionally very slowed down

In chrome we'll not show anything before we have a preview of everything

While true, I have been in areas where mobile internet is rather slow and could see that. In developing nations internet can also be at 2G/3G speeds. Just saying I feel it would look a better visually if they just wait for the entire row to be rendered before doing the render.

jpeg xl at lower quality has too loss

In the bitstream, you get DC in groups too, which correspond to 2048x2048 regions in the image

do you advice to encode something with that version?

https://ci.appveyor.com/project/EwoutH/libjxl/builds/39328673/job/0perh7t4aiii724h/artifacts

i don't find it on github

Yes, sometimes it happens even on a good internet with some sites or routes https://discord.com/channels/794206087879852103/803663417881395200/844293123672768572

Fabian I have no clue what you are asking

that version of ewout

is good

patch-1 02b76c43

0.3.7

I assume that is more an issue where a large image was used where a thumbnail should have been. That happens periodically, mistakes get made once in a while.

I'm calling wp2 "hype" right now because it seems so far from being ready. Maybe I'm wrong. I don't want folks to start saying "wp2 is the future!!" until we have something more concrete. It's kinda difficult to talk about something like that without getting people over excited, or sound like you're dismissing the thing

The settings I used for the JXL in that video came from <@!794205442175402004> btw

too early to say anything about wp2 atm tbh. I don't think that saying it this way is dismissing the thing

It's too early to draw any conclusions about it when the bitstream is not finalized yet and the code is still mostly unoptimized.

I can comment on it based just on the project goals stated on https://chromium.googlesource.com/codecs/libwebp2/ though. If those are the goals, then I wonder "why not just use avif"...

I do agree, even early testing comparing an equivalent AVIF to WebP2 there seems to be little difference in output on a number of images I tested. I feel if the development takes too long and doesn't deliver enough features, everyone might just decide: "well, we already have AVIF & JXL... do we need another?" On the other hand, if they end up doing a lot more optimization/performance and add in some JXL-competing features like progressive decoding & better high & lossless compression, and it could have the possibility of replacing AVIF and being a larger competitor to JXL in the future. *Too early to tell yet, will have to wait & see.* ™️

Progressive and being faster than avif don't seem to be things that are on the roadmap/desirables list though.

Was the JXL progressive rendering actually done in a browser or image program or was it simulated?

https://chromium.googlesource.com/codecs/libwebp2/ > As of Nov. 2020, WebP 2 is only partially optimized and, roughly speaking 5x slower than WebP for lossy compression. It still compresses 2x faster than AVIF, but takes 3x more time to decompress. The goal is to reach decompression speed parity. Seems like performance may end up becoming a big thing at some point. As for progressive rendering they clearly have that on their feature list but I doubt it will be as robust as JXL.

simulated 😄

They have "incremental decoding" on the feature list, which is basically just what sequential jpeg does, or webp1.

Having it start rendering while downloading is still better than just an empty space.

Yes, of course. That could probably also be done for avif though, it's a matter of decoder api, no need to invent a new bitstream for that...

Progressive is something else, that you need to have in mind when designing the bitstream.

Jake said in the video they don't even know if it is possible to do any kind of sequential or progressive rendering with AVIF. Currently they are looking at putting a small few kb thumbnail image in the container ahead of the full image that will probably be displayed with a blur while the full image downloads.

blurha.sh

a) Never good to rely on a third party library for things that should exist in a modern web image format b) Those seem to be **too** blurred. At least including a small thumbnail can have enough detail that you can make out the subject of most images

i see the advantage of blurhash (or something similar) as that it's just a string so you could include it in something like an api response, so the browser has something to render before it's even opened a connection to retrieve the full image or thumbnail

You could also use twim by <@!811568887577444363> 🙂

link? can't seem to find it

Blurhash is cute, but it isn't really a useful preview. You can't really tell anything about the image. Whereas a 1-2k blurred AVIF gives you a ton of structure.

https://avif-blur-preview.glitch.me/

Not working on Firefox

yeah it only shows the blurry one

Yeah, Firefox doesn't support the blur method

oh no firefox supports blurring with `filter: blur()`

but you seem to be using a backdrop filter with a div on top of the image for some reason

firefox doesn't have backdrop filters on by default, i actually have them enabled in about:config but it seems to apply backdrop filters even when the element with backdrop-filter set also has `visibility: hidden`. chrome doesn't apply filters in this case

idk which behavior is correct but can't you just put a blur filter on the image itself?

anyway that's a cool technique but not really a fair comparison between 20-30 byte blurhash and 1-2kb avif

the idea with blurhash is you could have in your api response e.g. (for a hypothetical movie api): ```json { "title": "Interstellar", "poster": "https://www.themoviedb.org/t/p/w600_and_h900_bestv2/gEU2QniE6E77NI6lCU6MxlNBvIx.jpg", "posterBlurhash": "mHK_n8-;_3IU~qoftRof00%MIBofIoxaIAWBD%t8xtoff,IUofRj" } ``` which gives you something to display immediately while it downloads the full poster or thumbnail. it doesn't have to wait to make another request to get the thumbnail.

We could do something like that but just put the first 200 bytes or whatever of a progressive jxl there

That could also give a blurhash-like preview

yeah i wonder how that would look

That would mostly depend on how you upsample/blur it

any trick to doing a progressive decode manually? i can't get djxl to work on truncated progressive files even with `--allow_partial_files --allow_more_progressive_steps`

It doesn't work?

Maybe it's currently broken with some of the recent optimizations

``` Read 200 compressed bytes [v0.3.7 | SIMD supported: AVX2,SSE4,Scalar] /home/190n/Downloads/libjpeg-xl/src/jpeg-xl/lib/jxl/dec_modular.cc:436: JXL_FAILURE: Undoing transforms failed /home/190n/Downloads/libjpeg-xl/src/jpeg-xl/lib/jxl/dec_frame.cc:804: JXL_RETURN_IF_ERROR code=1: modular_frame_decoder_.FinalizeDecoding(dec_state_, pool_, decoded_) /home/190n/Downloads/libjpeg-xl/src/jpeg-xl/lib/jxl/dec_frame.cc:838: JXL_RETURN_IF_ERROR code=1: Flush() /home/190n/Downloads/libjpeg-xl/src/jpeg-xl/lib/jxl/dec_frame.cc:244: JXL_RETURN_IF_ERROR code=1: frame_decoder.FinalizeFrame() /home/190n/Downloads/libjpeg-xl/src/jpeg-xl/lib/jxl/dec_file.cc:171: JXL_FAILURE: Not enough data. /home/190n/Downloads/libjpeg-xl/src/jpeg-xl/lib/jxl/dec_bit_reader.h:256: JXL_FAILURE: Read more bits than available in the bit_reader Failed to decompress to pixels. ```

i get some different errors truncating it at different points

actually it's usually that one

except for 10000 bytes ``` Read 10000 compressed bytes [v0.3.7 | SIMD supported: AVX2,SSE4,Scalar] /home/190n/Downloads/libjpeg-xl/src/jpeg-xl/lib/jxl/image_ops.h:58: JXL_DASSERT: rect_to.IsInside(*to) Illegal instruction (core dumped) ```

How did you encode the image?

``` cjxl interstellar.png -s 9 -d 2 -p interstellar.jxl dd if=interstellar.jxl of=firstpart.jxl bs=1 count=NUMBER_OF_BYTES ```

A standard blur filter also blurs the edges of the image

Remember that the browser doesn't have the blurhash decoder built-in, so you have to factor the size of that in too. This is especially the case if it's the core image on a web page

Sure, and it's a cute effect. But it isn't so great for an initial render of a web page (eg how every news article works)

is it better at default speed? there were some bugs with -s 8/9 -p

still doesn't work

interesting... might be able to give it a look next week

https://github.com/eustas/2im

ooh that looks cool!

seems like the decoder may be smaller than blurhash's

Theoretically, a Squeezed dc frame should give you a tiny but accurate 8x8 (or 16x16, or whatever) thumbnail version of the image in the first few bytes after the header stuff

So if you upscale that in a nice and blurry way, it should be quite comparable to blurhash-like approaches

blurhash is based on DCT iirc

You can basically use any modular technique to encode that 8x8 info. Actually by default it would be 8x8 luma and 4x4 chroma, if I'm not mistaken. So about ~~100 bytes~~ 150 or so bytes (it's not 8-bit but a bit more in the usual XYB case) uncompressed, but compression should trim that down quite a bit (and with a different aspect ratio than square it will be fewer pixels).

Question is if we want to make the effort of extracting that very low res preview and do fancy upsampling on it...

<https://github.com/libjxl/libjxl.github.io/pull/2> :P