JPEG XL

I don't really care if FFMPEG can decode an image format. I'll switch when Firefox, Discord, Irfanview, CDisplayEx, and Tachiyomi all have support

Actually I suppose Firefox doesn't matter as much since I won't really be opening local content with it

I meant personally

Like, it doesn't effect my personal transition to the format

Wouldn't surprise me if Discord they patches in JXL first, because the lack of generation loss will help with the current problem that every image on mobile is too big so they'll downscale it

> I don't really care if FFMPEG can decode an image format. Actually you can fiddle a bit with image formats in FFmpeg. https://en.wikipedia.org/wiki/FFmpeg#Image_formats > I'll switch when Firefox, Discord, Irfanview, CDisplayEx, and Tachiyomi all have support IrfanView support is stalled because everyone is waiting for Irfan's response to an email about it. I don't know anything about CDisplayEx, you can ask them directly for support. Tachiyomi is FOSS software available on GitHub, so adding support for JPEG XL is as simple as adding a pull request with libjxl and its integration code (you can file an issue first if you can't do the coding).

mainstream manga jxl could be hard but could be also possible if some people are interested enough

i think getting jxl on browsers working is number one thing

Yup

I think Manga sites will be early adopters

In general, the anime piracy community is cutting edge. Oldest AV1 anime release I can find is an experimental one from 2018

Mangadex has a lot of competitors

Just scroll through Tachiyomi. There are like a million of them

__**How to permanently enable JPEG XL in the latest stable Microsoft Edge 91**__ 1. MAKE SURE THAT THE BROWSER ISN'T RUNNING. 2. Open `%localappdata%\Microsoft\Edge\User Data` in File Explorer. 3. Open `Local State` file in your favourite text editor. 4. Find `"enabled_labs_experiments":` string. a) If you found it, enter `"enable-jxl@1"` inside __empty__ brackets next to the string above. b) If the brackets aren't empty because you've already got some flags enabled, insert `,"enable-jxl@1"` (yes, with that comma) before the closing bracket, after all other flag descriptions (or inside the list, I tried to keep its alphabetical order). c) If you couldn't find that string, try temporarily enabling a non-harmful flag (I'd recommend `Parallel downloading`), then close the browser, open the file again, and replace that flag's string (`"enable-parallel-downloading@1"`, if you followed my example) with `"enable-jxl@1"`. 5. Save and close the file, then open the browser and test if JPEG XL is working on https://jpegxl.info, https://jpegxl.info/jxl-art.html and https://mo271.github.io/jxl.

Apparently it is... https://www.ghacks.net/2021/05/11/find-out-if-your-browser-supports-the-new-image-format-jpeg-xl/

The ghacks.net guide asks the user to run Edge with `--enable-features=JXL` command-line parameter (or to add it to the Start Menu and/or Desktop shortcuts). My guide allows you to enable it *permanently*. ...or until you decide to turn it off, then just remove `"enable-jxl@1"` string from the file from my guide.

Please update your Edge to 91, check if my guide works (it may not, don't hold me liable in case of breakdown lmao) and if it works, feel free to share it anywhere on the interwebs. Consider it public domain.

Sorry, I couldn't find JPEG XL in Experimental Features in DevTools in Edge 91.

I know it's JSON, but don't want to fiddle with whitespaces, I don't know how will Edge react to it... And you need to find `enabled_labs_experiments` anyway.

I could reproduce it, and also noticed a lot of `pow()` calls in Callgrind. I think it's a similar issue to the one observed here: <https://github.com/mm2/Little-CMS/issues/2#issuecomment-3699863>.

Anyways, the fast float plugin of lcms2 helps here, see e.g. <https://github.com/kleisauke/libjxl/commit/44bc535532216661aa282dc3dde960e0faac7f7d> (unfortunately GPL-licensed).

yeah, the fast float plugin is a bit of a problem for jxl as you can imagine, which is why we go with skcms. Although I believe <@!604964375924834314> fixed the issues that we had left with skcms, so I suppose we could get rid of lcms entirely?

(maybe it doesn't quite support all kinds of display profiles, I'm not sure)

the fast float plugin doesn’t have to be linked to libjxl specifically, iirc, it would also be possible to just have it in cjxl

(/ djxl)

or the viewers, I guess

ah, and yes, for the viewers, skcms was a no-go

it doesn’t support converting to a LUT-based profile

which is likely to be relatively common for display profiles

or at least I think it didn’t at some point (?)

right, that would be a problem

but I guess we don't need to depend on lcms in libjxl, no?

I wonder how that works in Chrome...

it has always been broken

https://crbug.com/820233

Oh, you mean it isn't needed in the core library? I found this TODO-item: <https://github.com/libjxl/libjxl/blob/0f6ddd4727f2c51bb2396872599d4f86f19bf064/lib/jxl.cmake#L367>.

“CMS” refers to “either skcms or lcms”, so currently, building with skcms should already avoid an lcms dependency

but yes, in principle it should be possible for libjxl to depend on neither

well, for libjxl_dec

the encoder does need a CMS, and likely will for the foreseeable future

but I think there's no downside in making color_management.cc only have skcms

part of me is somewhat uncomfortable with it, not sure why

is there much of an upside?

we don't have to wonder if it's actually thread safe, for one 😛

Does skcms support cmyk?

At some point we need to make cmyk work in djxl and viewers

and encoders?

xD

Not sure what encoders should do in the cmyk case, probably mostly do it losslessly

XYB doesn't really make a huge amount of sense for CMYK because brightness is as much influenced by CMY as it is by K

<https://forum.doom9.org/showthread.php?p=1943897#post1943897> > change skcms to littlecms2 <:Thonk:805904896879493180>

what commit is that

4dbbdca5

ah he added a 5

hey all, we are collecting data for the decision to have JPEG XL on by default in Chrome and we would need your help. Could you please share images or descriptions of use cases where JPEG XL does better or worse than AVIF? either here on Discord, in a GitHub issue, or using this form: https://forms.gle/rnKJt5RWq5tvdXueA

```@```everyone on this message? 😛

@here sorry for the spam but it's kind of an important thing

isn't jpeg xl in chrome canary already?

like aren't they already considering it?

anyway i will complete the form, but it was just a thing i was confused about

considering is not the same thing as making the actual decision of enabling it by default

enabled by default is basically a more or less irreversible thing

oh okay

i personally really want to see jxl enabled in chrome

I think many people here share that sentiment 🙂

thanks you guys for making it clear how we can help <:S3ShigHappy:644095715500621834>

that’s great to hear and if you would like to describe why, we would be grateful 🙂

yes

i'll submit the form shortly

<@!794205442175402004> feel free to use https://www.youtube.com/watch?v=-7k3H2GxE5E as a "AVIF doesn't have progressive" thing. Although the AVIF folks seem to be saying they will have proper progressive rendering at some point.

But also, the image I used in that video, AVIF is really bad at compressing it

AVIF & CATS don't mix.

😀

https://photos.app.goo.gl/3JyubXiBcggJQBS56 here's the full image

You specifically need data and info on *lossy* JXL as compared to AVIF, right? also, it's better if images are copyright free/limited right

With the cat pic, AVIF over-smooths the chiminea. It might be ok, but since it's between the two faces, my eye is really drawn to it

I think we don’t mind duplicate reports 🙂 it’s also useful information if there is something that many people seem to care about

Just imaging the cats were sitting there licking it for a while.

there are still a few serious things being found in libjxl by fuzzers, so I'd think delaying a few more months would be sensible myself libvips isn't planning to enable libjxl by default until the autumn (for what that's worth heh)

if Modular mode has specific advantages (for example the palette transform), I think we are happy to hear too

noted, thanks 🙂

Note that chrome 93 feature freeze is on June 18 but the actual stable release is on August 31 - any security bugs found in between those two dates can still be fixed afaiu

Oh, interesting. Yes, we're imagining sep/oct some time for enabling libjxl, so that lines up. I think we're assuming that by then issues from fuzzing will be down to ~ one minor thing every few weeks (hopefully).

<@!794205442175402004> Maybe also put it in the <#803379415106584626>

<@!387462082418704387> or someone

v0.3.7-51-gaf6ece2 sse4 - 2021.06.01

i need a newer build

is jpeg xl improving at less than q 48.6?

has the medium quality less perceived detail than before or is transparent?

I don't think there have been changes lately in lossy encoding

yes but medium quality fix is not enough

for a modern encoder

<#803574970180829194>

people as spidermario said are interested in super low bitrates

<@!111445179587624960> we're talking about what spidermario did

(when did I say that?)

even to webp2 if you send the latest build from today

when it expires? <@!604964375924834314>

ah that was kornel

when it expires spidermario

I share my builds here https://eddiezato.github.io/bin/

thanks

you are a genius

even with the date

Never really used AVIF so I guess I’m not the right person to answer this, I just know JPEG XL would be better than the JPEG and PNG I currently use on my websites

agreeable.

May want to post that on the jpegxl reddit too?

even without having actually used AVIF, maybe you could say why you were not particularly inclined to?

I tested avif and jxl on non-photographic images, but I can't choose a winner, compare current version(libjxl, libavif), jxl and avif have different strength and weakness.

we would be very happy to read what you think they are if you have identified them 🙂

It wasn’t widespreak enough maybe? And never really got interested in formats, didn’t know you could do that much better. Also I feel like JPEG XL has an overall very advanced philosophy, with best overall compression, lossy and loseless, animations support, progressive rendering, JPEG compatibility… all those things that I feel really makes sense to switch format now (I’m no expert, just fond of tech and an embedded developer, doing web stuff from time to time)

Actually in my company we are designing an IoT product that has the main purpose to display stuff. We are having trouble decompressing big PNG right now on our microcontrollers, it’s normal it needs to be upgraded for the resolutions we have, but I asked myself if JPEG XL could be integrated and if it would give good performances considering the limited ressources of our embedded products (RAM is pretty expensive compared to those in computers)

Here’s the product: https://sectronic.fr/portfolio/lisa-laffiche-dynamique-conectee/

I only focus on the important parts:

For low to high bit rates, AVIF looses finer detail rather quickly. JXL looks way more consistent across different content.

For high to very high bit rates, AVIF struggles to utilize the additional bits. Most dominantly, AVIF produces very bad banding artifacts while I consider only JPEG XL (VarDCT mode) as being able to achieve visually lossless outputs at reasonable file sizes for natural content (at least when outputting to a high bit depth or once they support dithering in the decoder or when using noise=1). Just take a look at the awful sky in the AVIF picture: <https://res.cloudinary.com/mattgore/awful_banding.avif> While JXL handles that perfectly fine...: <https://res.cloudinary.com/mattgore/zero_banding.jxl> ... and is visually no different than the original: <https://res.cloudinary.com/mattgore/original.webp> (Once browser support JXL by default, I will use lossless JXL instead of lossless WebP wherever lossless is needed.) Also, compare how AVIF fails at reproducing the mountain texture around the person's shins.

For very low bit rates, AVIF avoids common artifacts and might be called pleasing but looks fake at the same time and might even remove important parts (e.g. small stars in the sky). JXL shows some slightly noticeable but unobtrusive artifacts. So when seeing the JXL, you know that it is a lower quality and slightly inaccurate picture but it still looks fine overall. In Contrast, AVIF is way more puzzling to the viewing person since it is hard to decide if the partial blurring of specific regions was artistically intended by the creator or a compromise made by the image encoder.

Regardless of bit rates, AVIF can cause an unwanted shift in color across a large part of the image. It also struggles with small color details when using chroma subsampling, whereas 4:4:4 isn't supported very well. JXL only has minor saturation issues in some very specific image cases and when combining the optional modular mode at very high quality with the XYB colorspace. (Jon recommended to try out RGB and that worked perfectly.)

Most of AVIF's issues also weren't even present in the original JPEG image format, so it is a very bad idea to convert those files to AVIF (or WebP) for size reductions. JPEG XL on the other hand even supports truly lossless recompression of these files but also works fine to greatly reduce size of very high quality JPEGs after those have been rendered to pixels.

Also, the libjxl encoder is quite nice and has a good performance. Free encoders for AVIF aren't that great and performance is rather poor overall. And AVIF can't even store lossless 8 bpc RGB efficiently.

yes jpeg xl has more control of image

your comment is good

do you used jxl 0.3.7-54

do not wrong delvish use this value

maybe he counts himself

but don't know if he's real number of commit

how he measure them

zero_banding_avif

how you created it?

libavif 0.9.0 (aom [enc/dec]:3.1.0-13-g3bd281799) > avifenc --min 9 --max 9 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=9 -a color:aq-mode=1 -a color:enable-chroma-deltaq=1 -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=8

thanks

Interesting. How does it perform on dark gradients? Do you have to manually tune the parameters for each image or can you use the settings you provided for any image content? And still, the other issues of AVIF remain like the blurry mountain texture.

AQ-mode 1 and chroma-deltaq are quite powerful as command-line options, and I use them every time. Grain synthesis can be used as well(since it only models after the original noise), and 6-8 is a good strength for almost all images.

They improve the encoder output to the point of not even being funny.

To be fair, the encoder has improved a lot on aomenc's side as well, even without using 10-bit(which activates the HBD pipeline and fixes the issue seen in the sky, and I think aomenc should activate the HBD pipeline at all times) I do agree with your points however. It's just that the encoder matters a whole lot more than the standard.

I think BlueSwordM is explanation this command how to work, thank you <@!321486891079696385> 🙂

AVIF would need a free encoder that achieves good image quality with one or two parameters at a good speed to impress me. But if JXL get adopted quickly, than that is rather obsolete from my point of view.

The spec limits what even the best encoder can do. The available encoders limit what can currently be done with the format.

For both, probably there is significant room for improvement.

av1enc after 4 commits

q 73.9712

and write as avif and effort 9 commands

don't know if firefox can read them

Jon is from Cloudinary so he knows

av1enc is slow

effort 9 you need

The main problem is that JPEG-XL is absurdly fast in that image compared to others. However, here's an example where avif with aom has improved a lot in that regard still: https://slow.pics/c/TVmZLYrX Notice how the sky is better on JPEG-XL and preserves the tiny noise that aomenc can't preserve(without the HBD path), at a cost though. aomenc: `avifenc -j 4 --min 3 --max 8 -s 4 --tilecolslog2 1 -a tune=butteraugli -a aq-mode=1 -a color:enable-chroma-deltaq=1 -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=8` JXL: `cjxl input.png output.jxl -s 9 -d 0.8`

maybe try cjxl -s 8, -s9 sometime can't get best result?

S9 in this image gives the best result.

From my own testing, S9 has a subtle, but noticeable improvement in most photographic images.

I'd like to talk more, but I need to go take my vaccine shot now.

oh, thank you <@!321486891079696385> 🙂

To be honest, I hope jxl can replace avif, so I still wait Jyrki Alakuijala integral transform selection improve.

Am I the only one that can see just a little, but still a bit of banding on the improved AVIF image?

(The quality *did* improve nevertheless.)

Perfectly normal.

The banding is because the colors are so close together that in 8-bit, aomenc can't seem to get the banding out.

Remember that JXL internally does VarDCT on 32-bit floats™️, IIRC... Would 10-bit AVIF help with banding to the point of it being imperceptible?

Yeah, 16bpc(10-bit+) processing actually does get rid of the problem entirely.

yeah improved one still has banding

while jxl looks fine

can confirm that 😛

That's cool, <@!387462082418704387>! Could you please also add the GIMP plugin? (It seems that no Windows "builders" are interested in the plugin…)

What dependencies do I need to install in msys2 to build the gimp plugin? gegl, babl, gimp itself, gtk, etc.. Maybe someone who has already built this can help.

<@!604964375924834314> is enlightened in that.

<@!604964375924834314>, could you please share your knowledge?

just `mingw-w64-$arch-gimp` should be enough iirc, but you probably also need to set the `…_PLUGINS` option to “yes” in `CMakeCache.txt`

Ok, it failed. 😕 Log: https://pastebin.com/Svq3SncM The command was: ```Bash cmake -B build -G Ninja -S ./ -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_DEVTOOLS=ON -DJPEGXL_ENABLE_PLUGINS=ON -DJPEGXL_ENABLE_GIMP_SAVING=1 -DJPEGXL_ENABLE_OPENEXR=OFF -DJPEGXL_ENABLE_SKCMS=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF -DJPEGXL_STATIC=ON -DJPEGXL_WARNINGS_AS_ERRORS=OFF -DCMAKE_CXX_FLAGS='-ffunction-sections -fdata-sections' -DCMAKE_EXE_LINKER_FLAGS='-Wl,--gc-sections -Wl,--no-export-dynamic' .. ninja -C build ```

that’s odd, it seems to work for me

how old is the build folder? maybe some of what cmake detected from pkg-config is stale

actually, let me try your exact command

maybe one of those flags is somehow problematic

ah, with your command, I get the same error

now, to find what’s different that causes it

ah, it’s `-DJPEGXL_STATIC=ON`

it should work without

Okay, it works. But now every tool asks for a bunch of dlls. Because now it's a non-static build, right? How can we build it statically?

one way would be to have one build folder with `JPEGXL_STATIC=ON` for the tools, and one without for the GIMP plugin

empirically, it seems that GIMP loads the plugin with all the necessary DLLs

Yeah, I thought about two builds. 😄

I personally just build everything dynamically, and since I run the tools from a mingw shell too, they have access to whatever DLLs they require 😁

they’re in the PATH

Yeah, but unfortunately they can't be shared with people without msys2 😉

Hehe, I tried this non-static plugin in gimp 2.10.24 and it works fine <:Poggers:805392625934663710>

Ok then, now it contains gimp plugin

what is file-jxl.exe

That's the actual GIMP JXL plugin.

Wow, that was super fast, thanks!

where to copy

and how

i'm installing the development version

GIMP → Edit → Preferences → Folders → Plug-ins. One or more folders should be listed there or you can add another. Then just copy file-jxl.exe to one of those folders and restart GIMP.

<@!794205442175402004> What is the status of JXL in Cloudinary? Will there be a big anouncement once it fully supports JPEG XL?

you mean when it also does animation? still is already kind of fully supported (at least decoding and encoding work, as well as f_auto serving of jxl)

do you plan to add f auto also to libjxl

?

no, libjxl will only encode jxl, no other codecs 🙂

in cloudinary you have automatic quality based on resolution etc

why in libjxl there isn't

why you added automatic quality only to cloudinary

cjxl input output is automatic quality

For example, the canyons image scaled down to a width of 400 pixels and delivered with both automatic quality selection and automatic format selection (q_auto and f_auto),

does this exist in jpeg xl in cloudinary

Will we see multi-frame/animation support or is this not going to happen anytime soon?

It will certainly happen, but it might take a while — it's not a super high priority since any browser that supports jxl will have other, better ways to do animation

Sure, but it's super simple in the case of jxl: `q_auto:good` is just the same thing as `cjxl -q 80`, `q_auto:best` is the same thing as `-q 90`, `q_auto:eco` is the same thing as `-q 70` and `q_auto:low` is the same thing as `-q 60`. In cjxl, these are actual perceptual targets, not quantizer settings like in e.g. jpeg or webp, so q_auto is trivial to implement for jxl 🙂

One more mime db done: https://github.com/gabriel-vasile/mimetype/issues/154#event-4837715696

do you standardized the logo that information and tech site will share

You mean <:JPEG_XL:805860709039865937> ?

No, it's not part of the standard

no the other

of github

<:JXL:805850130203934781> ?

yes

That one certainly not

so you will not decide copyright

or help to clarify how it works

<:JPEG_XL:805860709039865937> is the official logo, made by the JPEG committee, and it is CC-BY-ND

<:JXL:805850130203934781> is the libjxl logo, and it is CC0

I want better JXL animation support 😬

(plz)

In what? Browsers? They will add it in eventually, it's not as important of a feature.

what does better mean?

Showing them animated (or at all) and supporting conversion back to APNG.

first one works in chrome beta (or it should)

apng, eh, that's another story

Yes, but would be nice if other programs make that work as well.

Cute

I'm thinking about convincing Chrome and possible obstacles there

what is the sentiment here if we would enable lossless JPEG XL features only in the first stage

i.e., lossless JPEG recompression, pixel lossless (modular), perhaps palettized imaging, too

that way JPEG XL wouldn't conflict with AVIF's feature space and could be more attractive for integration

that'd cause confusion for adopters (eg if browser can do image/jxl does that mean all features or only lossless?)

yes, but if alternative is no jpeg xl in browsers right now, it might still be better to do something

we haven't yet fully measured how strong Chrome's commitment to AVIF is and if they will be protective around it

we might need to add another mime type later for lossy compression, or solve it otherwise -- for example by having both lossy and lossless behind a flag

chromium being fast to update may not poison it too much, so it somewhat makes sense, but keeping it that way for too long could be sorta dangerous, especially if any other browsers would decide to do the same for whatever reason

Cripling jxl doesn't sound like a good idea to help with adoption

I'd anticipate a six month period like that and turning both on at the first moment when another browser integrates

I think the technical merits of the format will win in the end

nothing at all, cripling, or full launch are the options

AOM might not like it a full launch as it would possibly deprecate/reduce the value of AVIF, and AOM member companies have invested into it -- suddenly the hardware decoders they built would be a worthless investment

if AOM doesn't like it, Chrome needs to decide whom to make annoyed -- their long-term video compression technology partners or a couple of image enthusiasts

would they actually even use AVIF w hw decoding? i think hw for many-images use case is sorta bad fit anyway

no, they wouldn't use it (or perhaps they'd use it in extreme use cases like animation or large photos loaded from flash)

but currently they think they would, otherwise they wouldn't be specifying and building those decoders

AOM should stick to video. AV1 is good for video.

they define media as their scope nowadays -- they started with video

"Next Generation, Open-Source Digital Media Technology for Everyone"

I consider the main reason it was founded was inefficient IP practices on media codecs at ISO

ISO creating a lucrative business to make billions of small incremental improvements and about the worlds need to communicate through mpeg standards

companies got tired of it, got together and built AOM

now, we are coming from ISO with our proposal hitting to their foundational thought that ISO is dangerous/inefficient/to-be-avoided

JPEG had HDR, alpha and other features that weren't implemented at launch and the snowball rolled and no one implemented them.

yes, it is a risk that can happen

still, lossless jpeg recompression + AVIF would be a better world than just AVIF

but will you be truly happy in that world? 🙂

I'm a pragmatic person and go for the best available option whatever it is 😄

the codebase for JPEG recompression has significant overlap with the VarDCT coding -- the full libjxl decoder would be shipped, just with VarDCT disabled for first six months or so

Yes, but first impressions matter. If content creators got the first impression that jxl can be used only for that it will be hard to change their mind later

Artificialy cut the decoder features don't sound good

I don't really think that it'll be as big political issue. AV1 isn't going away anywhere. but i could be wrong idk

i personally would be fine just with lossless part because i have a lot of anime art in my dl folder

We will learn about the balance of political, communication vs technical in the coming weeks with the Chrome 93 launch

in my experience every compression achievement that I was participating was super political, and success was more impacted by soft influencing than by technical superiority

one of my greatest achievements was WebP lossless which took three hits because of politics

1. image size was restricted to 'match' that of WebP lossy

1 makes sense tho it would be sorta legit weird to have that mismatching documented

2. I wasn't allowed to make my own 16 bit per channel lossless version as layers were going to solve that. However, layers was cancelled afterwards.

ouch

3. It took 10 years to deploy it in all browsers, because there was no effective soft-influencing

the opposite effort is WOFF2

it had the greatest team to do communication

perhaps 10 big guys in the industry just for communicating around it

me and Zoltan hacked up an initial solution up in seven weeks and it was already approved (still with some conditions) by the respective W3C committee

it went smooth because they knew how to reach agreements -- they said they learned it the hard way during WOFF 1.0 standardization

WOFF2 reached about 85 % deployment rate in the first year

maybe it's also sorta about where it gets standartised? though yes, communication is v important

But what is the problem with adoption at the moment. From what I see jxl will be available behind a flag in firefox, chrome and edge. To me this looks spectacular. What is the problem?

i think we will see how it plays out in coming weeks

I don't see a really feasible way to just enable JPEG recompression...

yes, it is difficult to do it with JPEG because JPEG is already lossy

we could however disable some of the VarDCT mechanisms like adaptive quantization

I don't think it will affect the decision in any way, but we'll see today

putting it in so far is an engineering decision -- turning it on is a director level decision

I do think we can use things like JPEG recompression to help sell it in a different way though

oh no... I really need jxl lossy vardct... 😢

oh, so it might not be enabled after all 😐

jpeg recompression is kinda vardct codepath.. but var part of that would be disabled i think

What decision will be held today?

no decision, just a chat

avif still makes sense if encoders have av1 encoding hw

But not too much on the web where you have many images on a page and is hard to use hw

yea not at client side

I don't want use avif tune-PSNR on my still image.😢

So facebook and cloudflare would be interested to use jxl, so if there are big users they should enable support

In my opinion, I think vardct just need some improve for non-photographic images, jxl vardct quality will better than avif lossy on any use case.

I still have the ideas in the pipeline, haven't been able to act on them

I understand 🙂 , I compare jxl and avif a few month before(non-photographic images content).

<@!532010383041363969> if you enhance it, they will come! 🙂

Sounds like a bad idea to me to intentionally cripple jxl to make it more acceptable to avif fans

would you rather delay by 12 months than ship lossless recompression and modular only?

Really hoping you don't have to take this path. The lossless features are great, but JXL's VarDCT is most significant for new images, IMO.

likewise. i hope it doesn't come to that

Good question. If it's 12 months, I have to think about it. If it's 12 weeks: yes, I would rather delay than ship something partial and have mime type weirdness

I suspect we'd be talking a minimum of 6 months if we don't find a compromise with AVIF

... and very likely 12 months

in this case you need to ship a codepath from png to jpeg-recompressed I think

we haven't had capacity to convince everyone, so I guided our effort to focus on facebook only as they are one of the biggest owning both ends (client/server)

next up is convincing a browser and I was hoping we can do that with facebook only

Chrome is unlikely the first browser to support as they are worried about their reputation in AOM

I think we need to make a point that JPEG != MPEG, and not all ISO committees are the same. Do they also want to get rid of C++ and A4 paper?

that is why I'm looking at a feature set that wouldn't make anyone in AOM upset

truth and perception are different

in short timespans perception matters more

gif, png, jpeg, bpg and zlib are probably ISO standardized, too (didn't check)

ISO/IEC 21320-1:2015 (a subset of ZIP file format 6.3.3) etc. etc.

speculation: these are video people who have dedicated their lives to making video better -- a significant personal achievement for them was to win over mpeg hegemony and set up AOM

what other things are on going matter less to them than their personal experience and their personal achievements

jxl feature => near-lossless(vardct) and lossless avif feature => lossy(medium and low bbp lossy)

What if you ship a subset of jxl and it gets accepted in browsers, but the full spec never gets accepted?

that can happen

it is just my speculation right now, no one else is proposing this

I'm just trying to avoid a waiting game

Honestly, AVIF's blur just looks dishonest to me, I prefer VarDCT.

i prefer my jpg to be compressed

even if doesn't look natural

The main motivation for AOM is to have royalty free media codecs. JPEG XL is a royalty free media codec. We are not their enemy. If anything, having jxl in chrome might help stop Nokia from starting litigation with their patents on HEIF, which could change the royalty-free status of AVIF...

like cavif or jpeg xl

I agree your opinion, but for now we need find a new format position. > Jyrki Alakuijala > why I'm looking at a feature set that wouldn't make anyone in AOM upset

I'm thinking that facebook could start using jxl even without browser support. They could enable the use in the phone apps and use it because it is a better format and it useses less space for the same quality (mobile data bandwith).

Without browser engine support?

In their app they can do that

It's just nicer if they can do it also outside the app

I think it might help if we could get AOM to recognize that any royalty-free codec helps to make the landscape more royalty-free, not just the ones they develop themselves.

We needed something to compete with HEIC, and both AVIF and JXL serve that role

That's a more positive strategy.

Arguably for many use cases, JXL serves that role better than AVIF

So they should see us as allies, not opponents.

It's a bit early to tell, and more subjective studies are needed, but I think for Cloudinary a likely deployment strategy will be that we use AVIF for low-fidelity high-appeal targets (q_auto:low) and JXL for high-fidelity targets (q_auto:good)

For that we do need a non-crippled jxl in browsers though.

I just thinking if define jxl format position to near-lossless(vardct) and lossless, Maybe format position will like this jpeg(avif), png(jxl), lossy png(jxl) ?

I see avif as a good replacement for lossy WebP

Yes, I don't see jxl threatening avif's longevity in low bpp.

Yes

If you ship only jpeg-re-compression how you make sure that in the future you can deploy full decoder?

You can't, that's the issue.

Shipping an incomplete decoder is a bad idea imo

Current cwebp have three mode, lossy, near-lossless, lossless, avif can't work very well on near-lossless and lossless role.

guetzli and pik for high quality lossy(near-lossless), FLIF and FUIF for lossless. jpeg xl vardct lossy and modular lossy-palette for near-lossless jpeg xl modular lossless for lossless

I also agree that this is a bad idea, in my opinion it is better to defend full implementation by all means

Lossless also has no efficiency alternatives (even after changes in AVIF lossless), except that speed/efficiency is still worth some improvements (to be in most cases better and faster than WebP and PNG encoders), also lossy is better suited for Web or very large resolutions

For now only webp have near-lossless implement(and some lossy png implement), I think maybe we can change format position to near-lossless and keep full implementation, avoiding challenge avif lossy format position?

The way I see it, the main threat is that of inertia: people sticking to the old JPEG because 1) it just works everywhere, 2) it's fast to encode and decode, 3) it can do progressive, 4) it does a 'good enough' job for medium to high fidelity. What could happen is not that avif becomes the new codec of choice, or jxl becomes it, but people just stick to the old jpeg. What AVIF has to offer to dethrone JPEG is doing a great job at low fidelity (orders of magnitude better than what JPEG can do there) and doing significantly better than JPEG at medium fidelity (let's say "typical web quality"), and that it supports alpha and HDR. What JXL has to offer to dethrone JPEG is that it can also do 2) and 3) and is consistently significantly better than JPEG at all fidelity targets, and that it supports alpha and HDR. What neither of them has at this point though, is 1).

so the thing is that jpeg xl way of working can't be useful for photographic low fidelity

so you can't make a mode for that

but did you ever said chrome won't adopt jpeg xl

when chrome will adopt jpeg xl

they are waiting his development

to have better modes

we don't know that yet, likely jxl can be a lot better at high appeal low fidelity and it currently doesn't because that's not what the encoder has been tuned for so far

similarly maybe avif can also do a lot better at high fidelity, with better encoders

like even (basis compression) sometimes beats jxl

basis (compression)

is on squoosh

in the basis branch

i don't want jxl to reach those bitrates

but at least compression that sounds natural

like an aom mode

is even planned?

or an automatic thing

or will be disabled for some formats

like do you have a spoiler?

What do you mean?

what julia is doing

a different palette

or something interesting that could make jxl as aom even if worse because of different design

all kinds of things are possible, but I think at this point it's not that much about technical capabilities of codecs but more about the politics and the possibility that some AOM members would be annoyed to see Chrome support for JXL which they might see as a competitor for AVIF, and the Chrome team not wanting to annoy their long-term video compression technology partners.

Even if JXL would be consistently better than AVIF on all fronts, that wouldn't help for the political question, in fact it would only make it worse.

I think having browser support, even if it is behind a flag, is a great place to start. People that want to study jxl support can test it and see its merits. If they see value in jxl they will push for adoption. If they don't, then they won't use it, even if there is full browser support.

What I think will help a lot with adoption is having a decoder for Windows. The best way would be to have a Windows Imaging Component. So if https://github.com/mirillis/jpegxl-wic would provide also a release that would help. What would be even more helpful is if it would be included in the Microsoft Store. So when you double click on a jxl file Windows would popup a meessage that you need jxl support to open it and take you to the Microsoft store to install it.

mirillis makes paid softwares

He or someone else could provide a release.

The problem is that once a browser supports something, there's an implicit commitment that they'll keep supporting it. Removing support for something once it's used in the wild is a problem.

I'm not sure exactly who was developed the WIC-codec for WebP. But it became available in the libwebp releases repository very early on. Having the WIC-codec for JXL active, ideally from the developers of JXL itself, will allow Windows users to enable its support with just a couple of clicks. Many viewers support viewing images with WIC.

having a up to date JXL WIC codec would be really nice because I use windows photo viewer as my main image viewer and also I use paint.net as my main image editor and paint.net has a plugin for it that lets it decode any WIC codecs installed on the system

currently I am using the outdated mirillis codec to do stuff with JXL files which is not that ideal since it's based on a pretty old version of libjxl

there is this https://github.com/saschanaz/jxl-winthumb which exists but is pretty useless since it's just a thumbnailer and nothing else

the creator did show possible interest in making a WIC codec at some point though https://github.com/saschanaz/jxl-winthumb/issues/3

Yes, I also use apps that mostly decode different formats through WIC and this would be useful, except it requires a maintainer who has free time to do it and who also uses and knows Windows

imageglass is pretty fast.

just open imageglass and select and make it by default

it's based on very old version of jxl

but i didn't see high usage of ram

i saw 84 mb for many megapixels

more than 20

So maybe it would be worth it to re-open this issue (describing which applications are used and support WIC)? Because I'm not sure that in the near future someone from the Jpeg XL team will have time to create a WIC decoder

also the speed could change and encoder needs to be updated and supported

also decoder can implement new features

i think google people don't like what wb did

to create this server r/jxl art

my presence fabiorug

he talk about cloudinary everytime he mentions jxl

he is really convinced that browsers or fb will lead adoption to his modular softwares

yes an official plugin for windows 11 could be useful

but windows 11 isn't even presented

so that's the problem

why worry about, i guess jyrki and the devs know

Yes, JXL art poses great danger to Google.

r4ight

people hydolizing hell piano

or wwwqart

Yes, I'm pretty sure they pay him rather well.

i guess he will ban someone

if we can continue

he didn't find the invite, he even admitted that cloudinary found the call for proposal

in one of his video

found on xx

you know

don't understand this comment

so don't know if i need to agree

i got 19000 views for a jxl art

It's not just time — few of us use Windows and are familiar with it

windows 11

so in october call of proposal for plugin integration in windows 11

Yep (and so far afaik only spider-mario uses Windows) https://discord.com/channels/794206087879852103/803574970180829194/851439593978200094

in august windows 11 insider

september release

jxl in 2022

See, he doesn't even think about defending himself.

jxl will become the standard

<@!604964375924834314> ? 😄

I think also <@!806098177983643658>

I do think it would be good to spend some more effort on plugins and in general on making life easier for end-users

thing is, I use Windows kind of as if it were Linux

we've correctly spent a lot of effort on browsers so far, and I do think they are a major force in driving adoption of new codecs (they have short release cycles and better compression is very relevant for the web, so it's a natural target), but we should get more OS level support, image authoring tools support, viewer support, for example even just a simple open sourced Android demo viewer app could be useful to encourage others to also integrate libjxl in their Android apps

I don't understand the link between adoption of av1, and the choice to use avif format (which is fun for low bpp but not a real image format, and avif creator know that) Not using avif have zero impact of av1 future. AOM was not create for avif.

+GIF replacement: AV1/AVIF

Google map (and streetview) with progressive JXL would be awsome !

<@!532010383041363969> What about only dropping animation support for the first 6 months? That's quite a big compromise I would say.

I don't think splitting up the lossless/Jpeg recompression part and the lossy/animation part will be better for either side, it almost doesn't reduce the complexity and size of the decoder, because most lossy part is still needed for recompression Perhaps it would be better to promote the lossy compression much less for a while and focus on the other aspects (so as not to create competition for AVIF, but still have a full decoder)

I think we need to email many tech journalist to speak about the "revolutionary futuristic image codec" which is called the JXL 😄 I'm pretty shure the battle is on the public place. Geek are smart and will prefer jxl to avif 😄

Il will do it for Fance 😄

And also about different decoder variations and mime types, it might shorten the time to enable the initial implementation, but if we consider a more distant future and usability and user-friendliness for the next decades at least, it might not be the best solution (as well as there will be more arguments not to add lossy JXL at all, because there is already lossy AVIF and that is enough)

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

Adobe enters the room

↑ this is big! (they still haven’t added WebP!)

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

Posted on Firefox too

A bit of an odd one though... I don't think they even support WebP, do they?

https://memegenerator.net/img/instances/50299481/lets-get-ready-to-ruuuuumbleeeeeee.jpg

(btw, how do we know that they are actually from Adobe?)

Leonard Rosenthol (Lazerware) https://youtu.be/sJINedGixdo

The email is @adobe.com - I believe you have to verify it before you can post.

At least on Firefox. The Chrome was says lazerware which is odd.

send them the same photo of them compressed with JPEG XL and AVIF at 2 bpp and ask which one they'd like to see in their future 😄

I know Leonard from the JPEG committee, he's also behind PDF

This is actually a good proposal, I'll add it into the features to be discussed -- (however, I have no guarantees that proposing to drop something is a working strategy at all, it is just an idea)

Leonard told me they don't have WebP support in Photoshop because it's not a "proper standard"

(or in PDF for that matter)

What is meant by "proper standard"? I would think if it wasn't it wouldn't be supported by all browsers, other image editors, most image viewers...

Hopefully JXL support will be better than PNG (1bit transparency for years, still no sRGB chunk support etc). 😜

WebP is a Google format, like PSD is an Adobe format. Google defined the bitstream, Google could change it if they wanted to, there is no international standardization organization that has some kind of process, it's just a Google thing.

fb if it wants to have aom dedicate mode for jxl

what's the problem

likely users won't notice

and fb can execute clouds

they are not poor

Not that the WebP bitstream is going to change at this point, but initially it actually did: e.g. alpha, lossless, animation, color profiles were added later iirc, so for non-Google companies to add support for what can be a moving target is kind of risky

fb don't support screenshots

like it wants a specific ratio in images

Fabian you are very cryptic.

I think AV1 is an ISO standard, but isn't the bitstream not solidified as well?

like this photo can be made to 800 kb

without using d 3

reaching aom compression

this in a high quality jpg

AV1 is not an ISO standard, but it is created by an industry consortium (AOM) that includes quite a lot of different companies, so at least it is kind of standardized in that way.

The av1 bitstream was finalized 3 years ago

i want fb to use lossy

lossy jxl

with a dedicate mode only compression

like basis, aom

to hide jpg

make it seems photo that loses his vivacity

like original photo that weight 92 kb

even if the photo is reduced to 50 kb

....

i think jyrki said it don't want to do

AVIF however is something that does seem to be a bit of a moving target, and does get regular changes still ("version 1.0" is two years old, but they keep making changes so it appears to be a not very frozen thing)

because jxl is not designed in this way

so is risky

but personally do you consider this idea <@!794205442175402004>

Ah, I misread that. It is based on other standards. But I've seen a number of people claiming the bitstream could change so that is rather confusing.

to make a jpg photo smaller and more distorted

face etc

and making it look like original with filtering