JPEG XL

and like 117 kb 123 kb

but those options are good with current encoder

just copy paste the txt file i made and make a generic title like current options or save more

and publish on reddit

on tell me that you're publishing on reddit with jon as mod

you didn't say you want to publish on reddit

but i assume

...talking seriously

who can publish something in jpeg xl does a post when i publish will be published only when there is jon/ or bitlag approval?

<@!231086792315633664> can i least spam another excel link to your post

or i should make another post

i upvote and i encourage to upvote to prevent spam

i don't know tomorrow i will make the post

<@!416586441058025472> How did you come up with these arguments like -q 81.16 -m -X 4.34 -Y 87.16 -I 0.05 -s 9 --num_threads=2 ?

Please do not promote use of arguments like that.

If you feel that they are actually better than the defaults, please state your justification for them and convince the developers to change the defaults, but do not promote the use of bizarre arguments like that with no explanation or justification.

just speed and distance should be enough

Does anyone know if brave nightly has the JXL flag inherited from chromium yet?

those just come to my mind, i know s 6 and modular do not bring gains in 99% of photos

maybe you could pass the command line flag when you run brave

but if you have spare cpu why don't use

just use dct for lossy please

idk why you'd use modular

the sane defaults are called sane defaults for a reason

i stated that dct improved for graphic

modular is worse at 99 of the time even with photo

but for explicit and anime especially jpegs

sometimes i saw more than 22% reduction

but in rare cases

and obviously image look worse

dct should still be more compact

just use the distance flag instead of the q flag too

i never use modular flag

apart of lossless

why is it in your guide then

if you have spare cpu time

<:WhatThe:806133036059197491>

I hope i'm not being overly antagonistic

but your guide seems.... not objective and uh eccentric at the least

there are also the defaults

if you want to reduce the size of a jpeg beyond ~20% you can just use the -j flag i believe and encode like regular dct

it damages explicit

if they are jpg at the start

i mean if you use a d value more than 1 it will reduce their quality

*subjective quality

it would be nice if you wouldn't use pornographic imagery for testing of jxl because idk about others but I sure don't want to test them myself 😓

this is getting offtopic we should probably move to <#794206170445119489>

i don't use ...

what is "explicit content" then?

https://c.tenor.com/D8wG7Du39vIAAAAM/torre-de-babel-silvio-de-abreu.gif

<:YEP:808828808127971399>

the image is this

why two threads?

like explaining what threads are

Why not just keep default?

Fabian is an beta artificial intelligence chat bot with so many bugs 😆 🤖

it just seems like a strange decision to use two threads unless you're doing multiple images at the same time

Autodetect nb of threads is best if you have a smallish number of images to encode serially like that

so don't care

s6 can be good if you need a fast encode and i'm assuming decode

do higher speed levels use more memory to decode?

So default is better than explicitly setting two threads

i have a suspicion that my images encoded with `-s9` use more memory to decode

You don't know how many cores others have, or how large the images are they want to encode

RAM?

than a lower speed level

yeah I haven't tested

Slower speeds use more memory, in general

sorry about the offtopic

btw

now that i saved it processed

Also if you use the fast-decoding encode option, it will use less memory and be faster for both encode and decode

(for lossy at least)

ok i censored

Fabian just please don't use sexual imagery for testing the encoder/decoder

I don't speak for others but I don't want to download such imagery for testing

If you cite improvements or issues please use sfw imagery for that citation

Just common sense

thanks

to me it needs a GUI that can say the file is reduced more than 26% 30% i'll delete the original, or like a comparer

but i don't know such software

obviously for real images is not good

also for graphic like screenshots d 1 s 7 i found it way better

but i do not have claims for that

like i stated i did a graph

but is not true. is only a .doc file

<:AngryCry:805396146322145301>

<@!416586441058025472> hi. 🤖

hi

on the plus side, I guess it counts as a form of fuzzing

yeah Fabian can be a little out there but you can't deny he's done a lot of testing for the project

Especially with odd numbers Btw, I think Fabian will like this game <https://www.metacritic.com/game/playstation-4/nier-replicant-ver122474487139>

ExifTool Version 12.25 (April 22, 2021) has JPEG XL support: https://exiftool.org/

the chromium version in the ubuntu snap store in the "edge" channel now supports jpeg-xl it seems

`snap install chromium --edge`

3% of the visits come from italian

and guess many of them are editors

https://pageviews.toolforge.org/langviews/?project=es.wikipedia.org&platform=all-access&agent=user&range=latest-20&sort=views&direction=1&view=list&page=JPEG%20XL

https://pageviews.toolforge.org/?project=es.wikipedia.org&platform=all-access&agent=user&redirects=0&range=latest-20&pages=JPEG_XL

19 mobile es

52 mobile it

2 person italian in wikipedia from the android ios application

102 - 909 from the english

not comparable to other public

i guess jpeg xl is stil niche

Brave nightly is lagging behind chromium, doesn't currently have jxl

Nice. A step in the right direction: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075

In other words, T-4 to 5 years until Apple even lifts a finger. <:kekw:808717074305122316>

Hard to tell what Apple will do. They are a black box to me.

https://bugzilla.mozilla.org/show_bug.cgi?id=1707590

Very nice to see things happening in firefox!

maybe there is firefox dev here in submarine :D

Seems like the guy needs some help: https://bugzilla.mozilla.org/show_bug.cgi?id=1707681

Nah that's just our code causing something in the firefox build system to throw an error (where it shouldn't, it's one of those "hey did you really mean this? It could be a bug!" checks where the check itself has a bug, I think), and this needs to be escalated, I suppose.

sounds like they shouldn't enable such sanity checks on external code

so before you can just put a jxl in an <img> tag and expect it to work without fallback, I think 4-5 years is probably a more realistic expectation (and that's assuming all browsers will actually decide to support it)

ah it needs time browser understand this

1% of people are still using Internet Explorer, for example

so you are saying on windows 7 or on android 8.0 no jpeg xl

fallback will be needed for quite a while

if someone can descrive fallback

falling back to another format in case jxl is not supported

so converting jxl to jpg

one way to do that is with a <picture> tag, with a jpeg/png <img> and a <source> with an image/jxl

it can do without using too band for already lossless vardct

or i'm wrong

another way is server-side respond with a jxl if the browser signals `Accept: image/jxl` and a jpeg if it doesn't

(or a webp, or an avif, whatever the browser does know how to decode)

the server-side thing is what Cloudinary does when you set the format to `f_auto`

this need to include both image in a server

so you can do `<img src="http://res.cloudinary.com/jon/f_auto/sample">` and this url will return a jxl if you accept jxl, a webp if you accept webp, and otherwise a jpeg

the one with a tag

it needs to include two urls

but who will do it

include two urls

with f_auto you only need a single url

the picture tag is what you can do if you cannot implement that server logic and you need to do it with pure html

(implementing the server logic is not so straightforward, especially if you also want to do CDN-based delivery and if you want to do more than just believe the `Accept` header — e.g. some clients claim they support something but they actually have known bugs in it so you still want to avoid it, or some clients can support something but they don't signal it)

hi <@!416586441058025472> how are you?

why you write always same message

don't ping please

webp with fallback we've been doing for 6-7 years now, iirc

WebP was slow to gain adoption because its efficiency improvement in lossy mode was not big enough, in addition, in some features it was worse than Jpeg and it was a project only from Google and not some international standard or alliance of many significant companies I also remember that when it first appeared it received a lot of criticism from famous people related to video and image compression, e.g.<https://web.archive.org/web/20150319214453/http://x264dev.multimedia.cx/archives/541> And at first it was only used for very low bpp, starting with re-compressing images in Opera Turbo for more traffic reduction

The first WebP I saved from a random site was in 2017 and it surprised me. It's only since last year that I've been seeing them all over the place (using Firefox).

Mozjpeg and lossy webp are not that far from one another, webp usually being somewhat better if 420 is acceptable for the image, but the gap is not huge. It does have alpha support though, so there the alternative would be PNG and webp wins easily. For other (non-alpha) cases where you would use PNG (like logos and other non-photo images), lossless webp is consistently better than png.

Mozjpeg was basically created to demonstrate that jpeg could be roughly as good as webp, which was for a long time the justification in firefox to not add webp support.

Microsoft resisted webp for a long time because it is not a standard.

I don't really know why Safari resisted but probably a combination of the above two reasons.

The good news is that neither of those two arguments can be made for jxl: jxl is consistently better than jpeg/png/webp, and it is a standardized format.

(the only objection that can now be made is that it is not consistently better than avif)

It is also important to have a good encoder implementation from the beginning, for example lossy WebP quality was not enough to compete with good Jpeg encoders, and lossless mode was added later and it was quite slow, after some time it was significantly optimized, but the first impressions of the format were by not very well optimized implementation, because it was considered ready and started to be used

First impressions do matter a lot indeed

Codec devs know that you can only benchmark encoders, not codecs themselves. But most people think in terms of codecs, not encoders.

Of course in practice a codec is only as good as its best encoder.

don't be fooled

firefox paid for including jxl

they paid the ISO specification

is just that they don't pay every year/per device

he's pretending that is working for them

this is random file copy pasted

not true jpeg xl and updated

I highly doubt that. First of all because the actual spec (not even the FDIS) isn't for sale yet, only the DIS which is outdated. Secondly because they don't need the spec, they just need to integrate libjxl.

ok

and why AVIF can't work without spec

and jpeg xl can work with the spec

because of heif and other things?

you need the spec if you want to implement software from scratch that implements the spec

if you already have software that you can use, you don't really need the spec

are you required (as part of the ISO process) to *not* release the spec? i.e. everyone would have to go through the ISO paywall?

well, after the CD stage, it's copyright ISO

Yikes. That's kind of why I hate the whole idea of ISO. I get it, that's how they make their money, but it's hard to call a format "open" when the spec is locked behind a paywall.

it's not as bad in software because often there's at least one open source implementation, but for hardware things get really bad

I do not think it will be costly for hardware manufacturers (unlike various patents), it may be bad for some personal projects from enthusiasts, but not companies

That's the worst part of it. Those most affected by it are the open source community.

I can hear a torrent in the backgroud

YARRRRRR

https://caniuse.com/avif 63%

what i can view in avif that is italian and safe for work

avif if i remember right there is no image you can view on internet

all is jpg webp png

svg don't work

...

what means 25% global use for chrome 89

75% of people have not opened their computer

what it can mean

or have updated not enabled so they are guilty

Does AVIF finally decode properly in FF 89?

ok

in my firefox 90 it was disabled by default

I guess because it's still buggy?

I'm betting we'll get working JXL before they finally fix AVIF's decoding issues

to my seam fine but no animation

I'm still on 88 (no 89+ yet for my OS) but colors are definitely wrong in Firefox's decoding of AVIFs

Can I test?

you're welcome to. You want the AVIF?

yup

sec

https://cdn.discordapp.com/attachments/673202643916816384/834160062867832832/reel_18.avif look at the lower-right area and tell me if you see something like this: https://cdn.discordapp.com/attachments/673202643916816384/835706084600840232/greenrect.webp

or just compare to aomdec

windows photo seam more yellow but chrome and firefox look the same

hrm, may be fixed then

or is a system specific bug

could be that too

Try this one, it should be easier.

Look in the shadows. Firefox and MS Paint show them incorrectly (pitch-dark).

Which version of Firefox are you on though?

Chrome, on the other hand, shows shadows correctly, together with noise synth.

Nightly

ah, yeah, still bugged then

4 program 4 different illimination wut

photo, paint and firefox ar similiar, chrome is totaly different

And only Chrome is showing this thing correctly

paint.net s....

is paint not paint.net

i have always big problem with jxl_winthumb.dll dll to add thumbnail to windows. Tested with https://github.com/mirillis/jpegxl-wic and https://github.com/saschanaz/jxl-winthumb Who have a zero bug with it?

I tried it a couple months ago and it didn't work, nearly locked up the file explorer.

i ask to a dev: https://github.com/saschanaz/jxl-winthumb/issues/4

At first start, i works, but with all my jxl, maybe some files cause BIG problem.

https://chromium-review.googlesource.com/c/chromium/src/+/2846508

Animation soon? <:Thonk:805904896879493180>

I hope progressive comes first 🙏

Wait yeah

Progressive would def come first

Should be easier to implement than animation

that really depends on internal APIs, i think

But JXL doesn't even use progressive by default.

At least all VarDCT images have some progressive component (the 8x8 subsampled DC coefficients).

Ok, so -p is only for modular?

I'm not sure exactly what it controls. I think it's wrong to think of an image as having a single progressive or not property; there are some features in various places that permit certain kinds of progressive decoding.

Nope, it works for both VarDCT and Modular.

Yup, even the "non-progressive" mode is an improvement, compared to JPG. Sequential JPG is 100% sequential, no excuses. JPEG XL, on the other hand, even without `-p`, transmits DC and then AC. It's always an additional pass! 🙂

Fun fact: DC in VarDCT is saved with Modular. Progressive mode is just enabling Squeeze transform on that DC. Am I right <@!794205442175402004>?

Currently Chrome Beta (the only browser implementation currently) has to download the entire image before decoding.

Well, if the browser doesn't support progressive decoding, nothing obviously. Otherwise, if it's a VarDCT, the AC/DC split can still be used for progressive decode. If it's a non-squeeze Modular file, nothing can be shown progressively AFAICT.

But when Chrome finally ships progressive decoding, non-progressive JXLs should decode (roughly) like this: https://www.youtube.com/watch?v=inQxEBn831w

Oh, right, sequential decode still works of course.

Depends on whether you call that progressive...

At this moment Chrome decodes JXL like AVIF – downloads the entire file and then decodes.

But that's not all, JXL has a potential to be *even more* progressive than what's shown in the video above! 😃 https://www.youtube.com/watch?v=A4GFzarcR3U

Progressive means a lot of things: * The use of squeeze mode in Modular encoding (directly, or for the DC component of a VarDCT image), a choice controlled by -p in `cjxl`. * Decoding partially downloaded images (sequential or not) * The ability to decode a partially decoded image at full resolution but reduced quality/resolution (which can be done through the AC/DC split for varDCT images, and through the squeeze mode in modular).

Right, <@794205442175402004> ?

Yes

Actually there are 3 kinds of progressive in VarDCT mode

One you always get: the 1:8 image ('DC') goes first

The second is that the AC can be done in multiple passes, e.g. to add steps for 1:4, 1:2 (very flexible scan scripts are possible since you can basically send all AC coefficients multiple times and they get (shifted and) added to what was there before, so you can also choose to pretend some non-salient part of the image has no detail in the first pass, and then add the detail there later.

The third is that the DC itself can be done progressively, by using a DC frame where Squeeze is used.

Ah, I see!

-p activates both extra kinds of progressive, you can also do only one by doing --progressive_dc or --progressive_ac, iirc

So the AC progressive mode is redundant?

Also note that at high distance / low quality (I think above d4.5 or so), progressive dc gets enabled by default because it just gives better compression

AC progressive does tend to come at a slight density cost

It doesn't have to be redundant: you can also do scan scripts like in jpeg.

(send coeffs from low freq to high freq and msb to lsb, not sending the same one twice)

But our entropy coding doesn't really know which coeffs are being sent: all you have is a coefficient ordering, and you always encode all coeffs (though the ordering permutation can be different) and use the fact that tails of zeroes are cheap

Insider information (:P) says that likely Chrome won't actually implement below-DC progressive steps

at least not to begin with

if that's actually the case, then maybe we'll change -p to mean more or less the same as --progressive_ac...

Main thing to get in Chrome imo is the simple two-step progressive: DC, then full image (sequentially per group)

That is the uncontroversial kind of progressive (still obvious when the final image is loaded, not a lot of re-renders)

(well, relatively uncontroversial - there will always be someone who doesn't like it, whatever you do)

pre-DC progression and several AC refinement passes is 1) less important, 2) more controversial, 3) has more significant speed impact so need to be careful to not do too many renders.

But just the DC is already a very nice preview that is likely at least as good as any preview frame you'd want to add to AVIF, and it's always there (well except in non-squeeze modular but if you use that on the web it is likely for small images or images where progressive isn't that useful anyway)

well, the AC refinement passes IMHO are not controversial 'cause you only get them if the webmaster explicitly asks for them (and they can be made cheap on a fast connection)

there's no reason to enable AC progressive unless you *want* AC progressive, so I don't think there's any reason to not implement it 😛

Yes, I guess from Chrome's perspective that is true

I meant controversial among web devs whether it is a good practice or not (90% of them seem to think yes, but a vocal minority claims progressive is bad)

Is there yet an Android viewer?

There's no reason why an existing image viewer app couldn't be updated with jxl support

For now the dll thumbnail for windows (don't work well) need to decode all the picture (that's the same for all software, maybe a dev will create a superfast thumbnail viewer for windows and software. 😄

0 for now

Sucks

Go to ask to all dev of your favorite android image viewer 😄

I've sent messages but gotten no answers. :/

New chrome canary update support jxl with --noise 1 option 😄 All jxl file seem to work, exception animation.

But there are zero progressive decoding.

I was first, AGAIN 😜 https://discord.com/channels/794206087879852103/794206170445119489/838873194370826280

But I'm glad that someone else also noticed this. Good job, Chromium & JXL team!

News update from WINDOWS THUMBNAIL, it works great! (some file don't display) https://github.com/saschanaz/jxl-winthumb/releases Regular people can use jxl now! 😍

There are regular linux users

HAHAHA

What even is "regular linux"?

I mean Linux users that the average persons would consider 'normal people'

although now we need a distro named that just to be able to say you run ol' regular linux

people that compile everything

do not download anything

neither fonts or all

that is linux user

code their programs

Yeah, my statement was word play, wasn't sure if yours was in some way.

https://bugzilla.mozilla.org/show_bug.cgi?id=1707590

it landed! <:Hypers:808826266060193874>

<:JXL:805850130203934781>

nice

There is no flags in firefox nightly?

We'll probably have to wait for the next build, it's more often than Chrome Canary so it should be actually soon™️

<:This:805404376658739230> You guys are a little too eager. Same with Chrome. I think FF does 2 builds a day where I think Chrome only does 1. <:kekw:808717074305122316>

I don't feel like Chrome Canary is ever updating, while FF Nightly: "An update is ready, restart now" shows up CONSTANTLY.

They added a bunch of issues to do things like color profiles and transparency so looks like it's just very barebones support right now.

😄

lets goo

alpha is buggy rip

https works, but if you want to use http that also works

https is unneeded for static sites tbh

I don't really want to force people to use https for something like my website

maybe only if browser offers header which indicates desire for upgrade

oops…

Yes, if you use http to access my website, theoretically someone could man-in-the-middle that and make it seem like there is something else on my website. So please use https if you want to be more sure that it is actually my website you're seeing.

But https also makes it impossible for proxies to cache my website, which could make it very slow to load for someone on the other side of the world.

http redirect is interceptable so redirecting adds no security whatsoever

just use https if you want https

ah I dunno, maybe because my hosting server is stupid or maybe because I misconfigured something

Unfortunately it's an upstream issue https://gitlab.com/wg1/jpeg-xl/-/issues/229

Have you tried `dom.security.https_only_mode`?

<@!239702523559018497> you're awesome

Hello everyone 😁

upstream fix should land soon

also thanks for all the work on jxl support in firefox!

Yup, Chrome's also borked...

looks like both chrome and firefox try http first, I wonder why. Both work for my site, and many sites do an automatic redirect from http to https, but that makes it impossible to access the site over http...

https://tenor.com/view/spongebob-squarepants-spongebob-patrick-star-we-have-a-bug-panic-gif-4771359

https://tenor.com/view/bugs-bug-insects-cockroaches-music-gif-5045519

we're syncing it ~~ now 🙂 another instance of off-by-(not quite 1) 😛

DAMN OFF BY ONE

well there's bandwidth and then there's latency

By the way: is the latest jxl-winthumb affected by this alpha bug?

AFAICT it doesn't happen there, not sure why.

probably because it only happens when decoding to RGBA8?

The Gecko logic is virtually a subset of the one used in jxl-winthumb, which uses RGBA8, so 🤷‍♀️

the other thing I can think of is that the FF version of jxl is newer (I introduced the bug very recently...)

Both uses 9a8f519, and thus both can decode layered JXL without crash

Wait, I didn't really released the version with 9a8f519, but anyway it doesn't happen with 9a8f519

ok, I'm confused then 😄 the bug only appears for sufficiently large images (>256 pixels on at least one side), so maybe it's that?

LOL never mind, I was looking at the cached version generated from a previous version

heh, ok 😄

we should update master and 0.4.x soon

(where soon means "hours", just to clarify)

BTW, what made you to develop things in a private repo when the source is open? Possible patent issue?

ISO policy

we had to work in a private repo because there could theoretically be non-open-source contributions from others in JPEG

That is the least expected answer to me 👀 (I'm not any familiar with ISO things)

which didn't happen

but we had to keep the option open

we're planning to migrate to open development ~soon, but that takes time and we are currently a bit busy with mostly Chrome integration 😄

ISO requires the activity of its working groups including WG1 (JPEG) to be based on technical merits only, regardless of IP status (patents, proprietary code, whatever). So we are technically not allowed to require contributions to be royalty-free and open source

We did express our desire to end up with a royalty-free and open source codec, but we were not allowed to demand that.

That's very weird, how do you plan to keep it being FOSS?

Luckily it did not happen that there were non-royalty-free / proprietary contributions.

Now the spec is final so it is no longer an issue, and we can move to a public dev repo

Ah, cool

If there would have been contributions in the past years that were non-royalty-free, we would have done our best to find technical arguments on why we wouldn't want to accept those contributions, and if that failed, we would have had to create a baseline profile that is royalty-free and an 'extended' profile with the patented crap

but it didn't happen so we can have just a single profile

yes, but keep calm i have only 1 houre late 😋

Referring to the meta bug is the preferred way https://bugzilla.mozilla.org/show_bug.cgi?id=1539075

BTW, the "Next-Generation Image Compression" name is not used anymore, right?

"The JPEG XL Image Coding System (ISO/IEC 18181)"

that's what it's called on <https://jpeg.org/jpegxl/>

ISO/IEC 18181: Information technology — JPEG XL Image Coding System

The support in Firefox is so 🆒 that I updated the JPEG XL articles in the English and Czech Wikipedias… 😜

that's the official name of the thing

but yes they don't seem to call it next generation anymore as it's very soon going to be current generation one

it already had the name JPEG XL before anyone knew what codec it was going to be 🙂

next-gen, high efficiency, that all doesn't mean much because almost everything is next-gen and high efficiency when it gets created 🙂

well, not webp2 apparently... 😛

as far as I can tell, it was actually Netflix who was pushing the JPEG XL activity the most back then, I mean before the call for proposals was even sent out

we made the codec but we didn't get to choose its name 🙂

https://twitter.com/jonsneyers/status/1281661229648564224

Jay x el

it's pronounced jxl

obviously

There is a new version of XnView MP 0.98.3, but the jxl plugin is still broken.

The "j" is like in Jyrki, Jan, Jon: not how you would pronounce it in English

And it rhymes with pixel

So "yixel"

cjxl does pixel to yixel, djxl does yixel to pixel.

But I have to admit in practice I usually say "jay excel" or even the full "jay peg excel"

<@!239702523559018497> Thank you so much for firefox support!

Can we use jpeg xl on phones already

Squoosh app

Firefox nightly

Chrome canary or beta

Arm v7 for example galaxy s4

What is the status

Good

Btw, is the default JXL support going to arrive before AVIF in Firefox? 😁

Can be

Depends on if they keep pushing it back. 90 is supposed to have AVIF enabled but JXL will likely be behind a flag.

Has libjxl already stable and good vmaf support

?

Vmaf support?

What does that mean?

I saw it on r jxl 2 months ago

Vmaf integration

Vmaf is a technique for videos

Used for 1080p or 4k encoding

I don't think it's applicable to images

We're better off using butteraugli

To encode jpg we need a tuning

And a 1.0 stable release

If You want more than 50 reduction

Does this have anything to do with vmaf?

In theory jpeg xl could be made like webp

I don't understand the point you're trying to make.

In what way?

To shtink as much as possible jpegs

As jpeg xl has good psnr

So it can

Jpeg xl is already better than webp at compressing most images I believe

jxl does not encode jpegs, it only recompresses them losslessly (but there is no tuning to be done in that case)

Plus it has lossless compression for jpegs

for jxl itself, we do tuning based on something more advanced than vmaf

In this Way i got 50 reduction

If you so chose you could go lossy, maybe add some AI denoise filter then compress it to avoid spending bits on artifacts

Jpg input

so adding vmaf tuning would be a step in the wrong direction, except if you specifically want to produce good numbers for the vmaf metric or something

Like a jpg input tuning

I don't see what vmaf and jpg have in common

Jpeg xl has good psnr so it can more than 50

If you compress lossy, it doesn't matter for the encoder whether the input is jpeg or something else. It's decoded to pixels first and then compressed.

You shouldn't care about psnr, cjxl is aiming for another metric.

What is this number 50 you keep repeating?

I would not judge a codec on a metric you got on a single image with one set of parameters

Jpeg xl doesn't have a metric of anything, your parameters and input image matter very much

Reduction to jpg from reddit

With the param on this scrwenshor

Anyway wb dont want to add more vmaf tools

He Said it would overcomplicate

vmaf is for video, not images

But for jpg a set of tools could help

jpeg is not video...

To compress them at Less than 50

50 what?

what unit is this number?

Vmaf is only good for video

And only at two resolutions

It isn't even an effective metric at some video resolutions

It would be utterly useless on images

VMAF was made based on 23 video clips

Only 23?

Netflix can do better than that <:YEP:808828808127971399>

Esp since they use it for their videos

<https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c25> HDR landed (I think)

yup

that's some fast reaction time there 😛

https://pagure.io/mailcap/c/4a12cc7caeb4a74626e8e6aedf38e7223b28e982?branch=master

https://www.reddit.com/r/brave_browser/comments/mvvx6h/jpegxl_is_coming_to_town_will_brave_be_brave/

> JPEG-XL is just going to be another webp. Yeah a few corporations will use it to save on bandwidth and storage costs but when the average user runs into one they’ll go “what the f is this garbage?” without the default photo viewer supporting the format. > > Begging brave to support jpeg-xl is hilarious because you really should be begging Apple and Microsoft to support it. i hate this take

left a comment, wonder if they will reply. 15 day old thread :P

https://pypi.org/project/imagecodecs/

"Let's not add a thing because normies don't get it."

Average user sure, but imagine being a manga/comics hosting site and suddenly being able to cut 20% of storage costs. Or something bigger like Pinterest or DeviantArt. Or a booru-type site.

I also have a comics collection myself and shrinking it is an appealing prospect instead of getting even more storage.

I think jxl with better patches will be great for manga

Or anything that uses a single font

Imagine having a comic panel and only having to encode each repeating letter once

Hm

If it's a simplified font maybe it could store a repeating part of each character?

Like a dot?

Hm

I don't know how powerful patching is

How it can translate

There are around 50 or so hiragana and 50 or so katakana which repeat frequently Also, kanji have repeating parts too and while there are 2000, some are more common than others so it could be doable

Patches already work pretty well for text, but there's lots of room for improvement for general repeating images.

In an image mosaic with several hundred unique images repeated many times, only one image was encoded with patches.

Can patches use lossy modular?

Would it be useful in any way or just stupid?

Patches can even use vardct if you want

Any frame can be used to take patches from in a later frame. Frames can be "reference only" so you can have invisible reference frames, or they can be just regular frames that have "save as reference" set in their header.

The way patches are currently used in lossy mode, does already use a kind of lossy modular: the XYB gets quantized to a limited number of shades of X, Y and B.

Ah

I think in the future when patches is improved it might be important to have a point when size > X or complexity > X of a patch to have it use vardct

Like maybe use modular for text but vardct for a repeating larger patch with a lot of colors

Yes, for something like repeated profile pics it would make total sense to use vardct patches

Which font it is

"Inter", apparently.

Ok

<@!416586441058025472> Actually, it's "DejaVu Sans". CSS says Inter, but my browser replaced it.

Ok

I'm more worried about how to *detect* such patches...

making an encoder that detects them without doing O(n^2) work is indeed an, uh, interesting research project

https://discord.com/channels/794206087879852103/822105409312653333/841279843567140874

<@!424295816929345538> I wish there was a way on discord to do "reply to this but in a different channel"

I pinged Leonard Rosenthol from Adobe yesterday evening but I didn't get a reply yet (guess he's asleep atm)

Cool

Webkit/Safari doesn't seem very enthusiastic so far, trying to ping them about it on the webkit slack but it's not a very active slack it seems

Apple / Core Image devs I don't know how to reach, I think Apple is shielding them quite well from the outside world

Shielding from bad heif rewiews?

from 'users' in general, I suppose

I think adobe is very important for all not web adoption

Apple not this much

(that's from the WebKit slack)

See codecs only as OS related is a very traditional view