JPEG XL

xnview mp don't support jxl create by imagemagick but it have an build in jxl decoder and encoder :/

it probably uses an old version of jxl before the bitstream was frozen then

yes, i will report it in the forum. Who know graphic windows/android programs reading jxl?

darktable don't support it now.

not much yet, but I guess we should get the libjxl api stable before opening issues in all the relevant software

or we could open the issues already so they can start working on integration in a branch

best to wait for stable libjxl api though before compiling with jxl support by default

xnview mp use libJPEGXL.dll if i replace it with a more recent binary it will works. But i don't know who built it and where i can find it.

When you speak about api, you speak about stability of parameters of the encoder? (i'm not a developer)

it's the way the library gets called: what functions you can call, in what form you get the result, etc

if we change that, stuff breaks

ImageGlass (windows) support jxl: https://imageglass.org/moon

Nomacs (multiplateform) support jxl with an extension: https://www.reddit.com/r/jpegxl/comments/l4nwb2/how_to_view_jpeg_xl_images_in_nomacs_for_windows/

https://caniuse.com/?search=jxl

we've asked them to add it

https://github.com/Fyrd/caniuse/issues/5041

https://github.com/rouault/gdal/tree/jxl is a work in progress to encapsulate jxl compressed tiles (usually 512x512) inside a TIF container

I'm not sure if this is the place to ask, but https://github.com/rouault/gdal/commit/8aac52b8bc8a3c1a3d550822da4ec28a26eed760 had to be added as a workaround as JxlDecoderReleaseInput consistently returned a non zero amount of remaining bytes after JXL_DEC_FULL_IMAGE was returned.

how could I reproduce this to try to investigate and fix?

<@!768090355546587137> if you are willing to compile a gdal tree from that branch, reproducing should be straightforward

does this happen on all images?

yes

well, it happens on all 16bit lossless ones. I haven't tried other configurations

it can happen that release returns non-0 though, if bytes past the jxl file itself are given

it should indicate that it's done with the JXL_DEC_SUCCESS status

and any non-zero value that release returns then indicates how many bytes of the input have been consumed as jxl bytes, and which ones are the rest of the non-jxl contents around it

JXL_DEC_FULL_IMAGE is not necessarily the last event returned, there could be more animation frames with more JXL_DEC_FULL_IMAGE in them. JXL_DEC_SUCCESS is the last event

let me check, but that should not be the case. the input bytes should be the exact same bytes that were output by the jxl encoder, i.e. with no trailing bytes

in this case, there is a single frame

> JxlDecoderReleaseInput consistently returned a non zero amount of remaining bytes after JXL_DEC_FULL_IMAGE was returned

If you try one more call to processinput, and it returns JXL_DEC_SUCCESS, does release still return a non-0 value then?

give me a few minutes to try that out

so the next call returns JXL_DEC_SUCCESS

the remaining bytes returned by JxlDecoderReleaseInput is the exact size of the input buffer

I just created a <#804324493420920833> channel, maybe can continue discussion there?

also feel free to put a link to your project in <#803663417881395200>, it is nice to keep track of the projects that are working on jxl support / integration 🙂

tbonfort, thanks! that may be a bug in that case. If everything else works correctly, you could ignore the return value from releaseinput once it returned JXL_DEC_SUCCESS for now

<@456226577798135808>

do you know if the images themselves are a pure JXL codestream, or have the JXL box format container around them?

I have no idea. They where created by the encoder code here: https://github.com/rouault/gdal/blob/8aac52b8bc8a3c1a3d550822da4ec28a26eed760/gdal/frmts/gtiff/tif_jxl.c#L466

(btw, lets move to <#804324493420920833> to avoid polluting <#803574970180829194>)

anyone want to try to get jxl working in libvips? https://github.com/libvips/libvips

``` curl -sD - -H "Accept: image/jxl" https://res.cloudinary.com/jon/f_auto/sample.jpg ```

The last windows binary 0.3 of jpegxl encoder/decoder is here: https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=67989&viewfull=1#post67989

https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 Someone is a bit impatient it seems. 😛

People need to not do that or they will just lock the comments.

so, besides browsers, what should get jxl support?

Think for most people browsers, default photo viewer apps on desktop and mobile and maybe camera apps would be enough. Having the option to take photos in jxl format would be nice, but not sure if that would be possible yet and if bigger companies want to add support for it

what viewer apps are people using where we can open issue to ask to add jxl support?

Editing software support would also be very nice. Can't really think of anything else that would benefit from it

Default Microsoft ``Photos`` app and mobile apps like ``Google Photos`` and other widely used apps (no idea what the most commonly used mobile gallery apps are)

But not sure if that's achievable for the near future

For Windows, as I said before it is also important support through WIC (Windows Imaging Component), not necessarily from Microsoft itself, it can be a third-party implementation as it was for FLIF <https://github.com/peirick/FlifWICCodec>

XnView (some applications also use the XnView SDK for decoding) <https://newsgroup.xnview.com/viewtopic.php?t=40709> IrfanView <https://irfanview-forum.de/showthread.php?t=12783>

Image and file hosts (Imgur, Google Drive/Photos) are very important imo. Though my hopes for that are quite low. If you currently upload a Google WebP file to Google Photos, Google will display a PNG, JPEG or GIF depending on what the source is.

Makes me wonder why Google even works on image formats like WebP, JXL, ... <:ugly:805106754668068868>

But what happens if you try to download the original photo from Google's servers? I mean not for viewing, but for storage?

This gives me the WebP back. But kind of useless using Photos for that if it can't display the actual file. So I currently just stick with Google Drive.

Oh, and by the way: I'm working on JPEG XL support in Google Photos, just gonna type in some encouraging description and send feedback to them 🙂

Would be nice if it gets added

If common apps support it then I could start using jpeg xl I guess since now the workarounds/having to download things isn't really worth it to me

I was planning to upload all of my photos before June 1st (you know, the free tier apocalypse), but now I'm waiting with all of my photo uploads before they add JPEG XL support. I hope that they add it before June 1st, because otherwise I'm screwed.

screenshot tools could be interesting

I was the one that mentioned it on their subreddit: https://www.reddit.com/r/googlephotos/comments/kkhnt9/jpeg_xls_bitstream_is_frozen_google_photos_can/

``Furaffinity and othes can join in`` <:kekw:758892021191934033>

I've been doing some tests: original JPG vs Guetzli JPG vs size-matched JXL (`--target-size` was *incredibly* helpful) and JXL's been winning

I hope that Google Photos introduce `-s 9` JXL encoding in their free tier instead of Guetzli JPG (if you choose so in settings)

They also worked on AVIF, and pushed it way more in the beginning as browsers started to support it. The fervor has died down, but we have yet to see what Google plans to do as far as pushing AVIF over other formats. I personally don't like the excessive amount of smoothing it does. It may work well for videos (though, probably not for a while yet). Hardware vendors are not keen on adding AV1 encoding support yet likely due to the slow encoding speed. Some CDNs have given the "'I'll pass for now" on AVIF due to it's low performance as well. I feel if browsers and other image handling software starts implimenting JPEG XL soon, and most CDNs start adding it as an encoding option, we could see JPEG XL support start surpassing AVIF this year. AVIF may have jumped out of the gate first, but keeping a steady pace (and balanced performance) is what wins the race.

JXL is made by Google Research (and also Cloudinary), which is not the same organization as Google Chrome.

AVIF and WebP2 involve people in or closer to Google Chrome.

IrfanView definitely

but it's one of these one man projects, so it's kind of like asking for a new feature in foobar2000 or calibre

may happen, may not

foobar2000 and calibre have plugin systems, though

does IrfanView?

Yeah, but I'm not sure if it includes format support too

I think that's baked in

e.g. foo_input_dvda

https://www.irfanview.com/plugins.htm

cursory check and yeah, it's possible to support a format via a plugin

If anyone feels like preparing a pull request for a viewer, that would be great (and I am sure you can get help here if you have api questions on the jxl side)

Just opening an issue is also nice of course, and less work 😄

So, I'm going to do a follow-up article on modern image encoders, and I need some more datasets for testing: https://chipsandcheese.com/2021/01/30/modern-data-compression-in-2021-part-1-a-simple-overview-on-the-art-of-image-encoding/ I already have the CLIC datasets for real life pictures, but I need some more varied datasets. I would also like to have higher resolution datasets to test multi-threaded performance. Any sources you can people can link me to?

The images <@111445179587624960> used in his lossless comparison are varied (a bit focused on non-photo though)

Oh yeah, I had completely forgotten about that.

Yes, because I wanted to minimize the "lab test sets" and keep the proportions closer to actual use (however, it also has different photo sets).

Also, I originally wanted to add similar categories, but the difficulty is that I couldn't just post most of them (without permission) and they would also require manual selection and searching from various places or google results.

In the reddit image sets, I simply took various popular subreddits with lots of lossless images and filtered out only the obvious ex-Jpeg or broken images (without any of my preferences)

Support in SumatraPDF would be nice if it could happen.

Hey, when they said they were making a codec for all usage, they were *making a codec for all uses*

🍆

For ubuntu there is a viewer now?

KDE make me sad

You no like KDE?

😢

No idea, has someone got it to work with eog maybe?

yep, i feel it so clunky and i'm all on dinamic workspace

I have tryed whitout success

i will try wine nomacs XD

no, too sad, i will only install a qt viewer

I use qview for general use

gwenview is ok I guess, it feels a little too cluttered by default

yep, I will try qview

This is how my gwenview looks like

disabling/hiding is just an setting option

how I like it:

So many settings on kde, i have tryed but no dynamic workspace and bad Google drive and proprietary driver management don't make me invest time

Easy and integrable, I like

I'm still a noob with KDE customIzation

for example I still don't know why I can't use transparency as a window background

the jpeg-xl repo has a gdk-pixbuf plugin, that should make it work for both thumbnails and say eog

I failed on compile it

how did it fail?

I made quite a mess, i will do another try in the future

Ha Ha. KDE best.

What about a javascript implementation of the decoder? I wonder possible speed and memory use

squoosh.app basically does that

counting wasm as a form of js here

Guys, I know it's not much but I'm offering 20$ for an IrfanView JpegXL plugin. Others can chip in!

ooo do we need to start a Bounty Hunting channel?

I think it would be a good ideea

ok, bounties can be announced in <#806522208692207617> now

for those who don't know, <@!228116142185512960> and <@!710762823986446367> are the main devs of https://squoosh.app/

We need to update to v0.3! Haven’t done that yet I think

I can help with that 🙂

😄 That would be appreciated

Wasm is an hack

A good hack

I was not thinking about squoosh cli

I wonder about the possibility of an flutter viewer

Are you maybe thinking about asm.js? Wasm is pretty good

I have undervalued wasm portability

I'll do that after 0.3.1 is out (should be later today)

On squoosh effort is -s?

Yeah, wasm is definitely not a hack 😄

<@!424295816929345538> do you mean the Squoosh CLI? Then no

I’d recommend using squoosh.app to configure the encoder and then click the “copy CLI command” button

the CLi is fairly undocumented. We wanna fix that soon

On squoosh app

I think quality is -q, true?

`cjxl -s N` is squoosh effort `N-3`, I think

we should probably rename the cjxl option to "effort" too, it makes more sense

--effort <number> or --speed <animal>

What make no sense whatsoever is VP9/AV1 `cpu-used`

and that for VP9 it can go `-16 - +16`

Lol on my firefox crash on effort 5

`cpu-used` is higher-is-faster, right?

Yup

that seems a bit backwards

--speed <animal> is cool, but not very practical, there is a need to remember the names of animals and it may limit the difference in speed, since it should roughly correspond to the speed of animals

Not a problem If there is a --effort number

Yep, --effort <number> is more logical and easy to use (including scripts, GUIs, etc.), --speed <number> (which is now) it is not always clear which value is faster/more efficient

just like we have `--quality` and `--distance` which are just two different ways/scales to set the same thing (quality is higher = better, distance is lower = better), we could have `--effort` and `--speed` which are two different ways to set the same thing (effort is higher = slower, speed is higher = faster). Could still allow numbers for speed, and also come up with some metaphorical strings for effort, e.g. `-e herculean` etc 🙂

rav1e have `speed` and svt-av1 have `preset`

is rav1e's `speed` higher = faster?

yep, it make sense)

Just make a not configurable encoder that automatically convert all image of the pc and delete olds, immediate jxl adoption

haha adoption by force

systemd-cjxl

let me know if I can help to get that working...

I will try tomorrow

now i don't have my pc

anytime..

Waiting on this page to inlcude JXL 🙂 https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img

bit pointless if no browsers support it

> The older formats like PNG, JPEG, GIF have poor performance compared to newer formats like WebP and AVIF, but enjoy broader "historical" browser support.

Should probably change that to "poor visual performance," since the new formats are actually poorer [speed] performance than the old formats.

I have build jpegxl pixbuff plugin on ubuntu 20.10 and jxl is now listed on /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders there are other steps?

<@!795684063032901642>

possibly `update-mime-database`

damn i have a problem with krita update-desktop-database Error in file "/usr/share/applications/krita_jpeg.desktop": "jpeg/jfif" is an invalid MIME type ("jpeg" is an unregistered media type) The databases in [/usr/share/ubuntu/applications, /usr/local/share/applications, /usr/share/applications, /var/lib/snapd/desktop/applications] could not be updated.

ok i have removed krita and updated mime-database

now?

probably `gdk-pixbuf-query-loaders`

or `gdk-pixbuf-queryloaders`

`sudo /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders --update-cache` apparently

... ignore me, I didn't see that you did it already

it should work at this point I guess

I have did it

but it don't work

so you confirm you ran that, not just that `/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders` shows jxl?

no wait

i run ` sudo /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders --update-cache ` yes, no output on it

ok, and then it still doesn't work?

yep, it don't work

maybe you need to install some xml somewhere, let me check...

I remember I got it to work at some point in the distant past

one thing you likely need is `sudo xdg-mime install --novendor plugins/mime/image-jxl.xml`

unless the build system does that already

also, can you run `ldd` on the installed loader?

can you be more specific?

`ldd /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jxl.so`

` ldd /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jxl.so linux-vdso.so.1 (0x00007ffcc1581000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fae505ed000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fae505e7000) libgdk_pixbuf-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fae505c0000) libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fae50565000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fae50433000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fae50252000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fae50235000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fae50213000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fae50029000) /lib64/ld-linux-x86-64.so.2 (0x00007fae50cfa000) libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fae50023000) libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007fae4fe3c000) libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007fae4fe30000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fae4fdbb000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fae4fd9e000) libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007fae4fd40000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fae4fd15000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fae4fcfa000) libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007fae4fca5000) libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fae4fc15000) `

doesn't seem to have broken deps, so that's good.

did you try updating again the mime type info after xdg-mime?

it did the trick!

great! maybe we should add instructions...

` sudo apt install cmake pkg-config libbrotli-dev sudo apt install libgif-dev libjpeg-dev libopenexr-dev libpng-dev libwebp-dev git libgdk-pixbuf2.0-dev sudo apt install clang-11 export CC=clang-11 CXX=clang++-11 git clone https://gitlab.com/wg1/jpeg-xl.git --recursive cd jpeg-xl mkdir build cd build cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_PLUGINS=ON .. cmake --build . -- -j sudo cmake --install . sudo /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders --update-cache sudo update-desktop-database cd .. sudo xdg-mime install --novendor plugins/mime/image-jxl.xml `

cool!

wait

So thumbnails in file browsers work and also viewing with eog?

yep

if some thumbnails still give you trouble, then possibly delete the thumbnail cache with rm -r ~/.cache/thumbnails and restart the application displaying thumbnails, e.g. nautilus -q to display thumbnails.

also desktop wallpaper work

This URL gives you different results depending on what codecs you claim to support in your `Accept` header: https://res.cloudinary.com/jon/f_auto/sample

It currently returns a jpeg by default, a webp if you accept that, and a jxl if you have `Accept: image/jxl`

So once we get browser support, it will give a jxl?

Yes

Now already, if you manually fetch the image with the right http header: ``` curl -sD - -H "Accept: image/jxl" https://res.cloudinary.com/jon/f_auto/sample HTTP/2 200 content-type: image/jxl etag: "b376d12f595c5e8802f0ce5a2ef12679" last-modified: Thu, 28 Jan 2021 19:34:05 GMT date: Thu, 28 Jan 2021 19:34:16 GMT vary: Accept,User-Agent strict-transport-security: max-age=604800 cache-control: private, no-transform, immutable, max-age=2592000 server-timing: fastly;dur=221;cpu=116;start=2021-01-28T19:34:16.218Z;desc=miss,rtt;dur=19,cloudinary;dur=27;start=2021-01-28T19:34:16.371Z server: Cloudinary timing-allow-origin: * access-control-allow-origin: * accept-ranges: bytes x-content-type-options: nosniff access-control-expose-headers: Content-Length,ETag,Server-Timing,Vary,X-Content-Type-Options content-length: 47383 ```

Currently 900k web developers are using Cloudinary, most of which just use the free service, and a bit under 1% being a paying customer, most of those with very substantial traffic.

Many of them are using `f_auto` already.

Currently only the `jon` and `demo` accounts have jxl activated as a target codec for `f_auto`. We can pull the global switch when the first major browser adds support and we have verified that it works properly.

Another simple way of serving jxl to browsers that support it (working on it..) is the following: <picture> <source srcset="image.jxl" type="image/jxl"> <source srcset="image.jpg" type="image/jpeg"> <img alt="jxl or jpeg depending on what your browser supports" src="image.jpg"> </picture>

Yes, that also works, at least if you can change the markup.

I like the elegance of a single img tag with a server that varies response based on Accept header and Client Hints. That is a better way to avoid combinatorial explosion.

Because it's not just format, also dimensions you may want to vary based on viewport width, quality target you may want to vary based on the `save-data` client hint, maybe in the future HDR or not based on some new client hint.

Putting the cartesian product of all those things in the markup gets heavy quickly...

BTW that second `<source>` is redundant because it's already covered by the `<img>`.

Yep or change jpeg with webp or avif (but in the future if the percentage of JXL support in browsers is significant, I think it will be possible to leave only JXL with on-the-fly conversion to legacy Jpeg) ```<picture> <source srcset="image.jxl" type="image/jxl"> <source srcset="image.webp" type="image/webp"> <img src="image.jpg" alt="Image"> </picture>```

Unless we are talking about lossless or have the need for alpha, then JPEG should be preferred over WebP.

I mean, if 4:4:4 operation was supported in lossy WebP, I would actually use it.

Sadly, it does not. <:AngryCry:805396146322145301>

Adoption is a weird thing

Progressive JPEG was not supported in early versions of libjpeg, so in the first 10 years of the web, progressive JPEG was not really used.

The fact that progressive was rarely used was then later used as 'evidence' that progressive is a bad idea and not needed, to justify WebP not supporting it.

oof

In my opinion, webp near-lossless and lossless is very well, only webp lossy have problem.

WebP lossy was a quick hack to get more benefit out of the WebM/VP8 decoder that was available anyway.

WebP lossless was added later and was actually conceived as a still image codec

vp8 and vp8l

Except it replicated some VP8 limitations like max image dimensions, only 8-bit, and no progressive

Lossless webp is somewhere in between PNG and JXL in terms of sophistication, implementation complexity, single-core decode speed, and density results.

near-lossless webp can compare which jpeg xl mode?

`cjxl -m --lossy_palette --palette 0 --P 0` does something similar, but it is still experimental and can be improved.

I remember early progressive jpgs almost always led to a larger file size and people avoided using it. Not the case today.

I think early libjpeg also just refused to decode it, so that also doesn't help

Didn't know that progressive JPEG wasn't supported in early days of JPEG in web.

When it was? I guess IE6 already supported it, right?

Arithmetic coded JPEGs are refused to decode by 95% of software even today.

Even though all the related patents are expired for 10 years or so.

https://en.wikipedia.org/wiki/Libjpeg#History

So, 1995 🙂

progressive was added in version 6, released in august 1995

I was playing NES and even didn't dream about a computer those days 🙂

I don't know at what point browsers added support for progressive

I remember that IE6 had issues with PNG alpha channel

But OK, it is about some really ancient days of web anyway

Before JPEG XL was a thing, I tried to persuade Chromium developers to support JPEG's arithmetic coding

https://bugs.chromium.org/p/chromium/issues/detail?id=669501

https://www.thewebmaster.com/dev/2016/feb/10/how-progressive-jpegs-can-speed-up-your-website/#:~:text=Progressive%20JPEG%20Browser%20Support,Internet%20Explorer%208%20and%20below.

I'm so happy that JPEG XL does what I wanted (lossless compression of old JPEGs) and even better 🙂

this one says IE8 and below had significant issues with progressive JPEGs

so that's not _that_ early

As far as I understand, progressive JPEG was displayed properly, but without being "progressive".

back in 2011, IE8 had still like 60% market share

So it wasn't that crucial 🙂

I guess not, but that was probably a worse experience than sequential, which would at least render top to bottom

That and some ancient browsers probably not even supporting progressive at all...

I understand now why progressive JPEG didn't get more adoption

I always assumed it was just laziness of web devs using default cjpeg / ImageMagick convert settings, which are sequential

but there were actually good reasons to avoid it – in the first 3 years of images on the web, it didn't work anywhere (as in there were no available implementations that could encode or decode a progressive jpeg), and after that probably still didn't work for a long time in many browsers, certainly not actually loading progressively

BTW, does JPEG XL have non-progressive mode which allows to save a bit more space? It is useful for the cases when small images are embedded into CSS using data urls.

If your JPEGs are high quality (90+ and 4:4:4) I would try doing jpg --ll--> jxl --ll--> png --lossy--> jxl. This resulted in an even smaller JXL with no visible degradation.

you can also just do `cjxl -j input.jpg output.jxl` if you want to treat the jpeg as input pixels

cjxl does non-progressive for lossless by default, for lossy modular (with squeeze) it has to be progressive because it just inherently is progressive, lossy VarDCT (the main mode) is by default not very progressive: DC is sent first (sequentially), then all AC is sent (sequentially). Still gives you a nice 1:8 preview progressively, but that's it.

Thanks for clarification.

DC can also be sent progressively (`--progressive_dc=1`) for 1:16, 1:32 etc previews, and AC can be sent progressively (`--progressive_ac`) for 1:4 and 1:2 previews, and if you use `-p` (`--progressive`) it does both of those things.

There is no way to go "even more non-progressive" than default VarDCT, and it wouldn't help for density if we would add that, in fact it would probably hurt.

Yes, but it doesn't look as nice.

https://twitter.com/HenriHelvetica/status/1358459440773611520?s=19

Any updates on chrome integration?

Are here Chromium developers?

I was following the ticket related to adding APNG support to Chromium. As far as I remember, it was at least for half a year in code review (with a lot of changes during this time) before merging. So I wouldn't expect that JPEG XL support will arrive soon if the developers didn't promise it 🙂

https://discord.com/channels/794206087879852103/803663417881395200/808141830805651478 Hmm, it seems to be from the developers of this application (but it requires VS and Inno to compile and install the WIC decoder) <:SadCat:805389277247701002> <https://store.steampowered.com/app/228180/Action__Gameplay_Recording_and_Streaming/>

<:PepeOK:805388754545934396>

That application looks cool 😎

Pixbuf work in linux mint!

Ultra File Viewer Pro on Windows store says that it can view any file. I'll see if it can view jxl.

Hmm, nice avif picture.

it displayed it

in hex

but it displayed it

?

JXL made error first but then gave me this:

It does seem to work.

interesting

"Any file format" might not be marketing only.

Though oof, it does crash on this file format a lot.

The filename is jpg since that's what Megapixel outputs.

On Honeyview, I only get this.

Here's something interesting: When I alias the .avif file into PNG, it opens as a picture. When I don't, it opens as hex.

?

Is it just using imagemagick then using a whitelist of formats?

I don't know.

It does use 7% CPU and 160 Mb of RAM to display one picture, though.

If I zoom in too close, the side scroll bar becomes unusable, as it just stops in the middle of the picture.

Then when scrolling back down and up again, the picture has a white bar and the the program crashes.

Overall, I'm not impressed by the experience. The lack of zooming using mouse wheel is also a big turnoff.

I wonder if there's a better way out there.

Diplomatic response.

Ok, things are probably getting serious in Chromium. After some time the old issue 1056172 has been closed and merged into issue 1178058: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c2

Not only that, but also the priority: the old issue had priority 3 and the new one has priority 1! 😃

Make sure to star the new (linked) issue in order to receive notifications about it and support by showing interest!

So Chrome 91, I guess? 🙂

it will come soon™️

I definitely hope so

If it starts working in Chrome, then I'll *finally* submit my request to Google Photos to support JPEG XL, too

looks like decoding support is gradually rolling in, wondering when encoder support from important software will come in

Chrome is most important IMHO

Of course

It would be nasty for Google Photos devs to try adding support to this format and not even knowing if it works at all

I first planned to submit my request to Google Photos team quickly, but it seems like fortunately my procrastination found actually better and safer solution

I’​m just imagining an option for jpeg xl in google photos that automatically converts your entire library to it losslessly to save space or if it seamlessly encodes it to jxl and back to the user’s choice.. that would be a more compatible alternative of course these would be very bold moves

Ohhhh yeeeeaaaah

**Guetzli-encoded JPEGs:** JPEG lossless transcode

**Newly uploaded files:** JXL lossy transcode with a pre-set Butteraugli distance (remember, we're *finally* setting a *visual* target, not *technical* one!)

Oh ironically just supporting those might be a better idea than pngs since you couldn’t necessarily get the *exact* same filesize back

wait wait if it’s a lossless transcode why would you need a visual target

Better yet.

Next Google phone uses JXL to take pictures as a non default mode.

No more crappy techniques to get HDR stuff in JPG, crushing picture quality and true dynamic range, etc.

<@456226577798135808> lossless transcode only for already existing JPEGs, since Guetzli is already pretty lossy, I don't want any more additional loss. Lossy JXL will only be applied to new photos that won't be treated by Guetzli (at least that's the plan)

Oh that’s what you mean. I understand now Yes keeping constant visual quality is an added benefit on top of the file savings

Google Photos team will need a survey, what distance is the best compromise between quality and storage savings and encode JXLs with that distance

d 0.0 or bust.

Ah they could make it happen - someone just needs to show the numbers of how much less bandwidth would be used etcetera

google photos can also use jxl even for people with original quality uploads with the lossless jpeg→jxl transcode

Holy shit, those are actually free storage space savings!

You've got a damn good point bro too

i think dropbox does this already with something other than jxl

Lepton

https://dropbox.tech/infrastructure/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs

since 22% is similar to what jxl claims i'm guessing lepton uses some of the same techniques?

No, IIRC Lepton is anti-progressive, because it encodes AC *before* DC

Lepton is slightly denser and slower (and single threaded)

And it's specifically tuned for compressing JPEGs

Lepton should be compared more with Brunsli than with JPEG XL

Brunsli was once part of JPEG XL, but that was scrapped and lossless JPEG transcode is now done by encoding JPEG block coeffs directly as VarDCT 8x8 blocks

> 👎 <@!321486891079696385> why not 😐

Scrapping Brunsli made the spec easier, shorter and the encoder + decoder are smaller

Another minus of Lepton is that you can't view it in any image viewer bc it wasn't meant to be used this way, while JPEG XL is compressing by using the coeffs like an image codec and simply storing them better without doing any Brunsli or Lepton level ultra-compression gizmo

yeah tbh i don't know very much about the tech that makes it work, but the jpeg transcode ability has me really hyped. as soon as android supports jxl i'll probably convert all the photos i've taken

Me too, I'm waiting for Google Photos (and optionally Samsung Gallery, but I can file a request now bc I don't have to wait for a browser implementation)

Pls someone make similar graphs for JXL lossless transcode mode:

https://dropbox.tech/cms/content/dam/dropbox/tech-blog/en-us/2016/07/lepton-15.png

hmm maybe i can try that later tonight

https://dropbox.tech/cms/content/dam/dropbox/tech-blog/en-us/2016/07/lepton-17.png

`Lepton encode rate when encoding 10,000 images on an Intel Xeon E5 2650 v2 at 2.6GHz`

https://dropbox.tech/cms/content/dam/dropbox/tech-blog/en-us/2016/07/lepton-16.png

`Lepton decode rate when decoding 10,000 images on an Intel Xeon E5 2650 v2 at 2.6GHz`

jxl->jpeg should be faster than jxl->pixels right?

But the first graph would be the most interesting comparison

for a jxl that was losslessly compressed from a jpeg

I can't guarantee but probably yes, bc you don't have to mess with DCT and all that stuff

JXL→JPG lossless transcode is so fast that it's said it can be done in real time on a server

Any news from firefox?

Unintuitively, I think jxl -> pixels can actually be faster than jxl -> jpeg for large images.

Because jxl decode and iDCT/color convert can be done in parallel

But jpeg writing has to be done in the same way as the original jpeg, so it's sequential

Both should be quite fast though

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058

New Chromium ticket

Priority 1 chromium bug, that's good.

Firefox, no idea

Getting jxl in blink is first priority. Then webkit and gecko.

Webkit will be hardest because Safari/iOS use the system level prioprietary CoreMedia for image decoding

As far as I know, Apple has own fork of WebKit.

For example, when Safari already supported APNG (it was a surprise from Apple), WebKit didn't support it yet.

But why, they totally control webkit already

It is probably like Chromium and Chrome.

The APNG support was implemented in the closed source part of WebKit/Safari.

They have e.g. Kakadu in CoreMedia

For jpeg 2000 decoding

https://bugs.webkit.org/show_bug.cgi?id=17022#c47

From the time when WebKit added APNG support.

Apple's own implementation was a bit buggy.

Also HEIC is in CoreMedia, but it's not on the list of codecs Safari allows in an img tag

Firefox is still priority 5, i.e. "do not want"

Hm

No worries, the priority will be changed when it is released in Chromium

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

Just added a comment there.

good luck, they seem to just be ignoring it entirely

I wouldn't worry as much about Firefox. They tend to be late to the game. Once they see Chrome adding it in and possibly Safari taking interest, it will likely change.

They also have fewer development resources. I'm sure their interest will pick up as they see other browsers taking interest.

we'll see

jpeg writing could be partially parallelized I guess

Could it? If you don't control where the restart markers are?

Ah yes because huffman writes whole bits

So you can append streams

they want a 1.0 format i think. webp before 1.0 or 1.1 ??? i don't know the version wasn't adopted. maybe is that the reason?

Maybe. Version numbers are not the most reliable indicator of maturity though

It's after all just a name, something devs can just arbitrarily choose. I have seen version 0.1 software that is more robust and mature than some of the software that calls itself version 10.0.

version numbers does have a certain effect on people's perception. I would hope that developers would evaluate JXL on purely technical grounds though, of course 😄

so webp first version to be adopted in mozilla Firefox in 2019 which was

1,1.0 or 1.2.0

or a commit in between

version numbers do bring some info for the people outside: "If the developer of the software wasn't confident enough to call it 1.0 it must not be that stable"

Yes, but different communities have different standards for that. Some call the first draft version 1.0 and things only start to become usable around version 4 or 5, at the earliest. For others, 1.0 is a major milestone and indication of maturity.

What matters most for something like this is: - is the bitstream stable - is the library api stable - is the implementation robust - how likely are security issues - will security issues be fixed quickly

<@795684063032901642> any idea when I can expect the first Chrome Canary that has jxl support behind a flag?

For many purposes like web serving of jpeg, Lepton's excellent--the time to first byte is very short, so at the cost of some server CPU, you can decompress the lepton and deliver the jpeg while it's being decompressed--virtually no difference to clients.

Still the size difference. On slow connections saving 22% on the load time would be nice.

Is the time to first byte also short when the jpeg is progressive?

I think decoding of animations will also be a required step for including jxl in browsers

Yes, we should be functionally as complete as possible: color management, transparency, animation, progressive decode: the more we can get working correctly from the start, the better.

(but we also shouldn't let perfection be the enemy of the good, better to get things working well enough than to take 2 years to get the best possible browser integration)

Yes, you are right. That is a hard lesson to learn 🙂

we would also like to have HDR working, we are looking into it

<https://forum.doom9.org/showthread.php?p=1935952#post1935952> Also, yes, it would be nice to post JXL WIC here if someone has already compiled it (I might do it later when I have time, since it requires VS and Inno)

https://irfanview-forum.de/forum/program/feature-requests/13089-

<:Thonk:805904896879493180>

I messaged Irfan a few days ago about JPEG XL: https://discord.com/channels/794206087879852103/806522208692207617/807992518116769792

He essentially just said "later". 🤷

I see the post has the tag **Supported** so maybe it was implemented 🥲

Just saw this. Hopefully soon: some code review if going on here: https://chromium-review.googlesource.com/c/chromium/src/+/2693607 and there is this tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058

ah cool

no animation yet?

I think it's OK to focus on still image for now, since that will be the main use case and animation does add some complications

doing DC progressively would be nice if that can still be added

though maybe it's best to get some MVP implementation in already, then improve it

RGBA with correct color handling is already nice

I'd prefer if animation and progressive also worked from the start when it's not behind a flag anymore

to avoid bad first impressions and people saying "you said jxl was progressive, but all I see is the same non-progressive decode as avif"

Great to see progress on getting in chromium, if we are in there, then that's a VERY big step in the direction of universal adoption

not the only thing that needs to happen, but it will make it a lot easier to convince other software that they need jxl support too

how to use it on chrome?

not yet

unless you build your own with that branch checked out

I hope we make progress on progression soon and I agree that it would be nice to have before enabling the flags by default. We do have correct color handling, but in the commit above HDR is not yet implemented. We are also working on that.

I hope non-photographic image quality can more stable in vardct(in high bbp), some non-photographic image get worst case in vardct and worse than avif.

Yeah, most features need to be complete when support will be available without a flag in chrome. I don't want jxl to have a PulseAudio type of release 🙂

Is there yet a full-featured picture viewer that accepts jxl?

Anything that uses qt on linux

using the plugin

there are also plugins for WIC for windows, nomacs, and a jxl viewer for macos

I see the WIC plugin for windows has no release yet. Can you install the dll?

https://caniuse.com/jpegxl

my next blog post is ready and queued for publication on Monday morning (US west coast time)

title will be "Time for Next-Gen Codecs to Dethrone JPEG"

it's going to be a nice one, spent quite a lot of effort on it

Nice, about time for an article that talks about getting rid of JPEG. 👀

will talk about jpeg limitation in ybcr and how to convert png,gif and jpeg with jpeg xl in a lossless way? or cloudinary talks?

It's basically a comparison matrix to give an overview of the features and properties of JPEG, PNG, J2K, WebP, HEIC, AVIF and JXL, making the point that maybe J2K and WebP weren't strong enough to overthrow the JPEG/PNG combo because the difference was small and there were aspects in which they didn't (reliably) beat JPEG/PNG, but in the case AVIF and JXL it will be different.

Be sure to link it.

https://res.cloudinary.com/cloudinary-marketing/image/upload/w_960,f_png,dpr_2.0/Web_Assets/blog/Battle-of-the-Codecs_fnl.png

That is the "conclusion" comparison table

From the blogpost that will be published tomorrow

lossless: WebP = HEIC = AVIF 🤔

Or is it visually lossless?

Lossless photo is that row

For lossless nonphoto they are quite different

Lossless WebP is strictly better than PNG (for 8-bit), but PNG is not very good for lossless photographic images

E.g. lossless j2k is often better, also e.g. for medical imagery (which is also sensor data)

Even J2k lossless is better than WebP lossless for photos (although I haven't tested the more efficient commercial codecs)?

No difference between kakadu and openjpeg for lossless, I don't think j2k has much bitstream choices at all in lossless

For lossy, kakadu is quite a lot better than openjpeg, and the table is for kakadu

Looks fair, the table?

The rest looks good (only for lossless WebP photo I would probably add half a point, although it depends on the content and format's capabilities and for example for the web is still the best option for lossless compression including photos)

why is generation loss resilience for jpeg and jxl rated the same, wasn't the original jpeg a lot more prone to generation loss?

It depends on the implementation. When I try default libjpeg-turbo or mozjpeg, it's quite resilient

Some implementations like current imagemagick seem to be doing something wrong and they degenerate fast

https://youtu.be/FtSWpw7zNkI

In AVIF, I also tried not decoding to rgb but staying in yuv444/yuv420. It didn't make a noticeable difference.

Yep, it all depends on the encoders, also progressive decoding is a bit better in JXL (but maybe 4 maximum points are not enough to show the difference, although in some ways it will be better in j2k, so it's ok)

J2K is extremely flexible in bitstream ordering options, maybe too flexible (to allow efficient implementations)

<@!794205442175402004> Btw, comparing incremental decoding support can also be interesting (and for example Pascal Massimino considers it even more important than progressive, less cost to decode and a clear understanding when the image is fully loaded)

JPEG XL can do both 😉

That is imo mostly a matter of implementation

An incremental avif decoder should in principle be possible too

It's just that video decoder implementers cannot be bothered with providing an api that lets you get a partially decoded frame, because why bother with that complication - it does not have any use in the context of video

Yep, although I prefer progressive decoding, incremental is still something like an intermediate option (which is probably worth mentioning)

It's certainly better than nothing

when the article about jpeg xl?

NOW

https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg

"the existence of the tag" is there an "<img>" supposed to be there?

its either getting filtered out or parsed as an actual tag (cant check which, on phone rn)

yes

There is supposed to be an <img> there

It's weird too

If I move it back into the text using devtools it shows up

i read it

18 minutes

Ah the <img> disappeared

Will get it fixed

Something strange with WebP resizing <:Thonk:805904896879493180>

What am I looking at?

Is fixed now, if you hard refresh

👍

Hm, I think the css might be set to NN rescaling, that's probably not a good idea

I should have picked a smaller image so there is no browser downscaling