JPEG XL

> lossless encoding of 16-bit integer and 16-, 24-, or 32-bit floating-point images. are "integer" and "floating point" supposed to be the other way around?

We can actually do lossless 32-bit float but not lossless 32-bit integer

Because we use signed ints

avif is on my browser

but anyway progressive jpg is important still ?

all stock images in that article are avif with the encoded sample are png

Depends on what browser you are using if you get avif or webp or jpegs...

I think progressive is great, but probably not great enough to be worth sending a jpeg that is twice as big as an equivalent avif

It's a tough call though

I'd definitely prefer progressive JPEG over even the best compressed AVIF, if I was on a modem connection.

<@!794205442175402004> is it possible for `f_auto` to add client's internet connection speed check? If it falls below a threshold (to be determined in some simple testing), serve progressive JPEG *no matter what*, because no other format available in `f_auto` supports progressive rendering which is crucial e.g. on 128 kb/s connections. Of course when JPEG XL rolls out to Chrome, becomes tested successfully (no bugs) and you add it to `f_auto`, JPEG XL will be sent if the client has compatible browser even on faster connections 😃

LQIP + incremental decoding is also some alternative for progressive, but of course it is better when LQIP is not a separate but part of the main image and when 60% progressive image is enough to get close to full quality

we are looking into having more information about network conditions, it is tricky because that stuff has to be done at the CDN level, and we work with potentially multiple CDNs (akamai, fastly, cloudfront, etc)

we can use the client hint `save-data` (e.g. Chrome "Lite mode"), which we currently use to select the default quality for q_auto (it's `good` by default, but `eco` if the client signals `save-data`)

the importance of progressive depends on a lot of things though. Above the fold, progressive is very important. Below the fold, it probably matters less since the image is likely already there before you have scrolled down. Unless you do lazy-loading, then it becomes important again. Etc etc.

On really slow, modem (or maybe even DSL, that's to be tested) connections progressive really matters. But on 300/20 Mbps (like me) I will happily get AVIF rather than JPEG, because on *that* fast connections progressive encoding... doesn't matter at all?

Without at least LQIP, this can be noticeable at any speed (also not all servers can transfer at client speed and other delays also affect), even with this speed I notice images popping up on some sites

Can we get an official node module with pre-built binaries? **Example:** https://github.com/develar/7zip-bin This would help to have an officially versioned place to point to as a dependency when building tooling to help adoption

Would be useful for server-side, automation scripting, native apps, and tooling

Who would be the person/people that should be in charge of maintaining this (capable of producing the standalone binary for each environment)?

and by maintaining I mean, producing a new binary for each environment when there are version bumps to JXL

If the bumps are rare, then doing it by hand may be quicker, otherwise, may want to dedicate time to setting up the environments in a CI to auto-produce and commit the binary to the repo in a branch named after the environment and the JXL version

For linux distros, there are automated processes for that

<https://newsgroup.xnview.com/viewtopic.php?f=82&t=41595> > Changelog 0.98.2: > 1976: [New] libJPEGXL v0.3 - break compatilility with v0.1

Ah, nice

But still no animation support. ^^

It don't display some images correctly

on the lastest xnviews MP decoding jxl with lossless jpeg encoding did not works :/

Is there encoding param in metadata jxl files? xnview mp seems to not read 16bits jxl files.

Is there a javascript pollyfill for jxl to canvas or jpg?

ooh not that i know of but that would be cool

although it would probably be a hefty download so only worth it for a site with tons of images

It solves the web adoption problem kinda. Being a js pollyfill, hopefully would help cdns and get cached effectively across website loads so only one big download. Probably a good use for a wasm target of the binary

most browsers now isolate caches between different sites

even if it's from the same cdn

so if site a downloads the jxl polyfill it won't be cached for site b

Squoosh.app is a kind of js polyfill (if you count wasm as js)

wasm is better than js so that counts

also being able to use multithreading/simd in wasm isn't universal

there is https://github.com/brion/ogv.js/ which lets safari play ogg/webm

you can compile libjxl to wasm - but it's probably not going to be very fast...

QT is a popular tool for desktop app GUI's, having a `qt-jxl-image-plugin` would enable a lot of image software to support JXL, example: https://github.com/novomesk/qt-avif-image-plugin

There already is one. That's how I've been viewing JXL images natively on Linux.

Look in his repositories. 😛

https://github.com/novomesk/qt-jpegxl-image-plugin/commits/main

abortion

neat <:clippe3love:666059289143541791>

<@!321486891079696385> https://github.com/easymodo/qimgv/pull/293

surely, you are not advising us to abort the project?

no

great, thanks for confirming

> - New JPEG XL (JXL) HDR capture fully compliant with final ISO/IEC 18181 JPEG XL standard https://steamcommunity.com/games/228180/announcements/detail/3053975488717921395

hope hdr stuff becomes more open

https://github.com/cocoon/jxl.Net

Hello, I would like to have a quality picture viewer that can view JPGXL and do things like zoom in and move around without crashes or really high system resource use.

what os

Windows 10.

https://github.com/easymodo/qimgv

I also use Andoird.

that is a nice clean/simple/light image viewer. The readme has a mention for JXL, but I have not tried it yet

it's portable, so you can try it and see

My current image viewer is HoneyView, but it's currently not being actively updated.

<@!720988177648713819> you'd have to request the makers of HoneyView add JXL support.

https://groups.google.com/g/honeyview-win/c/paBUaBSQFxY/m/A6hpk2IyAQAJ

"Honeyview will not be updated except for minimum security patches due to internal reasons. Therefore, please understand that it will be difficult to implement new features in Honeyview for the time being. We apologize for the inconvenience."

<@!139947707975467009> Why does this require Git? I don't know it .

oh, I didn't realize that the qt plugin was not pre-build

The jxl image I made is gray.

Does there exist a full build? Otherwise this program is not usable to me.

<@!720988177648713819> not that I'm aware of, sorry

Okay, I'll just wait until I can actually benefit from jpgxl, then. Thanks for the help.

honestly i don't see the point of lossless jpeg xl. why don't use png and set a a quality?

smaller file sizes vs png without applying loss?

Lossless JXL is based on ideas from FLIF, which outperformed PNG and other lossless formats

yes it's good

but new heuristics is better

you also get the progressive nature of JXL

for adoption xnview and jpeg xl wic don't support lossless jpg

lossless jpg or lossless jxl?

lossless jpg transcode

2 different standards

this is another aspect

lossless jpeg transcode IS a jxl

it's like saying 2,6 mbps in mp4 is garbage

just with extra metadata for recreating a jpeg

because you're used to perfect image

if the image is good enough likely 2,6 mbps are enough

new heuristics automatically choose speed, size

because it has efficient patches in 0.3.3

that there are security problems and q 90 could be better is another aspect

another point is that dev are aiming at more than 50% space saving with a bit of visual sacrifice

https://github.com/saschanaz/jxl-winthumb/releases/tag/v0.1.2

it don't read the lossless jpg transcode

first it did

why?

can you send me one image that doesn't work?

or open an issue yourself, https://github.com/saschanaz/jxl-winthumb/issues

xnview has same problem

jon has answered to that

but jxl winthumb before version used to work

Depends on the resolution. For 240x360 it can be too much, for 3840x2160 it will be garbage.

That's assuming that 240x360 video isn't inherently garbage 😉

240x360 is OK for a talking head in a small box next to a shared screen 😅

True. Videos star approaching good at 480p good settings.

Nah, 64x64 ftw <:PepeOK:805388754545934396>

is it jpeg xl in chrome 90 beta?

I believe they are working on it, but doubt it will be enabled in 90. At best maybe behind a flag if they get to that point? So far, it is not attached to any specific version of Chrome: https://www.chromestatus.com/feature/5188299478007808

Interesting to see how many people are involved in getting libjxl into chrome: https://chromium-review.googlesource.com/c/chromium/src/+/2749318

I think enabled in chrome 91 is the most optimistic scenario. Maybe behind a flag in chrome 90 but I kind of doubt it...

When is chrome 91?

It's 6 weeks between each chrome version: https://chromiumdash.appspot.com/schedule

I am running Version 91.0.4444.0 (Official Build) canary, which is the canary channel (nightly build), not the final Chrome 91 yet; there is no JPEG XL support yet.

It's sad that Mozilla still isn't interested in the slightest

givem time

Yeah, let them take time.

They're currently fixing the AVIF stuff first. <:kekw:808717074305122316>

FF has fewer resources and has fallen behind on features since they let go quite a few last year. I'm sure after Chrome ships (or at least gets close) they will start working on it as well. Safari support is always questionable. Given they have AVIF and HEIF it is possible they could just turn their back on JXL, or at least take over a year before starting work. Good thing is the WebAssembly implementation could be used in the meantime as a polyfill.

Also <https://caniuse.com/avif>

<https://caniuse.com/av1>

AVIF is supported more than AV1 and usually uses dav1d (a fully featured AV1 decoder) and even Safari plans to support AVIF before AV1

Also because mobile is starting to support AVIF but not AV1 yet.

Does mobile chrome support full AV1 "animated avif" in an img tag?

We might be having some revival of silent movies :)

Just tried it and it does, but looks like s**t. Also, neither desktop or Android Chrome understands what `.avifs` is. It has to be renamed to `.avif` to work.

https://github.com/AOMediaCodec/av1-avif/pull/86

None of the avif test sites got the memo.

That's what you get with a spec that can be updated at any time with just a pull request...

Can you say which example file you used on which version of Chrome? On https://caniuse.com/avif they write that no browser supports animated AVIFs.

Chrome 89 on desktop and 81 on Android. Many of the test sites had broken images but here is one that worked for animated: https://github.com/link-u/avif-sample-images Need to download, rename to `.avif` and open locally but works.

Hm... I tried a few others that don't work. I wonder why those do...

Maybe it works as long as it doesn't claim to be an animation, or something

<@!172952901075992586> Hui, looks like it worked 😃 https://gore.cf/b.avif

Though AVIF is 150 KiB, AV1 was around 100 and WebP or JXL were only 40!

Imageglass doesn't work.

you need qjpegxl file

maybe

i don't remember how i used it

Also is there an Android viewer for JXL?

I got Imageglass to work. In some aspects, it's better than Honeyview.

However, it can't view CBRs efficiently.

I don't think so

what it means

why no development

there is development afaik, but it's not reflected on this page for some reason. but hey, at least they documented motivation

https://www.chromestatus.com/feature/5188299478007808

and the thing about several google teams and facebook looking into it seems pretty promissing

you can follow development here: https://chromium-review.googlesource.com/c/chromium/src/+/2749318/3

Requesting again that there be an official repo and npm module that contains the built binaries for all major OS's. This would help with the creation of tooling and libraries for adoption. The sooner the better, so libraries can start being built to wrap the current CLI options.

For linux distros there already are packages for some distros, I think, no?

Yeah. IIRC OpenManDriva and Ubuntu 21.04 are thinking of including JXL stuff in their next releases.

https://aur.archlinux.org/packages/libjpeg-xl-git/

the AUR has everything

wait, where do you know this from?

I mean a stand-alone CLI executable

Well, I asked about it on the Openmandriva IRC a while back. I suggested it to them since it already works very well right now on my Openmandriva 4.2 machine. They are thinking of including the plugin and the JXL packages in the OM 4.3 Cooker branch so it gets native support without having to compile manually.

For Ubuntu, I need to go look at where I saw the JXL stuff.

for encoding/decoding/transcoding from one file to another

It's not in hirsute yet, at least.

I consider cjxl/djxl only something for experimenting/testing, in the long run they should become like cjpeg/djpeg: something nearly nobody uses.

(instead everyone uses libjxl via applications like imagemagick, gimp, etc)

Sadly, it looks like my info about Ubuntu 21.04 thinking of including JPEG-XL is innacurate. Sorry for getting your hopes up.

I think it can make sense to use cjxl / avifenc / etc. directly when you want control over certain things

Ah I wasn't especially hoping, I was just wondering how it would happen since we never asked Debian to include a package :P

I do not expect image magick or gimp to give 100% acccess to all possible CLI features of JXL encoding/decoding/transcoding. An official CLI is needed for tooling

Sure, for expert users. But for most end-users, decode should Just Work, and encode should be just a simple 'Save as jxl' dialog box with a quality slider and maybe a few advanced options.

And eventually cjxl/djxl should themselves use the libjxl api, and be very simple programs with not much logic of their own (except knowing about input/output formats and setting sensible defaults based on that), with all their settings/options also accessible through the api.

Some thoughts on jxl adoption:

We might attract new general users by multilingual articles on Wikipedia.

There are already English, Czech and Japanese articles.

I contribute to the first two and can also translate to Esperanto.

I guess that people here speak many different languages (not only programming languages :)) so if you feel like it, you can start an article in your language.

And if someone makes it to https://en.wikipedia.org/wiki/WP:GA or even https://en.wikipedia.org/wiki/WP:FA (to be able to appear on the main page) in their language, that could help even much more.

Maybe we can polish the English one a bit more

I mean pollish

I mean polish

or polish the Polish one

Both the shoe polishing and the Polish country are with one L

It's not like the Finnish at the finish line

It's only when you do something vaguely similar to a poll that you get a pollish.

So you have polish and Polish that are pronounced differently. Now there needs to be a word that sounds like one of thek, but is written differently.

I think desert-dessert-desert still wins.

https://blog.cloudflare.com/introducing-polish-automatic-image-optimizati/

(the desert is a dry place, the dessert is what you eat after a meal, and to desert is what soldiers sometimes do... sounds like the meal, but is written like the dry place)

Kornel who is the image optimization guy at cloudflare happens to be Polish, so I wonder if that's an intended pun 🙂

Yep

JXL's ANS is Polish after all so the debate here is quite relevant although it doesn't seem like it at first sight. 🙂

you should translate it in Italian

Who? And what's your mother tongue? Which language can you do? 🙂

i'm italian but i'm alone

isolated so i don't know if i'm correct to translate well

also i don't have wikipedia account

Wikipedia is unique: You can contribute even without an account. And accounts are free, of course.

no i don't want the ip to get published

especially that i'm on windows 7

for example

Formato esente da diritti d'autore con un'implementazione di riferimento open source.

google translate translate all

Sure. Nobody has to contribute. It's all voluntary.

copyright is diritti d'autore

font becomes caratteri

but is this text comprensible by italians

for examplev

Compressione di alta qualità di immagini sintetiche, come caratteri bitmap e gradienti;

or compresssione di immagini sintetiche in alta qualità, come caratteri bitmap e gradienti;

i'm not that expert of my native language

No need to discuss details of languages here. Let's just concentrate on the topic: jxl.

av1 if i remember when last visited was translated

no

royalty-free

also you have to insert the link of royalt free page

motore del browser is incorrect

i heard motore di navigazione

but i don't know

what language you did?

or did you add some things apart from the standardization who was there

petr if you want you can copy the text

and make you the italian version

I can help with the italian translation

JPEG XL è un formato di file di grafica raster che supporta la compressione con e senza perdita di dati. È progettato per superare i formati raster esistenti e quindi diventare il loro sostituto universale.

Nome storia caratteristiche dettagli tecnici

mhhh... not sure I like that translation 😄 I could help, but I'm generally better at writing C++ than at writing Italian xD

Software supporto esistente supporto proposto

Hmm, thanks, but it will be better if it is done by someone who actually speaks Italian.

web browser you change to browser web

me, Fabian and Crixis are all Italians from what I understand

motore di navigazione di Safari e altri

Writing a wiki is not just about the text itself. There are also templates, references, categories etc. – nothing for someone who doesn't speak the target language.

supporto a JXL su Windows via WIC es. per visualizzare il formato su visualizzazione di foto windows, Esplora Risorse ecc.

ImageMagick toolkit per l'elaborazione grafica raster

convertitori basati sull' implementazione reference reference e compilati per Windows (la pagina contiene anche altri programmi)

the technical details you should cop y paste from translate and you add links and formattation

JPEG XL si basa su idee dal formato Pik di Google e dal formato FUIF di Cloudinary. Il formato ha una varietà di modalità di codifica. Sul lato legacy, ha una modalità che transcodifica JPEG legacy in un modo più compatto per l'archiviazione. Sul lato più moderno, ha una modalità lossy basata su VarDCT (con modellazione separata di forme e ripetizione di "patch" come testo) e una modalità quasi senza perdita / reattiva che utilizza una trasformazione simile a Haar. Il DCT utilizza uno spazio colore XYB derivato da LMS. [9] La previsione viene eseguita utilizzando un decorrelatore pixel per pixel senza informazioni secondarie, incluso un insieme di predittori ponderato e auto-correttivo parametrizzato. La modellazione del contesto include modelli statici specializzati e potenti modelli meta-adattivi che tengono conto dell'errore locale, con una struttura ad albero segnalata e una selezione di predittori per contesto. La codifica entropica è abilitata per LZ77 e può utilizzare sia i sistemi numerici asimmetrici che la codifica Huffman (per encoder a bassa complessità o per ridurre il sovraccarico di flussi brevi). L'impostazione predefinita è un'impostazione visivamente quasi priva di perdite che fornisce comunque una buona compressione. [10] Le immagini animate (multi-frame) non eseguono la previsione inter-frame, a differenza dei formati basati su codec video

i see only predittori that maybe is ponderati e auto-correttivi parametrizzati

remember it

https://discord.com/channels/794206087879852103/803574970180829194/821683679301599252

I'm writing on wikipedia

good

do not add anything

apart from what is written in english and copy the reference without changing

italians do not edit reference

if there are biblical

Ahoj <@792428046497611796>! I can try making a Polish version of the Wikipedia article 😃

instead of making translation would be instead jpeg xl person make an offiicial article and they translate it?

Articles from official people aren't very welcome on Wikipedia. See here (Italian): https://it.wikipedia.org/wiki/Wikipedia:Niente_ricerche_originali

another reason why I shouldn't write it 😛

No problem. But if you see there some mistakes, confusing statements etc. at any time later, feel free to fix them. 🙂

I did a quick run through the English article to polish it a bit, I hope they're not going to revert my changes because it's me who did that

<https://en.wikipedia.org/wiki/JPEG_XL> > qt-jpegxl-image-plugin – JXL support for Qt on Linux and Windows (so I don't think it needs to be specified only on Linux) ImageGlass Moon also supports JXL <https://imageglass.org/moon> (but something was broken in the last build)

The software don't work

no decoders work for jpeg xl in windows 7

it breaks all

for windows 10 someone should test that uses windows

online media convertor

is converter not not convertor

also i don't understand why toolset

and not toolkit

what it change

but i like the version of j.sn

You mean ImageGlass? Just tested on W10 and works with non-lossless-transcoded jxls. It works with non-animated AVIF (though the previews work with animated AVIFs?)

The QT plugin works with nomacs. Have not seen a jxl that didn't work yet.

try opening that image

with nomacs

4000x3000

see if your computer crashes

fixed

That image crashes nomacs. ImageGlass and XnView can not open (appears as black bar in XnView) which is what happens with lossless transcodes, so likely lossless transcode.

not

Squoosh also not able to open, so maybe something corrupt in the file?

for %i in (C:\Users\User\Documents\LD\*.jpg) do cjxl "%i" "%i.jxl" -q 91.4 -s 9 -m -I 9.3 --num_threads=2

i used a iterations higher than older builds

As long as several basic rules (e.g. neutral point of view, encyclopedic style) are followed, all edits are welcome. So yeah, well done, Jon. 👍

djxl was not able to lossless transcode but was able to re-encode back to jpg.

is a jxl not a jpg

is already encoded with cjxl

it doesn't require -j

because it changed

djxl reverses jxl back to jpg

with some loss

is in reality a png for now that get's encoded

I was just using it to see if it was corrupt or not. The decoder was able to open and convert so problem is likely with the image viewers.

or maybe diretly in jpg

but still to pixels before

older version didn't support that iterations it had limit on iterations

other than having perfect modular q correlated to the output quality you specify

Some image viewers may not know a jxl can start with other bytes than the 0xFF0A of a naked jxl codestream

Try a jxl which is not a lossless jpg but a png with xmp or exif, the current cjxl will then also create a container to put the metadata in it

also why you can have higher iterations in 0.3.4

in this way the image have truer quality to original at 85 kb

If that also doesn't work, then the application isn't aware of the container thing

but with palette i corrupted the file

lossy palette

less moire better defaults is good

Squoosh fixed that issue and I submitted the bug to XnView (no new version yet). nomacs was able to open those fine but the file <@!416586441058025472> sent causes it to crash.

https://discord.com/channels/794206087879852103/803574970180829194/821712621161938994

but it has higher iterations that the supported of older encoders

-I with a value above 1 should do just the same thing as -I 1

the scale is 0 to 1 for that option

interesting, it does indeed cause trouble

and I bet it's because of orientation

maybe this is image toggleton send

i can try with -I 1

but i don't want

the issue is with nomacs, xnview is different black boxes

yeah, it decodes OK, but then when writing the output image, it has to orientate the image (it is stored as a landscape image which came from a jpg original with exif orientation to rotate it 90 degrees), something is going wrong and it segfaults

same with -I 1 and the same command i used

?

I hadn't tested orientation by 90 degrees, only 180 degrees. Maybe the code for rotating 90 degrees is broken

orientation has been in the bitstream for a long time, but it was never actually used until now, so it's likely that there are bugs

One djxl bug in particular is that if you decode to (lossy) jpg, it ignores the orientation and gives you the landscape image

Could someone open a gitlab issue about it? Segfault in djxl for images with 90-degree orientation...

Mine didn't segfault, just said it couldn't do lossless transcode then successfully lossy-transcoded it.

yes, it does that if the output is .jpg

but it's a landscape jpg, not a portrait one, right?

Nope, portrait. Looks same as what was posted.

Here is the file djxl made.

Wow, the Italian article on Wikipedia looks good!

it is unfinished sorry

WP is a living project – never finished. 🙂 Additions can be made at any time.

interesting... what if you decode to png or ppm?

It gets to "Decoded to pixels" then segfaults.

ah probably i'm using sjpeg and you're using libjpeg — the exif orientation is not preserved in sjpeg

(i mean when djxl is writing a jpg with sjpeg)

i'm not sure what we should do with it though - probably we should preserve the exif exactly when doing jpeg reconstruction, but when writing a new jpeg from pixels, we should orient the image and encode the oriented one, and then it also works if the exif was stripped. But then if the exif was not stripped, we should restore the exif, but overwrite the orientation field in it to do a no-op, because otherwise viewers will orient the image _again_

https://tenor.com/view/three-finger-salute-good-luck-jennifer-lawrence-katniss-everdeen-hunger-games-gif-14699764

first figure out why it is segfaulting when orienting

ok, not swapping width and height when doing 90/270 degree rotations is not a good idea

ok fixed it, so don't bother opening a gitlab issue, at the next sync it should be ok

<@!768090355546587137> please take a look at my merge request with the fix, if you have time 🙂

Is intrinsic_size supposed to be after rotation or before? The spec is unclear.

good point

what would make most sense?

we have nothing that actually does something with intrinsic sizes yet afaik, so we better choose and make it clear in the spec

I would guess that scaling would normally be performed after rotation, so it would probably make the most sense for intrinsic_size to be the final size after any rotation (with the regular size being before rotation). But mostly it should be clear so that clients know if they need to swap width and height.

yes, intuitively it makes more sense to me to have them be the final size after rotation, though there's also some beauty in having it similar to the pixel dimensions (so also before rotation)

in implementations you might want to scale before rotation if it's a downscale and scale after rotation if it's an upscale (or do scaling while rotating even 😉 )

I think that in a web browser, the css or html may specify a width and height that would override the intrinsic size in the image file, but if it specifies a rotation then it is supposed to be on top of any rotation from the image file, so at least conceptually the scaling is the last step.

I don't know the internals of any web rendering engines, but if you had the same image used multiple times, I would think that the cached image would at least conceptually already have the rotation applied, but not the scaling, since each instance of the image may have its own width and height.

yes, conceptually scaling is the last thing you do

Aaaaand it's ready! https://pl.wikipedia.org/wiki/JPEG_XL

<@!792428046497611796> seems like you understand a bit of Polish, so you can check if you're curious. Because it seems like ~~I'm the only one from Poland~~ **(EDIT: now I'm not)** on this Discord (~~and Kornel isn't there...~~ **EDIT: ok, now he is**)

And Jarek Duda isn't there, too... or is he?

Świetnie! 👏🏻 I've just added an inter-wiki link.

Jest elegancko;)

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

sundfvovfo

This is actually an image that I took.

<@!792428046497611796> the <:JXL:805850130203934781> logo is now CC0-licensed ('public domain') by its creator

Unfortunately, such statement isn't enough to meet the rules of Wikimedia Commons. Please see my messages in another thread.

scope petr which language i edited

Sorry, what do you mean?

ok i'll tell you

italians and english

english i corrected converters and toolkit

it was convertors and tool set

maybe i over corrected

italian the first three section are by crixis

he said he made him, correct <@!424295816929345538> ?

but it's predizione o previsione

Le immagini animate (multi-frame) non eseguono la previsione inter-frame, a differenza dei formati basati su codec video.

this part seems strange to me

that's actually false btw, we don't have an encoder that does it, but there *is* some rudimentary inter-frame prediction

There are three rudimentary kinds of inter-frame in jxl: - frames can only update part of the canvas, like in gif/apng/awebp - frames have other blend modes than just replace (e.g. kAdd might be useful) - patches can be used as rudimentary motion vectors: you can take part of a previous frame (one of 4 'remembered' previous frames) and copy it to a different region of the current frame (using any blend mode). For example you could make an animation that consists of sprites that move around, with backgrounds that move in parallax, and encode the sprites and background layers only once.

The third one is probably more than just 'rudimentary' 😅

so it should be able to transcode optimized gifs with "not worse" ratio, if encoder tried, i guess

Yes, it's just a bit tricky, but our entropy coding should beat LZW, the only disadvantage we have is that we have no global palette that can be used in multiple frames

So every frame can be used as a patch source? Or do you have to designate that one frame as patch source for every other frame?

You can use any frame, but you have to declare it in the frame header that the decoder should 'remember' this frame because it will be referenced in future frames

There are 4 slots for reference frames

So in the frame header you say something like 'after decoding this frame, make it reference frame 3'

Patches then say from which reference frame they are taking pixels

You can have a 'reference-only' frame which is not shown but can be used in subsequent frames

French version: https://gist.github.com/jido/3ba153a435a9f55da2254448f820c3d3

I should remove the part about "no inter-frame prediction" then

It looks good. But why is it on Github and not on Wikipedia? 😮

<@!416586441058025472> or someone with Wikipedia edit privileges will put it up

Everyone has Wikipedia edit privileges. Even users that aren't logged in.

<@768090355546587137> <@795684063032901642> How is the chromium integration going? Is it still possible to get in Chrome 90 behind a flag? Or what's the current status and goal?

I'm a D&D master and I paid on kickstarted for a new dungeon creator, I send this on their discord

I'm sorry for not apologizing even here for my bad English XD

I'm nowhere near being able to talk without sounding incomprehensible in any non-English languages, so I can't complain about others not speaking English well.

All right, done. For some reason there is no link to it on the English page though.

i found it

You are right, don't know what I was looking 😆

neat translation

I couldn't figure out how to add the logo

https://gitlab.com/wg1/jpeg-xl/-/raw/master/doc/jxl.svg

We're waiting for the author of the logo to upload it to Wikimedia Commons. This seems the best option due to licensing reasons.

The two pending commits are now here: https://chromium-review.googlesource.com/c/chromium/src/+/2745343 and https://chromium-review.googlesource.com/c/chromium/src/+/2749318. The second one has already all approval from owners, but the first one is still pending, (and the second one depends on the first one of course). It depends on how fast the eng review goes, Chrome 90 looks impossible currently, targeting Chrome 91 now. The plan is to have it behind a build flag, which is turned on by default on Desktop an turned off by default on Android and iOS. Then there will be a feature flag, which will be turned off by default. This can be controlled via chrome://flags (you can then find it by searching for the string "jxl" or "jpeg xl') or by passing the flag `--enable-features=JXL` when starting chrome from the command line. The reason the build flag is not turned on by default on mobile is more about binary size restrictions than about technicalities. Last week I compiled Chrome on Android and confirmed that it works.

I made https://mo271.github.io/jxl/ : it serves either jpg.jpg or jxl.jxl and the jpg contains some text that reads "Your browser does not appear to support JPEG XL" while the jxl contains some text that reads "Your browser is ready for JPEG XL" and Jon's JXL logo.

Those are some screenshots from running Chrome on Android

👍

I think we're all eager to try it out. Who is doing the review for the first commit?

Nope, Chrome doesn't work.

Are you trying a Chrome that was compiled with jxl support? Even Chrome 91 is unlikely to have jxl support on Android by default.

I don't know how to compile. I used Canary, since isn't it the latest features?

I also have Canary, but on Windows and it also doesn't have any JPEG XL flag at all.

I have my test at the bottom of my main page https://jeremylee.sh/

By the way, I downloaded the PNG file and optimized it with OptiPNG -> Pingo -> ECT. I preserved all metadata chunks. Could you replace that file on you website with this optimized version, please?

how much did you save ?

I only use ect -9

55.5 KB -> 42.5 KB

Very nice

Well I learned about pingo

After stripping down alpha with `pngtopam` and quick inspection in GIMP it seems like Pingo is doing something in 100% invisible pixels.

And I use `ect -9 --strict --allfilters-b`

where do I get pingo ? I only found this sketchy website https://www.css-ig.net/pingo

I got it from there

GUI should be enough

Set it up this way for best compression:

I'm not too big on guis

Me too, but after setting up *this* one you really only have to click "optimize" and then compress with ECT in command line

what about both from one script in command line

I'd show you but

Ah, ok. Lemme check.

currently I use this script when I need to `Get-ChildItem * -Include "*.jpg","*.jpeg","*.png","*.zip","*.gzip" -Recurse | % -ThrottleLimit 3 -Parallel { echo $_.FullName; ect_avx2_pgo.exe -9 $_; }`

yeah pingo seems to be lossy

Not if like invisible pixel data matters on the Web anyway

Ok, try this: `Get-ChildItem * -Include "*.jpg","*.jpeg","*.png","*.zip","*.gzip" -Recurse | % -ThrottleLimit 3 -Parallel { echo $_.FullName; pingo.exe -s9 -nostrip -nodate $_; ect_avx2_pgo.exe -9 --strict --allfilters-b -keep $_; }`

Use original `tosin.png` from your website and let me know if you managed to squeeze it to 42.5 KB (CRC32 of my file: 00C4B887)

Why doesn't it work in my PowerShell?

```ForEach-Object : Parameter set cannot be resolved using the specified named parameters. At line:1 char:79 + ... -Recurse | % -ThrottleLimit 3 -Parallel { echo $_.FullName; ..\pingo ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : MetadataError: (:) [ForEach-Object], ParameterBindingException + FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.PowerShell.Commands.ForEachObjectCommand```

I put `tosin.png` into a separate folder in Downloads and invoked that command from there in order not to mess with other files (of course I adjusted .exe paths accordingly)

seems to work with a custom build of chrome (hopefully coming soon as canary)

omg can't wait for this on firefox

see you in 6 months I guess

So this will be in Desktop Chrome Canary as soon as those pending commits are reviewed / have landed, but in mobile chrome canary it will likely not happen before Chrome 92, right?

yes but i'm blocked by my ISP in chrome

i can't use web in chrome

how i will transmit images?

Your ISP blocks the usage of chrome ?

Maybe is because i used firefox

that's kinda based

maybe the pc has virus

is in blacklist

my technician refused to fix it

now how i will use jpeg xl?

poke firefox devs to implement jxl support 🙂

https://tenor.com/view/futurama-what-you-want-poke-gif-12060067

I don't know of any ISP in Italy that could/would do that, I suspect it's a different problem 😛

windows 7 user

only firefox works

when i use chrome i always get CAPTCHA or network not loading please you could reload or launch firewall

but when i visit only one site not

Reinstall windows then

even with a new installation isn't different

it doesn't load anything and it asks for CAPTCHA

all people with windows 7 have this problem with chrome

okay. I too use firefox only so idk. ha ha

i use firefox

fyi Windows 7 is not supported anymore

right

but in windows 10 can you visit how many sites you want or it asks for CATPCHA

supported by Microsoft, I mean

without installing any vpn or configuring opera vpn

i'm a bit offtopic i'll stop here

you could update to 10, I don't think there's a reason not to - especially since there are ebay sellers that give you licenses for like 4€

i read about opengl

not supported by older computers

just waiting for firefox to add jpeg xl support in may june

or after

..JXL ADOPTION

where is the page of firefox, is the one on announcements? i don't see the poke button

bruh

ok i will wait them

my computer will become obsolete by then

so i change it in the time

Can also make a dual boot with ubuntu or whatever, compile your own chromium with the jxl patches, and have jxl support right now 😅

the thing is strange because the technician in the near country had fiber and connected and could watch av1 videos

and me i can't do anything

<@!416586441058025472> I think probably your chrome certificate(about https and TLS) is outdated? Blink Engine(chrome) force use https protocol.

how i can fix it?

Try update chrome and make sure your computer time is correct.

i did

should i go to the network windows settings?

is there a need to configure?

why chrome asks for CAPTCHA and firefox not?

I think we need transfer this discuss to off topic 🙂

yes, and it is conceivable that will can do another commit turning on the build flag on mobile before Chrome 92 comes out, but who knows

Does Pingo&ECT have multi-threading?

Oh, by the way: is there any way to disable palettization (for testing purposes) in either of them, as if palettes didn't exist in PNG?

No. However, ECT can do file threading.

So, if you have lots of files, you can just do threading over these files.

This will be very slow optimization (especially for large images) with very little improvement, more efficient in terms of speed/compression would be something like this: `pingo -sa -nocompression` + (-strip or -nostrip, etc) then `ect -9 --reuse` or `ect -30060 --reuse` + options Although I don't know why to use `-nostrip` and `-keep` for web images (they will be visually lossless), invisible alpha might be needed for example to use some tricks for textures in games, etc. Also pingo reduces all images to 8 bits per channel

> I don't know why to use `-nostrip` and `-keep` for web images (they will be visually lossless) For web images? Sure, lack of `-nostrip` makes sense. But `-nodate` and `-keep` are for preventing mess in File Explorer. I've got shitload of files in my Downloads folder and I don't want my optimized files to suddenly pop at the top of the file list (I sort by Last Changed).

Alright.

Yes, saving the date makes sense, although these are modified files and it all depends on the use cases (e.g. sometimes it is useful to know which files have already been optimized and which are old)

> it all depends on the use cases Exactly. If you tell me **your** use case, I'll probably prepare a better command 😉

And yes, this *is* slow. But I'm trying to break some records 😄 Don't worry about metadata, I strip some of it manually with TweakPNG beforehand.

Yes, I just mean that these commands can be used blindly by other people And get a very large increase in optimization time (for about 0.02% improvement) without stripping or alpha optimization (which sometimes significantly reduces the size and is not needed for example for web and ordinary images that are used only for viewing)

Good point. I was mainly focusing on record-breaking and not messing up my filesystem. **For everyone that wants to use any command from this server:** read help files and learn what those switches actually do, and tweak some of them if they don't fit your usage.

I have real examples of people who didn't use ECT because it's "slow" (because they used some options found on some site) and switched to Oxipng because it's fast and efficient (just by feeling, not making any comparison), but the point is that ECT and Pingo are faster than Oxipng in parallel image optimization and are much more efficient at all their speeds