JPEG XL

At the fidelity corresponding to mozjpeg q30 (and lower), typically clearly AVIF > JXL. At the fidelity corresponding to mozjpeg q50, typically AVIF = JXL. At the fidelity corresponding to mozjpeg q70 (and higher), typically clearly AVIF < JXL.

why jxl win thumb isn't updated <@!239702523559018497>

https://github.com/saschanaz/jxl-winthumb

Because fabian will update it.

Jxl works on Android Chrome canary now 🥰 with jxl flag on.

wasn't that the case for a while already?

oh, you mean on mobile?

Yes 🙂 i edit

Because there hasn't been any new tagged release from libjxl?

fair enough - I hope we can soon do an actual 0.4.0 release (which will not include encoder improvements etc, only recent decoder/fuzzing fixes), and also maybe a 0.5.0-alpha1 or something

firefox nighty alpha support when (currently it just draws that as white)

<@!794205442175402004> You should use `<wbr>` between the parts of the link.

feel free to make a pull request 🙂 https://github.com/libjxl/libjxl.github.io

I’m working on a image software and we will adopt jpegxl

Do you know if jpegxl has any rust bindings?

You can try this (not-so-official) Rust implementation by <@!179701849576833024>... https://github.com/libjxl/jxl-rs

...or an even-less-official Rust bindings to official libjxl library by <@!239702523559018497>. https://github.com/saschanaz/jxl-rs

I’ll work from this one. Thanks!

That's extremely incomplete though

Well I’ll complete the parts I need 🙂

I don’t think I’ll need bindings for the entire library anyway, just the most important portions

Yeah those are not there yet 😂

Obviously i will submit patches like I’ve been doing for other rust projects that I have been using

Do you need bindings or an actual rust implementation?

Just bindings

Maybe a actual rust implementation will come later but don’t have time for that right now

Then probably https://github.com/saschanaz/jxl-rs is what you need

Luca's project is trying to make a full rust implementation, but that will take a while

Chrome is quite a bit slow when decoding images with alpha. Lossy FHD with alpha feels like taking around a second to render. Will this get faster until the stable 93 release?

I hope so; I suspect some of the slowness is because alpha is done with the squeeze transform, which does add some decode complications

but maybe there's also some slow stuff going on to get the blending right

how long does it take to show an image like this? data:image/jxl;base64,/wr6HwGRCAYBAFAASzhBvO15IutBdUj+EWONJGEBgAA=

(that's also with squeeze but without alpha)

pretty fast. maybe almost as fast as a lossy FHD image without alpha.

ok then it's not squeeze that is the main problem

<@!768090355546587137> <@!604964375924834314> do you have an idea what makes images with alpha slow atm in chrome?

is it also slow with an equivalent PNG?

or let’s say, does a similar slowdown occur with an equivalent PNG vs. an opaque PNG

(to make sure that it’s not just PNG decoding in general that is slow)

No, PNG+alpha decodes what I would call instantly. JXL without alpha is quite fast, but not as snappy as PNG or WebP. JXL with alpha causes a noticeable lag.

in that case, I suppose it’s likely not the compositing either

is it slow in Chrome only or with `djxl` as well?

19.74 MP/s vs 11.53 MP/s

``` A:\>djxl a.jxl a.png JPEG XL decoder v0.3.7 [AVX2] Read 165603 compressed bytes. Decoded to pixels. 1920 x 1080, 19.74 MP/s [19.74, 19.74], 1 reps, 4 threads. Allocations: 352 (max bytes in use: 6.709487E+07) A:\>djxl b.jxl b.png JPEG XL decoder v0.3.7 [AVX2] Read 165829 compressed bytes. Decoded to pixels. 1920 x 1080, 11.53 MP/s [11.53, 11.53], 1 reps, 4 threads. Allocations: 392 (max bytes in use: 1.065569E+08) ```

ok, so I also screen-captured the command line. Maybe not totally accurate but between the "Read [...] bytes." and "Decoded to pixels." message lay a bit more than 100 ms for the no-alpha image and 300 ms for the opaque-alpha image.

So I guess it is mainly a performance problem with libjxl?

Just converted the image without alpha to lossless JXL and it is also slow to decode. So I guess modular mode needs support for hardware acceleration?

Modular is in general slower than vardct, and hardware will not help I'm afraid

Just wait until someone creates a cryptocurrency that involves decoding random jpeg-xl modular bitstreams. There will be optimized hardware for it in no time.

also what happened with facebook? is still interested in the collaboration?

Jxl NFTs.

It doesn't actually work.

Because difficulty of decoding is not uniform, people would at best just build hardware that can very efficiently decode a small subset of easy files, possibly with very arbitrary restrictions, and just grind to hit those cases.

Further, they'd optimize for massively parallel decoding, at possibly very high latency. Not what you actually want for production usage.

Look into what happened with ASICBOOST in Bitcoin.

There is a Japanese company looking into hardware encode/decode of jxl, but they're likely going to restrict themselves to a subset (simple modular with fixed MA tree, no patches, no splines, etc)

What would be the application?

I assume camera

There you care mostly about fast encode

And it's ok for an encoder to only use a subset of the codec

I'll know more after the next JPEG meeting

Ah, very cool.

Are you able to name the company?

probably better not

fair enough; I suppose we'll know in a couple years anyway

yeah, though there are only a few that I'd suspect are working on a JXL ASIC

if you google "jpeg ip core products" you'll probably get the company on the first page

I did not say camera company

I said Japanese company

I find a chinese language article introduction avif, quote Jon Sneyers youtube, > https://www.youtube.com/watch?v=w7UDJUCMTng and say<:NotLikeThis:805132742819053610> : > This is AVIF another victory. > https://www.techbang.com/posts/84971-jpeg-picture-format-avif

https://www.youtube.com/watch?v=FtSWpw7zNkI is a better comparison

JPEG can be quite good, there just is something wrong with what ImageMagick does, it seems

AVIF does not do great - it's not as bad as WebP, but it's certainly losing a lot even in 4:4:4, and certainly in 4:2:0

Agree, Hope jxl vardct can get better quality for anime(ligne claire) content.

first frame of that video - you can see the file sizes of the first generation, it's not like jxl is getting more bytes than the rest or something

generation 900

jxl does have plenty of issues after 900 generations too, especially of the yellow/blue kind

avif has significantly bigger issues though, especially in the 420 case

new encoder is better or worst in this?

haven't tested

was just responding to the chinese article that claims "another victory for AVIF" when it comes to generation loss

in practice, 4:2:0 AVIF is going to be most common, and generation loss there is very bad, almost WebP levels of bad.

the down-right bleed of chroma is very heavy

I think we need a chinese language wiki page.🤔

if its got the same magic as valid file, arguably its good enough for testing, i guess

Yes, presumably they don't care about it being valid

jxl is now enabled on the cloudinary.com website itself

for the f_auto images that are used there

we may have to update some marketing material

https://cloudinary-res.cloudinary.com/images/c_scale,w_400,dpr_2.0/f_auto,q_auto/v1601406451/website/refresh/media_management/cloudinary_web_media_management_loose_bytes_without_loosing_quality/cloudinary_web_media_management_loose_bytes_without_loosing_quality.png

for example the above url

will give you a jxl if you have enabled the enable-jxl flag

an avif otherwise

a webp if you're on a browser that doesn't have avif yet

or maybe a jpeg 2000 on safari

JPEG XR we don't do at all anymore (it's for internet explorer and really old versions of edge, not really relevant anymore)

and of course as a fallback for stupid browsers (mostly microbrowsers like what is in whatsapp, discord, slack etc) there's the good old JPEG

so they will update the image

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

the image is just to illustrate what f_auto does

will you update the image

with jpeg xl

I guess at some point they could update it with avif and jxl

when the quality is good

the image itself is a jxl though when you click "open original" and use a browser that supports jxl 🙂

currently we're just sending jxl to everyone who accepts jxl from the cloudinary website

our marketing people probably don't want to do the low-fidelity high-appeal thing where avif is better, that wouldn't really be a good idea for a website like this 🙂

how to know at which commit the decoder is

for jpeg xl in Mozilla and G.CHROME

Chrome follows the 0.4.x branch afaik

it'd be funny if they beat firefox to it

yeah doesn't seem like it's for me either

The new Proton UI in firefox is quite nice though 🔪

at least you can disable it

not for long

I use pale moon for some stuff, it’s better than people think. It’s just that sometimes websites are “chromesites” and don’t work in even Firefox

That’s by design. Pale moon is not a chrome replacement

It has a specifc use case for specific people

Some people have stuff that only work with old browsers (Flash, old extensions). In addition people with toaster computers might find it useful

https://twitter.com/jonsneyers/status/1410921825077501954 retweet!

_i_ measure my image codecs in acres of land ploughed per hour

i prefer my images unploughed

no avif tractor splashing muddy blur all over my pixels

😅

But for web, many people don't care about fidelity. They just need less artifact-y, low file size good appeal images.

sure

in some use cases

if the image is there just to make the site look less boring, fidelity doesn't matter and appeal is all that matters

if the image is e.g. a product you're selling, then fidelity does kind of matter - if you ruin the texture or color, you'll likely sell less and/or get more unsatisfied customers who return the product because it doesn't match the picture they saw

Some Ebook(manga) service also need high fidelity lossy compression to keep product quality.

in some cases, you can go down to very low fidelity as long as there's no annoying artifacts

but even for that, it's not q20

more like q50 or q60

Where’s me shiny new tractor…? 😉

Yes. Plus it’s more energy efficient,etc...

Chrome (93.0.4542.2) displays https://github.com/libjxl/conformance/blob/master/testcases/upsampling/ wrongly. Can someone check with a newer version or is this a known bug?

it's fixed in current git, but maybe the fix hasn't been cherry-picked into chrome?

https://www.newscientist.com/article/2282648-streamlined-jpeg-xl-images-could-cut-global-data-use-by-30-per-cent/

is even 30% of internet traffic images?

I think it's about a total traffic decrease

yeah but if total image traffic is less than 30% of total traffic, it's impossible for a new image format to reduce total traffic by 30%

Seems like a misinterpretation.

As far as I remember image traffic is about 60-70% (not including video)

Yeah, the stat is probably just ignoring video. I wonder what the original quote was.

I told the reporter that jxl is 50% smaller than jpeg and that images are 60% of the bytes of a median web page.

He turned it into that headline, which is not quite correct, but meh

The headline certainly seems to be garnering public attention, even if misleading.

<:JXL:805850130203934781> The Next Generation "Alien Technology From The Future"

I see the ISO table, we are in stage 50.00 for jpegxl 😄

Uh, i see that jxl is not default enable in chrome 93 ! They don't want? it's fully working for now? They are waiting for progressive decoding?

progressive decoding yes but also probably needs decision by higher-ups i guess

Avif is near everywhere !

Microsoft edge dev seem to prefer JXL !

why do you say that?

Because edge support now jxl with enable flag, that's not the case for avif.

oh. Weird - I would expect there at least to be a flag for avif in edge too...

likely there is

It just requires installed HEIF and AV1 extensions

in september what it will happen to jpeg xl

other than two tests by webp2 team

What do you say? I found no way to display avif file in edge and edge canary. (i have install microsoft store av1 and heif app)

Then I am mistaking with "fake" avif, when one AV1 frame was put into an MP4 container or something like that

Any chance jpeg xl will make it into the pixel 6? Would be amazing to have lossless + wide color gamut to take advantage of the display + camera system

though I guess it must be encoded / decoded in software, which is going to be too slow...?

No way. It's entirely too new to be used for image capture. Hardware support will be needed for that, which will take another two years, if it happens at all.

There is the possibility that djxl could make it in to Android 12 to provide decoding support in the OS and apps. I hope it does, since jxl can't be broadly useful without wide support, and if Google (which did the majority of development work on jxl) won't support it in their own OS and browser, why should anyone?

sigh. guess apple will remain the only company that supports wide color gamut 😦

pretty sure it can be done in GPU 😛

since jpeg xl parallelizes so well, it would work well on android's "many weak ARM cores" paradigm

That'd be nice, if so.

I was thinking about writing a fast GPU encoder at some point

probably if I write something the first implementation will use CUDA 'cause it's the only thing I know already

then I can figure out how to make it run on other stuff

IDK, but it's certainly easy to *write* CUDA programs

because it's basically C++

the most portable option is I think Compute Shaders

It could be a good idea to do that, but it would mostly be a PR thing. In practice, most Android apps ship their own decoders, even for libjpeg-turbo they often do not use the system library. The reason is simple: low-end Android devices are stuck at old Android versions, yet they need the decoder speedups the most that are in the most recent versions of decoders.

for 28 mpx images current decoder uses 1,3 gb of ram

too much

with jxl win thumb i get 800mb

djxl creates a full 32-bit float decoded buffer, so that alone is already 12 bytes per pixel in case of RGB, 16 bytes in case of RGBA. 28 megapixels -> 336 megabyte.

it should be able to not need significantly much more than that though, at least in the VarDCT case

in the Modular case there are still a few unnecessary copies

weird, I've just upgraded to firefox 90, enabled "image.jxl.enabled" and it doesn't work. otoh ` --enable-features=JXL` in edge works fine

vardct -d 1.17 -s 9 --use_new_heuristics or normal -s 9 -d 1 i used only those two commands

yes i used djxl libjxl v0.3.7-241-g89889a1 win_x64 2021.07.13

This doesn't belong to adoption

Fabian not only chooses parameters at random, he also chooses the channel to share them at a whim.

ive also tried to do animated jxl except that the api hasnt exposed all the headers for animation yet

i dont think there is an issue with transparency

it looked like it worked already (it works for me)

and idk anything about hdr. i will never understand hdr. it's not like firefox ever supported hdr in the first place

i open an image, right click inspect and change the background color

that's how i tested it

and it worked

doesn't work for me

hmm

ill look into it

yeah i get

image im testing with. on chromium it properly does transparent bg, in firefox it shows white there

black parts fully transparent

but white should be

that was an easy fix as described by kagami

though it's gotta wait for the qcms patch

it's more of it conflicts and it's easier this way

But I dunno how to enable chrome flags in electron/vscode, if that is even possible. 😄

Google contributed a lot to JXl but is still developping Webp2, I don't understand their goals

Google is big, besides jxl and webp2 they are also heavily into avif

They're big enough to just do everything so whichever wins they can say they made it :)

Google owns YouTube so it was in their interest to work on AV1. It was also in their interest to have AV1 be an image format because they have a lot of blogs that include images that are not major and that would work well for video screen captures in YouTube. While it does not seem they were all that interested in another image format, some of the compression techniques used in JXL are also being promoted for better generic/text & html compression. They are the web, after all. JXL just became a side project they didn't really expect, but since it uses their compression software, good for them. Since they also have a lot of image storage (Drive & Photos), it will just be an added plus in the long run to be able to improve compression on those media files for less storage & bandwidth.

Does anyone feel like adding jxl support to Blender? It already supports quite a few import/export formats (j2k, webp etc), and I think jxl would be a good codec for this use case.

It doesn't look like it would be very hard to do, basically grep the code for `WEBP` and do something similar

when support for cjxl in greenshot?

at least lossless

Ask greenshot developer?

<@!239702523559018497> There doesn't seem to be any activity on https://github.com/mozilla/standards-positions/issues/522 anymore, any idea how to make progress here?

how can facebook start with jxl

and permits to save other people photo as jxl

if windows 11 isn't out

windows 10 likely won't receive jxl

i think it can because it doesn't expire now

likely people don't have computer upgraded

so they have to download a viewer

and the viewer crashes when there is rotation metadata on a photo

and on android when you download a viewer that is not opensource you don't have libjxl

how support in the web will move? or in fb? do you have anticipations or spoiler, rumor

as i read the link up firefox still don't have upgraded decoder

latest is 25 may so 0.4.0

the support in open source is poor, greenshot can't save in jxl, qttabbar beta 17072021 can't show a jxl files bigger when you point the mouse

That's easy: Facebook doesn't care whether or not the user's operating system, much less third party apps, support JXL. All they need are for their own smartphone apps (which they fully control), and most web browsers (which would be the first things to adopt new image formats anyway) to support it.

yes but people shouldn't save ohter people image in jxl

if i want to download an image how i do in fb

if i'm on mobile

and it chooses another format for download a reconversion

jon sneyers probably knows

he can't spoiler

Why should Facebook care about people saving images? It's not a photo selling service

If fb adopt jxl, people will ask their favourite app's developers for jxl support. So I don't see any problem.

Firefox is irrelevant anyway 😆

>:c

It's bleeding users at an alarming pace

gecko > blink

will chrome 93 have jxl?

I don't think so. In market share, yes, they do have a problem. But it's the only other foss non-blink browser that has some market share (webkit itself is foss too but its only significant use is in safari).

i'm on firefox 90 stable, jxl enable, but it doesn't work, it's the same for you?

An i see OPERA 77 stable support JXL (with flags) 😍

Jxl is only in firefox nightly, not in stable builds

Why is there a flag when it only works in nightly anyway?

Perhaps because they are not sure if this format is worth including or the decoder is stable enough

well first it needs to get working properly

I've been trying very hard

also animated avif is still not supported in ff

decoder lib stuff is real concern as i think firefox didn't use 0.4 branch at all

now that it got 0.5 i guess it could be bumped

i think there have been lib size improvements incase only decoding part is used

i cant for the life of me get animated jxl working in firefox. i spent over 2 weeks on this already. i have to give up for now >.>

if anyone can help ill leave this here

i honestly cant bother lol

hmm.. is there even a point in animated avif when people are just going to use webm

i mean that avif is just av1 in avif container, so wouldnt people just do av1 in webm. there's no other way to get animated jxl so animated jxl kinda is required imo

Not if webm doesn't work in an img tag.

Are you stuck at some firefox thing, or at some libjxl thing?

I think it's some firefox thing. libjxl seems to be decoding properly

Did you look at how gif is done?

yeah i've especially stared at webp and apng

So what happens? Does it do anything?

I guess i should describe it.

All frames decode, but it crashes when it runs PostDecodeDone

actually that's it

Is there a way to get a backtrace or see why it crashes?

unfortunately i have no idea what i am doing when it comes to debugging firefox. there's no log for it for what it's worth

Have you tried running it in gdb?

so uhh i got it working

but these two test images <https://github.com/libjxl/conformance/blob/master/testcases/animation_newtons_cradle/input.jxl> <https://github.com/libjxl/conformance/blob/master/testcases/animation_spline/input.jxl> force firefox to do decode on demand (by default) which makes it really slow and it can't keep up with the framerates

Too many total pixels to keep all decoded frames in memory?

Or how does it work in ff?

yeah im guessing it's all decoded frames

decided here <https://searchfox.org/mozilla-central/source/image/AnimationSurfaceProvider.cpp#37>

I remember in chrome they had to spend some effort to make efficient seek work, maybe something similar has to be done in ff?

what it does is just restart from the beginning when it's done

and keep a buffer of frames

so when it needs the next one, which is always since it's a looping animation, the decode speed can't keep up with the framerate of the video

both of those images are just over the default threshold of 20mb assuming the images in memory are bitmaps in rgba8

your guys' care for this in ff pushed me to get this working so thanks.

next is progressive but ~~i dont think it's possible with how ff handles progressive~~ it is way too hard for me

Progressive is not even there yet in chrome, but I think it's less urgent (it's very nice to have, but it's not an interoperability problem if it doesn't work, only a perceived performance problem)

I'm not even 100% sure we have efficient animation in Chrome... at least in the beginning we just said "you cannot ever drop frames, sorry"

having said that, if we did put the efficient thing in Chrome then it should be relatively simple to do the same in FF, most of the work went in libjxl

... I'll ask <@!768090355546587137> tomorrow if I remember

Progressive support would also be nice, because it is one of the JXL advantages compared to other modern formats

See how progressive looks now in Chrome

We have per-group incremental loading in chrome, but not yet progressive loading.

dont know how i managed

i dragged the file into the box

instead of using the link

careful don't burn yourself out with this lol

haha spent all my time doing this instead of studying >.>

ooof these things can bite

i dont see the point in the olympics

:p

same

the olympics is the reason love live was delayed 2 weeks so i can only hate it

try to select 1kb step. For each step this tool generates a truncated image

cool tool 👍

Does it represent how progressive loading actually works in the browser? (when loading the full image)

yeah i tried using the built in FF network throttle

Very cool!

Is your patch going to end up in ff?

i hope, though i will wait for the efficient animation thing first

Kind of cool that ff might have good progressive jxl loading before chrome 😅

it helps that the api is so easy to use

... cool!

I'd suggest you to send the CL independently of the efficient animation stuff

(that requires updating to 0.5 among other things)

oh yeah i also need to figure out how title a patch to moz that covers multiple bugs

tbh probably the best way is to split the patch into multiple patches 😛

i guess ill do that then

This will make the animation more efficient in chrome. Just needs the latest jxl version merged https://chromium-review.googlesource.com/c/chromium/src/+/2953140

Lode, can we get progressive loading in chrome too? Would be nice if both firefox and chrome can have it before the flag gets enabled by default, then it's progressive "from the start".

what type of progressive do you mean? e.g. loading groups one by one, showing low res then high res, other forms of progressive...

Showing the upsampled DC if and when it is available, then groups as they arrive (which can be once per group or multiple times in case of progressive AC passes)

the upsampled DC is marked deprecated in the API. The showing of groups should already be supported, that is, chrome may show intermediate stages if the loading goes slow, and we render the groups to the final buffer as they get decoded EDIT: typo, meant downsampled DC

But we only render every pixel once, right? It would be nice to also show the upsampled DC (I assume there is a new way to get it besides the deprecated api?) for groups that aren't final yet, i.e. rendering every pixel twice.

why is it marked deprecated? getting DC sounds like handy feature

getting the *upsampled* DC, yes

getting the raw DC, not so much

it has a bunch of weird restrictions and problems

> the upsampled DC is marked deprecated in the API <:Thonk:805904896879493180>

that's a typo 😛

For some reason I do not see JXL LQIP at any load percentage 🤔 <https://stan-kondrat.github.io/progressive-image-viewer/>

Libjxl needs to get some fixes before we can do before-full-DC previews again (in case of dc frames)

<https://phabricator.services.mozilla.com/D119700#3977128> <:sadge:860304344771461130>

Is there anything we can do to help? If it's a matter of limited resources, is there a way we can add resources?

I am not sure, but I suspect that accepting a MR is not really a question of resources... I rather suspect there's politics involved

Oh ok, so the "limited resources" is just a polite way to say "no"?

"not right now". I guess reviewing takes time, and if no one gets assigned that...

kinda silly reasoning, but I guess that's what happens when project isn't community-ran but commercial

I think so, yes

I'm pretty sure time is not the issue, but IDK

perhaps.

<@239702523559018497> is here, I guess we can just ask: is it really about time/resources or is it a political thing?

in other news - I guess <@!693227044061839360> is the best person to bother about https://github.com/ImageMagick/ImageMagick/pull/4064 ? 😄

Yeah, hopefully it is just that they arnt going to do it until FF92 or something.

it seems the timing could be bad with AVIF support becoming default etc, so for the time being they're probably focused on getting that ready the foreseeable future could be making sure AVIF has a stable, successful bug free launch for enabling it by default I don't see a particular political reason to not support the format besides not impacting the release and success of another

Will take a look at the PR this weekend. Did a quick check and it looks like it requires some changes. I might use your PR as a template fro my own commit if it requires too many changes. Hope you don't mind.

Well, it's not my commit :D I'll ask

The 12-year olds on 4chan are overanalyzing stuff again: https://boards.4channel.org/g/thread/82921898/mozilla-is-prioritizing-avif-wont-merge-jpeg-xl

sigh, 4chan targeting the messenger saschanaz made jxl-rs and winthumb; it's pretty clear there's more to this decision than one individual

Ye.. I mean.. this summarizes the intellect of 4chan discussions I guess. Bash the messenger on a personal level. Ugh

Q: “Why am I not surprised?” A: because it’s relatively common for people to have they/them as their pronouns

I'll never get why people think it's an issue or a bad thing when people want to be addressed as they/them and then proceed to make fun of them <:sadge:855476349686513714>

tbh you can say the same about the opposite, why it's a bad thing when people dont address you as you like

Oh please, I didn't want to start a gender discussion 😛

do i really have to answer this...

if someone asks to be referred to in a certain way why tf would you not honor that?

I don't think anyone should continue this discussion, because I have seen too much good arguments for both sides

it's kinda stuff i just don't really wanna in jxl server too lol

I'll +1 that and ask that at the very least such discussions happen in <#806898911091753051> - and that it is kept civil if it does happen

Did not realize that without this patch version 0.5 will fail to encode the image <@!179701849576833024>. Applied a slightly different patch to fix this.

Perfect, can you link it?

Sure: https://github.com/ImageMagick/ImageMagick/commit/7fb6eda2c0ce209bacdc38d1c88c4a7d26125322. Now trying to figure out why 32 bit float encoding is broken. Using the exact same code as `encode_oneshot.cc` but colors are washed-out for some unknown reason.

sounds like a linear-vs-srgb issue... good luck 😄

Using `JxlColorEncodingSetToLinearSRGB` instead seems to fix the issue. But also getting `enc_modular.cc:506: JXL_ASSERT: !fp` with lossless compression

mhhhh, that ought not to happen, the assert is triggered by jxl trying to do an XYB conversion which definitely doesn't make sense with fp

can you open an issue?

Trying to figure out why it is happening 😁. Want a bit more info before opening the issue first

for reasons I don't really understand RN it's because JXL is convinced it needs to do both lossless fp *and* XYB

I think it's because xyb is an image-global decision while lossless is a frame decision

Doing this inside `JxlEncoderSetBasicInfo` seems to fix this issue: ``` enc->metadata.m.xyb_encoded = !info->uses_original_profile; if (enc->metadata.m.bit_depth.floating_point_sample) enc->metadata.m.xyb_encoded = false; enc->basic_info_set = true; ```

That's probably not a proper fix though

I think it's a good idea to file a bug

at this point

I am not knowledgeable enough about the encode API to be able to tell you anything useful here 😛

Will do I also think I know what is causing it

I don't know enough about the format but is correct that a 32 fp encoded image should not use `xyb` encoding?

Not if you want to do lossless

I mean, you can do whatever you want, but if you want lossless 32 bit floats, you ought not to use xyb

Thanks. I noticed that the libjxl an "old issue form". You probably want to switch to issue forms when this becomes available: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms

There you go: https://github.com/libjxl/libjxl/issues/447

thanks!

Firefox 91.0.1, image.jxl.enabled = true and it still doesn't render jxls. Any ideas? 😕

I hope it's not the case that the option is already there but the actual support not yet… 😜

just uhh use my patch

the flag only works on firefox nightly

Oh, I've just found it: https://discord.com/channels/794206087879852103/803574970180829194/864517617322295337

I hope that not too many users are confused with it…

How can we install your patch?

ill uhh set something up

I *could* make some builds perhaps... 😛

is that something like FlatPak?

anyway, it's probably a bit too much effort for me rn

it doesn't really, does it? well now it does if you enable a flag, but once the flag is enabled by default in a browser, the different Accept header doesn't give any extra fingerprinting besides what can already be derived from the User agent

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

* Photo sharing and storage. Vast majority of digital cameras generate JPG which can be losslessly transcoded to JXL. Photographers can share photos at the same image quality with reduced file sizes or same file sizes with improved image quality. * Format intermediary 1. TIF and PNG are often used in image editing workflows because they support higher bit depths. They are very large and can be slow to write. * Format intermediary 2. User and developer time is valuable. JXL is much much faster to encode (than AVIF). Web devs could upload JXL. Then the server could transcode to other formats over a longer period of time, if it's even still desired. * JPG replacement 1. With lossless transcoding, every JPG made during the last few decades is a potential JXL. * JPG replacement 2. Lots of existing websites still serve only JPGs, which could be transparently transcoded to save storage and bandwidth. For older browsers that don't natively support JXL, it's conceivable that a javascript loader could be used to decode images on the client side. * AVIF replacement 1. Even though AVIF is considered more effecient at low bitrates, it is very very slow to encode. On my computer, it takes 26x as long to encode a 24mp image into a 2MB AVIF as to a 2MB JXL (d=1). This translates to reduced carbon emissions, better battery life, etc. Maybe AVIF will get hardware acceleration, but so could JXL. * AVIF replacement 2. Users seem to be uploading larger images. (Based on the MB of bandwidth usage required to view what I think should be simple sites.) So I don't think many people are *really* putting a lot of effort into optimizing image sizes. If they are, they're doing really poorly at it. For images with the bpp that I've seen lately on the web, JXL does just as well as AVIF. (I see no significant visual difference when flipping between the formats in a viewer.)

Best practice for websites... just use JXL directly. It looks like every major browser is set to have JXL support as soon as it completes standardization. Maybe everyone still using Internet Explorer and Edge "Legacy" will finally upgrade.

Both options are also possible for jxl.

Nice list!

Best practice right now is not to just use jxl and only jxl, because that will show a broken image in 99.9999% of the end-users who don't enable experimental flags. Once jxl is in all major browsers, you could do that. For now, you'll have to use a fallback (e.g. jpeg or webp), and either use picture/source in html or let the server serve different files depending on Accept headers

Yes, for now. I was describing a scenario for after the standardization process has concluded. So many browsers already have experimental support implemented. They could set a compiler flag and have it in stable builds within hours. Right now, web sites could use it behind the scenes for image storage if they wanted. I look forward to when Google Photos supports JXL. What makes JXL significantly different from previous attempts at dethroning JPG is lossless transcoding. It answers, "What do I do with all my existing photos?"

Yes, it can actually replace jpeg and not just be a format you can lossily transcode existing jpegs to while still having to keep the originals if you care about generation loss.

It's also the first codec that can actually replace png.

WebP cannot because it can only do 8-bit. FLIF cannot because it is inherently slow. JXL can do everything PNG can do (and a lot more).

https://github.com/deckerst/aves/issues/56

I don't think image viewer apps should necessarily rely on Android doing the decode — maybe they do, but it's probably not a good idea.

Reason is that it will take many years before you can assume that all Android devices will have support for modern codecs like avif and jxl

(at the Android system level I mean)

avif support is planned for Android 12, jxl support is not even planned yet

if you rely on android system doing the decode, even webp isn't really supported on all android devices out there yet

Lossy webp was added in Android 4.0, lossless and alpha was added in Android 4.3

animated webp is afaik not supported at the android system level yet, it will show the first frame only

afaik

The point is: suppose avif support does indeed get added in Android 12, and suppose optimistically that jxl gets added in Android 13. When do you expect that a viewer app that just relies on Android system decoding can claim it supports these formats, knowing that there's such a long tail of devices running old Android versions?

WebP was 'finalized' in 2012 (the first webp was from 2010 but that was lossy still only)

WebP support was added to Android immediately

Yet today there are still 1% or so of Android devices that do not (propertly) support WebP

which on 3 billion Android devices would be about 30 million devices

In this context it might be interesting to mention that Fairphone 3 (which I also carry in my pocket) has at least 5 major Android updates guaranteed, so keeping this device for a long time shouldn't be a stop sign for modern formats.

that's nice but I think it's pretty exceptional

unfortunately, the situation in android is similar to that of windows: apps basically have to package their dependencies too, they cannot really depend on system-level libraries

my Sony XZ2 Compact stopped receiving even security updates, not two years after I bought it 🙄

https://www.aosmark.com/ has the track record for various manufacturers

most are not like that <:kekw:808717074305122316>

samsung generally only does 2 on their flagship s and note series and less on the cheap phones

but i heard that their newer phones are expected to get 3 now

I know. But it's getting better. EU has big plans with repairability of devices. And in France it was already launched.

is the data / source code publically viewable? on some older devices the data is a bit messy

oh, yes, they recently committed to four years of security updates and three android versions for some models https://security.samsungmobile.com/workScope.smsb > And select devices launched in 2019 or later will be supported with firmware security updates for a minimum of four (4) years following their global launch.¹ https://news.samsung.com/global/samsung-raises-the-bar-for-mobile-experience-innovation-committing-to-three-generations-of-android-os-upgrades > Samsung Electronics reinforced its commitment to offering the best mobile experiences possible for Galaxy users by supporting for three generations of Android operating system (OS) upgrades on millions of Galaxy devices1.

wow finally jxl in geeqie works

actually could be because of my recent PRs because I don't see anything else what could've made it work from earlier commits

feels comfy

or.. oh they integrated it into git version and i was using that

https://github.com/BestImageViewer/geeqie/blob/master/src/image_load_jpegxl.c

after https://github.com/libjxl/libjxl/pull/529 goes in, eog should support animated JXL 🙂

Animated jxl images seems to work in _qimgv_ after this https://github.com/easymodo/qimgv/pull/327 w/ qt plugin

kiwi browser has jxl but no adblock

Hmm, I built the latest `libjxl`, `qimgv` and `qt-jpegxl-image-plugin` with `msys2/mingw64` for win. Animated jxl doesn't work.

But it works with `QuickViewer`, even though the animation is slowed down.

Couldn't get it to work either with `mingw64`, it seems to be because of a mime-type mismatch 🥲 But luckily easymodo somehow managed to make it work https://github.com/easymodo/qimgv/pull/328#issuecomment-912741012

Yep, just copy `mingw64/share/mime` folder into folder with `qimgv.exe`

Hehe, boi! It works. But slightly slower than the same animated webp/gif.

https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html

I dunno what a good criterion is there, but I'd say there is "OS-level support" if in a default install, it's supported out of the box (you can just click on a jxl and it gets shown). It would be useful to also list distros that have the package in their main/stable repo, so you can install it easily.

what is the support for jxl in windows 11?

i think it's not waiting another year only for jxl

and i should not install any plugins

windows 11 is easy to break

also i read photos app when you cut the photo it saves as jpg

is really true

I have no idea if and how Microsoft and Apple can be encouraged to add jxl support to their OS

the problem is at least first year of having computer i don't want to bork install external plugins

i can wait another year until october 2022 and i prefer that

is worth it

do you think microsoft is trustworthy

or me as client i should trust microsoft

but is useless

at least i can format

or do backup

I haven't used Microsoft Windows since I stopped using Windows NT 4.0 in 1998

Well, nobody seems to have asked, so it doesn't seem like there's any demand...

I assume it is just as supported as in Windows 10.

I spoke with the FFmpeg team and they'd be happy to accept a wrapper for libjxl in libavformat/libavcodec

It's not there because it's in "patches welcome" territory

I might be able to throw one together this weekend

I mentioned added jpegxl support via libjxl and they suggested I write my own decoder according to the spec, since they like having internal decoders in libavcodec, but it's really outside the scope of my skill level

but since an internal decoder could be added later and coexist with the libjxl one there's no issue

It could be something like WebP support, although if JXL is planned as a very long term format, it might be nice to have its own internal ffmpeg codec implementation in the future (although this cannot be prioritized in any way if there is no interest from people who can do such a thing)

yeah that might take a while 😛

well

I mentioned that it was outside the scope of my skills

and I was told "it's a good exercise but you can always do it later."

and was pointed to libopenjpeg2000, which has both an encoder/decoder, next to their internal openjpeg2000 decoder added later

makes sense

I doubt a single person can write a JXL decoder in less than a year, except perhaps if already very familiar with the codebase

i doubt that it's that hard, but making it performant may take additional time. not that i would want to test that

was actually thinking making one in golang but my regular job eats too much time for me to attempt that

now this is based

oh no, for now I think cjxl d 1 e7 still not enough reach transparency quality for anime content...

that's for scans

Yep, not always enough to be visually lossless, but I think if the choice is between Jpeg and JXL, that would also be better

i mean in case of scans what you're getting aint lossless either way

But still, after some cleaning it would compress quite well in lossless and also any lossy compression will add more losses and artifacts

uhh you're not supposed to do cleaning on scans, that usually ends up kinda ugly

If it is done correctly and if the content is suitable, it is possible to achieve good results very close to what it would have been in the digital format as it originally was, still some digital publications and even animations are drawn by hand and then converted to digital format (but yes, that still doesn't mean there can be poor quality scans)

I think jxl vardct really need separate option for non-photo content, for now I can find specific image have some surprise, but I believe jxl can make better. avif also a strong encoder, I understand avif have some detail,grain issue, but av1 have local palette, this feature can handle some non-DCT situation.

jxl has more powerful palette options than av1, but (partially because it is more powerful) we don't have an encoder yet that actually explores such options

in av1 it's just a per-block decision to use palette mode or not, and the encoder is trying different block types anyway so it's just one more to try, maybe with a few options in how many palette colors to use (but the spec only allows 8 shades of each channel, so there's not a lot to try there)

in jxl we have a much more expressive modular mode and modular-encoded patches can be applied to any location (doesn't have to coincide with blocks), but atm we're only using it in very specific cases (solid background in the neighborhood and the patch has at least 2 occurrences)

is it going to have a way to only add cli options? I'd personally prefer it that way

I mean, having a way to only add commands in a text box instead of choosing the options in the gui

Would it make sense to define a syntax for encode parameter setting and have an API function to set params that way?