JPEG XL

which is possible by defining a macro during compile

Unfortunately, I don't think the complicated build system is sophisticated enough at present to build a v6 and v8 version of the library at the same time.

I'll take a closer look at it later, I guess. If you need any help or suggestions writing a PKGBUILD I'm happy to help out.

I just hacked away on the libjxl one until I got this

commenting out the below should replace libjpeg sufficently enough ``` install -Dm644 "${srcdir}/build/tools/cjpegli" -t "${pkgdir}/usr/bin" install -Dm644 "${srcdir}/build/tools/djpegli" -t "${pkgdir}/usr/bin" ```

I made a few improvements to the libjxl pkgbuild. speeding it up by using system libraries and fetching less stuff in the thirdparty folder.

I think libjpeg could be added to the same pkgbuild as it's own split package with it's own package function. Just like libjxl-doc package.

Anyways, I think I really cleaned up the libjxl pkgbuild a lot.

I will add libjpeg as a split package on a later date.

I haven't shared the changes I made with anyone yet, however.

There's a lot of bureaucracy it looks like, to submit any patches or suggestions to the official packages, despite how poorly written most of the official pkgbuilds are

the aur simply does not have a package like that right now

by default I think the API level is set to 62

in the current build system

but this can be changed by redefining a macro during the build process

it looks like it actually does support api level 80

based on my examination of the code.

but, I am not an expert on the libjpeg API so there might be some unfinished parts

or some compatibility problems I mean

I would not be able to recognize that, if there was

not without studying the api more first

You can configure jpegli to output version 8, I do that on Arch so i can inject it into programs

although I don't have my pc atm to find the command

it was just a CMake config iirc

yeah, it would be nice if there was a libjpeg package

https://digitalfrontier.com/articles/jpeg-xl-avif-google-apple-safari-chrome-battle

<:PepeSad:815718285877444619>

[painpekora](https://cdn.discordapp.com/emojis/1074490715872170034.webp?size=48&quality=lossless&name=painpekora)

Jyrki already tweeted about it, but this blog post is honestly baffling.... https://hackaday.com/2024/04/07/jpegli-googles-better-jpeg-and-possible-death-knell-for-webp/

"based on AVIF" "a successor to JXL"

<:NotLikeThis:805132742819053610>

wtf

alléluia ! I found a nice comment : https://hackaday.com/2024/04/07/jpegli-googles-better-jpeg-and-possible-death-knell-for-webp/#comment-6748157

the rebutal which follows is fast, short and sharp 😄

the only advantage of QOI seems to be that script kiddies can understand the format in less than 1 hour

This article is so bad that it wouldn't even surprise me if it's AI generated lmfao

> a new encoder and decoder library that promises to be highly compatible with JPEG. it literally outputs JPEG files > Jpegli uses heuristics developed for JPEG XL, making it more of a JPEG XL successor (or improvement). > Jpegli incorporates advancements from AVIF how do you end up contradicting yourself within 5 sentences

"Based on the benchmarks from 2012 by [Blobfolio] between JPEG XL, AVIF and WebP" <:kekw:808717074305122316>

oh ffs not Blobfolio again

the link shows 2021, must be a typo here

Few sentences and not even noticing a typo like that is very disappointing

There are times like these that become really difficult to restrain my 2000's 2010's inner linus

And linking to an old article is also disappointing <:KekDog:884736660376535040>

My friend made a PNG decoder years ago thinking 'it can't be that hard' Now they just say no when I ask about JXL xD Although... They did make the DCT encoder in a screenspace Unity Shader the past week too.... (Yes it runs slow, but not as slow as you'd expect)

articles under that name could all be ai generated

researching subjects is dead... nowadays writers just rewrite each others' wrong first impressions until you end up with ridiculous generational loss after the 6th homework rewrite

no wonder though, news tend to be selfcontained and theres usually no points of contact for more information of any kind. no contact this email for more information, check for more on this central website, or need help integrating this in your software? contact this specific hotline - commercial support available too!

ai models are trained on ai generated content <:Stonks:806137886726553651>

spread misinformation <:Stonks:806137886726553651>

earliest coverage of jxl should ideally be seeded through partner media. this way early birds get rewarded for insideship and direct ecosystem's further commentary

<https://hackaday.com/author/mayaposch/>

wow hackaday is just garbage

so like a game of telephone?

fun, mostly unrelated (?) fact: a 2020 study found that in such a setup, autistic-only and non-autistic-only chains were similarly accurate, but mixed chains not as much: https://journals.sagepub.com/doi/10.1177/1362361320919286

> These results challenge the diagnostic criterion that autistic people lack the skills to interact successfully. Rather, autistic people effectively share information with each other. Information transfer selectively degrades more quickly in mixed pairs, in parallel with a reduction in rapport.

OS interoperability not natively supported

Who is blobfolio?

They write dumb stuff like this <:KekDog:884736660376535040> https://blobfolio.com/2021/jpeg-xl/

Oh lmao

That was on the first page of Google for a while

Their FLAC article is nice tho

What do they say about flac? No practical use whatsoever?

i sure do love storing raw pcm files on my disk with no compression and no metadata

there's an argument to be made for WavPack

Wavpak is cool but flac is faster...

and wider support

Yep

It's not bad though

It's cool

Says mr variable blocksize <:trolldoge:1200049081880432660>

true <:kekw:808717074305122316>

I mean it's in the spec, why don't everyone supports it? <:KekDog:805390049033191445>

Because they're allergic to max efficiency flac? <:KekDog:884736660376535040>

Yeah, that's why it's good for other formats to exist even if it's not immediately obvious right away why you would use it

It's a very nice codec even if flac is usually what you want instead

Or, you know, you can just convert it to 24 bit int, and lose nothing of value.

As long as you are careful to avoid clipping

Or any other mistakes during conversion

iirc, WavPack also supports more channels

Really? I understand flac supports a lot of channels

flac supports up to 8 channels

wavpack, up to 255

(a need for more than 8 channels might sound outlandish, but: https://github.com/google/tabuli )

I didn't realize only 8...

Yikes

and 32-bit fp flac just 32-bit int and only in the most recent version

Only 8 channels but you can always use a container format like matroska or ogg and use several separate flac streams

But that isn't the same thing exactly

Sounds like a severely limited format. But >99% of the time it's probably what you want

https://www.tomsguide.com/ai/ai-image-video/adobe-firefly-used-thousands-of-midjourney-images-in-training-its-ethical-ai-model

https://beebom.com/what-is-jpegli-explained/

What Does Jpegli Mean for the Web? Nothing. The web, for the most part, has adopted WebPs.

So, will the web start using Jpegli soon? No, because it has already adopted WebPs for the most part.

🤨

Those artwork websites I know even don't accept WebP

isn't jpegli better than webp

maybe only with xyb

Lossy WebP

And it can beat WebP without XYB

With XYB it is just worse than JXL at mid to high quality https://giannirosato.com/blog/post/jpegli-xyb/

Nobody uses webp

It's literally considered cursed by most people I have seen

Don't go near webp users or you might get what they have too

xD

Android uses 😔

many websites use webp !

The most popular term for WebP is generally "how to convert WebP to JPEG/PNG"

`dozens!!.gif`

Some local news websites use WebP too

Discord uses webp

like avif its almost exclusively a final delivery format served by CDNs - doomed to be completely abandoned in favour of the Next Big Thing unless you go with a futureproof workflow or keep your bloated originals forever

I have one friend who seems to exclusively get AVIF in google images, every single time they try to copy paste into discord I hear "What the hell is that!?" swiftly followed by deleting the message and saying nevermind

issue is really google webmasters tools, lighthouse and equivalent basically ordering webmasters to use those formats instead of incentivizing lower filesizes for images. if those were honest or at least vendor neutral the recommendations would not stress webmasters so frequently they turn their websites into apps and tell google search to shove it

yes some of the tools are really annoying, I remember them saying we're doing it wrong because we serve jpegs that can be 4:4:4 or 4:2:0 depending on what the image needs, and the google tool says you have to use 4:2:0 or you're bad at image optimization

which would be fine if it would be just a harmless tool giving bad advice, but webdevs take such tools quite seriously for a good reason when they come from Google: what the tools say could very well affect SEO, and SEO is critical

Web pee

I've seen Nintendo providing .jp2

https://youtube.com/shorts/MoaVS1gp8MQ?si=HsfqjCdOoS6g2vA0

Painful

<:you:1216046797211045998>

Why can't google just adopt jxl like Apple

some of the comments are even more painful

Only reasonable person

I'm so glad Apple is much bigger than Google, because it means Google will eventually be forced to adopt it

As much as I'm not a fan of Apple

These comments are so nice

I can very much see a reality where Google still does not adopt JPEG XL into chromium, I think Mozilla/Firefox will play a very big factor into things but sadly Mozilla doesn't care

Yeah it still stings so much they didn't even give it a chance

Chrome they must have had their reason, as flawed, terrible, unpopular and unreasonable it may be. I guess they really just want to keep webp or whatever

But Firefox has no excuse, it's so sad to see

wait do you know the full story of what happened with Chrome?

Nope

It's a bit much to type out but uhh basically: Chrome got fully featured complete support for JPEG XL but disabled by default, then a bunch of companies and other individuals both inside and outside the web space such as Adobe, Facebook, Intel, Shopify, and a few others come out on the issue page saying they want Chrome to enable support by default with some of them even saying that AVIF did not fit or work for their needs, then after that Chrome announced it was removing support for JPEG XL with a vague list of reasons that didn't make sense, then many people including some of the original companies wanting JPEG XL support came out and where confused about the removal, then after multiple months of nothing but silence from Chrome they decided to respond to the backlash with data and tests from "the AVIF team" saying it was the reason for the removal despite the data not seeming to have existed until the backlash and the data while not technically false was constructed and organized in such a way to try and make AVIF seem better then JPEG XL as a whole.

it seems to be almost entirely an issue of power with those having the final say being active participants in supporting or developing AVIF

chrome has ways for website to forcefully activate specific flags (so *websites* rather than *users* test features that are normally disabled by default - origin trials iinm) but this wasnt done for jxl thus feedback from real sites did not even exist. origin trials are available for firefox and edge too

https://developer.chrome.com/origintrials/#/trials/active

Isn't FLIF replaced by FUIF replaced by JPEG XL?

correct

avif works, flif is superseeded by jpeg xl, where is QOI?

They don't know it's quite ok

QOI is fast but barely efficient

it's essentially a filter on data to make it more compressible in byte oriented codecs

so the speed almost gets negated by the fact that you need a second compression step to get decent lossless rates

It's also fun that QOI can be compressed externally pretty well

Behind JPEG XL and WebP but better than PNG, AVIF, HEIC...

i can see QOI for data sets, so you can read and analyze them faster

QOI has insane speed:compression it's good enough that I was legitimately considering it as a lossless intermediate, but in the end went with EXR for a myraid of reasons, still looking forwards to JXL

QOI is simple, not fast, for equivalent compression levels jpegXL is faster 😄

is it? I've only experienced that when using `faster_decoding=3` which blows up the size a good chunk

according to this : https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front cjxl -d0 -e1 compresses twice better for a slightly higher speed for non photos

for photographic images it states : Not shown on the chart is QOI, which clocked in at 154 Mpx/s to achieve 17 bpp, which may be “quite OK” but is quite far from Pareto-optimal, considering the lowest effort setting of libjxl compresses down to 11.5 bpp at 427 Mpx/s (so it is 2.7 times as fast and the result is 32.5% smaller).

I guess cjxl makes a better use of threads

disregarding encode speed since I don't really care about that, the size difference of a music video ripped from youtube is ```ps ➜ Videos l | rg -i seq .rw-r--r-- 557M quack 1 May 14:20 unison-seq-jxl.nut .rw-r--r-- 1.2G quack 1 May 14:19 unison-seq-qoi.nut ``` which is a big win for jxl but the time difference```ps ➜ Videos time ffmpeg -hide_banner -loglevel error -i unison-seq-qoi.nut -f null /dev/null ffmpeg -hide_banner -loglevel error -i unison-seq-qoi.nut -f null /dev/null 15.63s user 0.64s system 866% cpu 1.878 total ➜ Videos time ffmpeg -hide_banner -loglevel error -i unison-seq-jxl.nut -f null /dev/null ffmpeg -hide_banner -loglevel error -i unison-seq-jxl.nut -f null /dev/null 117.78s user 9.42s system 815% cpu 15.605 total ```and inside mpv```ps ➜ Videos time mpv --profile=bench unison-seq-jxl.nut ... mpv --profile=bench unison-seq-jxl.nut 119.70s user 8.80s system 759% cpu 16.921 total ➜ Videos time mpv --profile=bench unison-seq-qoi.nut ... mpv --profile=bench unison-seq-qoi.nut 15.40s user 2.15s system 359% cpu 4.881 total ```

which is a massive difference, especially when you bring that into an NLE

ill encode the faster_decoding one now, it's a bit more annoying since ffmpeg doesnt support custom options

you mean the decoding speed, right? libjxl e1 is a rare case that encoding is *way* faster than decoding

encode speed is still slower then qoi, qoi is extremely fast encoding, this is encoding in ffmpeg ```ps ➜ Videos time ffmpeg -hide_banner -loglevel error -i unison.mkv -t 00:00:20 -c:v libjxl -distance 0 -effort 1 -f null /dev/null ffmpeg -hide_banner -loglevel error -i unison.mkv -t 00:00:20 -c:v libjxl 0 151.74s user 134.17s system 505% cpu 56.584 total ➜ Videos time ffmpeg -hide_banner -loglevel error -i unison.mkv -t 00:00:20 -c:v qoi -f null /dev/null ffmpeg -hide_banner -loglevel error -i unison.mkv -t 00:00:20 -c:v qoi -f nul 15.06s user 0.46s system 864% cpu 1.795 total ```

like: ```console $ cjxl -d 0 -e 1 ~/jxl/3_orig.png test.jxl JPEG XL encoder v0.10.2 4da4b9a2 [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 1] Compressed to 28629.2 kB (9.670 bpp). 5787 x 4093, 702.137 MP/s [702.14, 702.14], , 1 reps, 12 threads. $ djxl --disable_output test.jxl JPEG XL decoder v0.10.2 4da4b9a2 [AVX2,SSE4,SSE2] Decoded to pixels. 5787 x 4093, 197.895 MP/s [197.89, 197.89], , 1 reps, 12 threads. ```

results for faster_decoding=3 it is a lot faster then without it (it scales way better which I didn't show here for simultaneous decodes) but it's still not near qoi ```ps ➜ Videos time mpv --profile=bench unison-seq-jxl-fd.nut ... mpv --profile=bench unison-seq-jxl-fd.nut 65.15s user 12.69s system 543% cpu 14.331 total ➜ Videos time ffmpeg -hide_banner -loglevel error -i unison-seq-jxl-fd.nut -f null /dev/null ffmpeg -hide_banner -loglevel error -i unison-seq-jxl-fd.nut -f null /dev/nul 64.05s user 5.19s system 749% cpu 9.241 total ```

huh I just checked the size and faster_decoding is smaller lol ```ps .rw-r--r-- 554M quack 1 May 14:35 unison-seq-jxl-fd.nut .rw-r--r-- 557M quack 1 May 14:20 unison-seq-jxl.nut .rw-r--r-- 1.2G quack 1 May 14:19 unison-seq-qoi.nut ```

I was speaking of -e 1 encoding... can you set the effort with ffmpeg ?

it was encoded using `ffmpeg -i unison.mkv -t 00:00:40 -c:v libjxl -distance 0 -effort 1 unison-seq-jxl.nut`

my bad, I don't know why it's slow with ffmpeg... can't use threads ?

ffmpeg libjxl will use all threads availible

it's not slow "with ffmpeg" it's just plain slower, this is a for loop which is going to be slower, but you can see this still takes quite a while with djxl ```ps ➜ jxl-seq /usr/bin/time -p bash -c "for i in *.jxl; do djxl $i --disable_output 2&>1; done > /dev/null" real 32.13 user 103.41 sys 65.22 ```

962 frames/images

ah it's 900 frames/images I had a blank file and the first line of `l`

Need to know that QOI encoder uses one thread only

And the benchmark was tested with M3 Pro 12-core

In my experience, e1 encoding is faster with multithreading disabled.

https://vale.rocks/blog/JPEG_XL_And_Googles_War_Against_It

> Super fast encoding and decoding. > Resilient against generational loss. prove it

With gaborish turned off 😅

Gaborish is useful and has room for improvement, let's keep it

no

proof?

In some of my tests `--gaborish=0` on the same `-d` usually gives smaller file size, but more differences from the original according to butteraugli. So I guess it's not that simple.

proof there is room from improvement ? quotes from devs 😄 I don't slander 😝

proof it's useful

i have proof it's not

something other than the generation loss issue it causes?

It's a war between Mountain View and Zürich

America and especially California has some of the world record setting dumbest people on this planet, no slander :) I know this because I was born there and I'm currently there right now.

Why even care about generation loss beyond, let's say, 10 generations? I don't see any relevance beyond few generations of reencoding, as even something like 50 generations won't ever happen in practice.

Generation loss act like a magnifying glass on encoding errors, it is not the generation loss per see which is a huge problem but what it shows... Even if, meme might by screenshotted and encoded more than once 😅

Some image hosting services transcode images when you upload them. F.e., imgur. You upload an image and someone downloads it in 2nd gen. Then uploads it to their account - 3rd gen. And so on. If an image becomes popular, like some meme, it can degrade very noticeably.

I'd say *all* services with little exceptions

When a meme photo is shared across different platforms under different qualities

my main issue is the advertising

stop saying it's generation loss resilient

Possibly better than lossy WebP

https://m.youtube.com/watch?v=8zdSKzLvsGA it was

only when gaborish is off

any filtering is bad for generation loss, heavy filtering is even worse (which is what most video based codecs use) but good for hiding artifacts, blockiness, and such jxl at least has options to disable such things and uses not that much and not such strong filters, also lossy modular should be pretty resistant to generation loss

can you prove there is no ungaborish() function such as gaborish(ungaborish()) ~= identity ? 😄

It can be generation loss resilient. But it depends on the encoder. And I do think we should make the encoder do something better by default in this respect.

like disabling gaborish?

Yes, I understand that. We did something similar for testing studio audio equipment, coaxial studio speaker and measurement microphone in an anechoic chamber, same signal passed through many times. An issue with such an approach is that some types of artifacts will add up perfectly, while others will not, scaling differently in perceivability with every generation...

That situation is actually not tested here... It makes a potentially huge difference whether identical encoding settings are used each time or not...

gaborish love, let the haters hate

A real world example I found a few months ago

Maybe disabling it below some distance makes sense. But I think it's useful in the "main range" of distances (d1-d3). The current encoder side introduces too much generation loss though.

would it be a huge performance impact to use a 7x7 kernel for the GaborishInverse ?

and I can't find the forward gaborish coefficients 😅

no idea how much slower 7x7 would be compared to the current 5x5

classical deconvolution takes indeed more "space" than convolution...

currently the encoder is always either using no gaborish (when gaborish is turned off) or it is using the default gaborish (signaling the default weights for the decoder)

but other methods seems to exists like https://projet.liris.cnrs.fr/imagine/pub/proceedings/ECCV-2014/papers/8693/86930033.pdf

it would probably make sense to have gaborish weights proportional to the distance instead of using fixed ones like we do now

(i.e. at d3 you may want to do something stronger than at d0.3)

also

if I understand you apply gaborish on all pixels not only block boundaries ?

yes it's all over the image

but in particular also across group boundaries, justl ike epf — which matters to avoid subtle seams

the paper quoted above speak of deconvolutions kernels of up to 51 pixel wide for a simple gaussian 😄 their solution looks nice but hard to grasp

yeah, gaborish should be much weaker on higher qualities

also we don't really want dec_gaborish(enc_gaborish(image)) ~= image, we want dec_gaborish(dec(enc(enc_gaborish(image))) ~= image

which means that even if we keep using a fixed dec_gaborish for now, you may still want to do something distance-dependent in the enc_gaborish

as distance goes to 0, dec(enc) is supposed to go to the identity so for low distances enc_gaborish should aim to just approximate the inverse of dec_gaborish

but for higher distances, maybe something else works better

I see

The Gaborish War

https://news.ycombinator.com/item?id=40243203

What's his position?

the original article has some massive `wut` takes

it also presents information in a super bias way

PDF week stars today in tokyo (online attendance available). the imaging model and hdr-capable image formats will be discussed first thing in monday may 5 and 6

could be but not that i know of

> JpegXL team > Transfer the development to other people, you are not competent, the project is not moving forward and is infested with bugs. > You are useless and are committing sabotage (possibly paid) to implement this standard in everyday life. The standard was removed from the Chrome browser because of you, because of too long development and protracted work to eliminate bugs in the implementation. https://github.com/libjxl/libjxl/issues/3560 <:PepeHands:808829977608323112>

when its this kind if mental deficiency, block and ignore is best

Don't tell the person that WebP took 10 years to complete the implementation among all major web browsers

Also interesting that the issue is nothing to do with JPEG XL

Couldn't we delete it ? Well you might say he'll be back for more [⠀](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&quality=lossless&name=av1_Hmmm)

I've hidden the comment for being off-topic (it has nothing to do with the issue he is commenting on)

it's also not a very nice nor useful comment — if he knows "other people" who are "competent" and can make progress / fix bugs, they're welcome to join the effort.

That's the joy of open source, you *can't* transfer development when everyone already is a developer

I see him as someone having high expectations, which is nice, but not knowing how to behave, which is sad... If only he was competent, he would have contributed

somehow this comment is giving me flashbacks to the xz backdoor

regarding the issue itself, it's a 1-bit grayscale PNG

which may be relevant

Interesting. Another issue related to greyscale

I still wonder if the bad performance related to screentone is an issue

I think the awnser here is, it depends

If you try to use splines, see you in 10 years. If you just do an effort 1 lossless, see you after a week

no

vardct is fast enough, modular can be quite slow. whether it's complicated is... well, I think it's a relative thing. jxl has more features and complexity than, say jpeg1 or png, but no more complicated than avif imo

Nothing does

oh ive heard of the xdsopl guy before

strange to lump J2K and JXL together

J2K is used in the film industry but yeah other than that and medical imaging it doesnt see much use

+ DWT itself isnt slow, it's the coding of the DWT that can be slow. J2K does bitplane coding, and I looked at xdsopl's project and they do bitplane coding as well which is _slow_ but allows for 'exact file size'

I saw j2k in pdfs

interesting

in what way?

Yes, it's the bitplane coding with funky branchy conditional signaling that makes j2k slow / hard to simd. In the new HTJ2K they replaced that with some more sensible and parallelizeable entropy coding, and that's what gives all the speedups (and also a little bit worse density).

J2K is designed so encoders can easily produce a bitstream at any given bpp. That's convenient for testing in the traditional way (comparing images at given bpp points), but it is not something you want to do in most actual use cases.

The browser engines might not support it themselves but their pdf readers support jp2000. In the chrome ecosystem its through pdfium, in firefox and lther apps i presume pdf.js. all it means is no jp2 for websites as th render throu blink and gecko

yeah, jpeg 2000 support is mandated by the PDF spec (https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf#page=43)

creating PDFs from jpeg 2000 images is supported by https://pypi.org/project/img2pdf/

> For JPEG, JPEG2000, non-interlaced PNG and TIFF images with CCITT Group 4 encoded data, img2pdf directly embeds the image data into the PDF without re-encoding it. It thus treats the PDF format merely as a container format for the image data. In these cases, img2pdf only increases the filesize by the size of the PDF container (typically around 500 to 700 bytes). Since data is only copied and not re-encoded, img2pdf is also typically faster than other solutions for these input formats.

soon jxl in the pdf spec too ?

[⠀](https://cdn.discordapp.com/emojis/824558603179524106.webp?size=48&quality=lossless&name=pepepray)

The event ended a few days ago, but no word yet https://pdfa.org/pdf-week-tokyo-starts-may-6/

Its imo the only thing that makes sense, especially to bring into the future all pdf docs that used jpeg1 yet with guaranteed lower filesizes

Theres almost as many pdf readers in circulation as browsers or even more, even more ubiquitous as flash player once was

I have pdf with images with such encoding: <</ColorSpace/DeviceGray/BitsPerComponent 8/Width 2266/Length 162218/Height 1793/Intent/RelativeColorimetric/Subtype/Image/Name/X/Filter[/FlateDecode/JPXDecode]>> But it opens in ff ok, like in a standalone pdf viewer, images are present

WTF > **Request: Re-open JPEG XL issue** > Changed > status: New → Obsolete > > Status: Won't Fix (Obsolete) https://issues.chromium.org/issues/40270698

They really don't want JXL do they......

The new IE

and they aren't even explaining anything of why they did that

I mean, it is *technically* just a duplicate issue

This however https://issues.chromium.org/issues/40168998 >>> May 16, 2024 11:09AM Status: Assigned (reopened)

was just about to post that lol

Both got our emails enabled then

yeee buddy

Oh, well nevermind

aaand just after > Changed > status: Assigned → Obsolete > > eu...@chromium.org added comment #437: > Sorry for the noise. lol

xD

Closing duplicate spam issues is normal. Nothing wtf about.

Somewhat weird that the main issue got reopened and then closed again though, I wonder what that was about.

were you, jxl devs, ever contacted directly by the chromium dev team about this topic ?

not me, but I guess if they would contact someone, it would be one of the Google folks

it slashes hard on the bug tracker : _"I suggest concentrating efforts on improving libjxl and working towards a high quality 1.0 release. As someone who has used libjxl, I didn't find it production ready, which is likely why Google dropped it. Once it is stable and has good performance, they are more likely to consider adding it back in."_

comment then deleted

xD

afaik the only real issues with it as a library is it trying to off the entire program when it encounters an issue wasn't it?

for Chrome that means your tab crashes if libjxl aborts, as opposed to just showing a broken image icon — not the best thing to happen, but could be worse

don't browsers have separate media decoding processes these days anyway

I don't think Chrome does, maybe others do

anyway, the aborts thing was mostly a problem in the encoder, I think the decoder only aborts when it is OOM but that shouldn't really happen easily in the Chrome integration (which uses the pixel callback)

and the aborts thing is being fixed anyway

oh neat

> "As someone who has used libjxl, I didn't find it production ready" This person must have quite high standards. Apple and Adobe apparently consider it production ready (since they're putting it in their products), so I'm a bit curious what aspects of libjxl this person considers "not production ready".

different users have different needs

if you sandbox media decoding, aborts all over isn't a problem. if you don't, then all those aborts are a huge PITA.

Firefox apparently does for video and audio, but I think not for images.

(also, I think it's rather easy to have higher standards than Apple and Adobe considering how buggy their products can be 😅 )

AFAIU that was eustas@ having fat fingers 😛

(IIRC at some point every Google employee used to have also a @chromium address)

I was going to say the "eu*@chromium" reminded me of someone... But I didn't want to point the finger haha

That issue was a duplicate anyway. The original issue still have an open discussion.

Sure, but it's still a bit of a weird argument to say it's not "production ready" enough for Chrome while it apparently is for Safari. I don't think that's the reason why Chrome dropped it. In any case, libwebp and libavif were in a less production ready state imo than libjxl when they were enabled by default, than libjxl was when it was dropped. They both were still making spec changes to the format itself after they got into Chrome, for example.

another, major drawback of libwebp and libavif is that the formats they implement are, respectively, webp and avif

> I don't think that's the reason why Chrome dropped it. oh, certainly not. Especially with several libjxl devs being available for any problems they might run into.

Sorry, but it's not duplicate. Original issue was about adding JXL and closed because of low interest in ecosystem. That is basically end of discussion when issue is closed. I created the new issue to request reopen of the original issue/discussion because state of ecosystem changed and there was new interest which is good reason for renewed discussion. That is not duplicating.

But it looks like now they dont want to even keep the discussion open even if there is new interest. I wonder what "obsolete" mean in this context... Do they mean JXL is already obsolete? Or just that the issue is too old.

unsure but maybe checking other issues set as "obsolete" could give an idea?

ohh, i found something: **Won't Fix (Obsolete) The issue is no longer relevant due to changes in the product.** https://developers.google.com/issue-tracker/concepts/issues

let me guess... "we already have AVIF so we dont need JXL"

or : jxl can be decoded with a wasm, hence we don't need to implement it like a real format

Chrome saying JPEG XL is "no longer relevant" sounds like Bill Gates saying 640 KB of RAM ought to be enough for anyone. I don't think it will age well.

Ironically, I'm mostly waiting on Windows to release support

FWIW, he denies saying that https://www.wired.com/1997/01/did-gates-really-say-640k-is-enough-for-anyone/ > I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time. > […] > I keep bumping into that silly quotation attributed to me that says 640K of memory is enough. There's never a citation; the quotation just floats like a rumor, repeated again and again.

He may not have said those words, but the 640 KB limit was a real thing back in the DOS days: https://en.wikipedia.org/wiki/Conventional_memory

Bill Gates said a lot worse things unrelated to computers he ought to be more embarrassed about

"Codec Docs" and "Codec Resources" doesnt really "click" compared to the current name

but if you come up with something better, do let me know

"Your Guide to All Things Encoding" I would call it Codec Guide

why wouldn't it be called a wiki if it can't be anonymous, wiki's don't imply anonymity at all

"a website that allows visitors to make changes, contributions, or corrections" https://www.merriam-webster.com/dictionary/wiki "A wiki (/ˈwɪki/ ⓘ WI-kee) is a form of online hypertext publication that is collaboratively edited and managed by its own audience directly through a web browser." https://en.wikipedia.org/wiki/Wiki So, can I as visitor/audience edit Codec Wiki? Not really. I can only send pull request which is just request to change something which will be checked, corrected and maybe published by team of editors.

so the issue is changes needing verified, there are other wikis that do that too

a good chunk of fandom wikis

though I suppose you could implement some kind of poll bot to make it truly community managed

I think people are starting to confuse term "encyclopedia" with "wiki". Just because something is encyclopedia/docs/guide/resources, it doesnt means it's also a wiki. Only a specific type of encyclopedia is called wiki. And if some fandom sites call themselves wiki but not really working like wiki doesnt change what wiki is.

I genuinely don't use wikipedia outside of real basic stuff so I can't comment on that

On wikipedia it's exception used only when absolutely needed. On absolute majority of pages anyone can edit anything. You dont even need account.

at the very least, needing an account is still really common

Yeah, I guess if anyone can make account and start editing straight away it's still in spirit of what wiki means.

I don't think no verification is necessary for a wiki, in the end if managed by own audience is the core of the issue, just make it possible for other members to verify/vote

everyone disagrees that it is a wiki

give up

?

I just made account on Fandom.com and looks like some wikis are more "open" than others. Marvel wiki has everything semi-locked and you need to wait 4 days to be autoconfirmed and be able to edit. https://community.fandom.com/wiki/Help:User_rights#Autoconfirmed_users Horror wiki allows editing straight away.

But you could say that anyone can just wait a few days and then you can edit whatvever you want.

Problem is if you call wiki something where people just send suggestions and editor team decides what goes and what not. I could just create a site, where only I can edit and tell people to send me edits by email and I will pick what I like and publish it. That is definitely not a wiki.

This almost reminds me when Facebook and US courts tried to decide is Facebook is a platform or media publisher.

btw <https://www.rxddit.com/r/OutOfTheLoop/comments/14bbttq/whats_going_on_with_gaming_communities_moving/> https://youtu.be/qcfuA_UAz3I?t=145

well, in the end they could always just add an auto merge bot

If I remember correctly it was like this: platform: anyone can publish anything and if it violates rules it will be deleted after when someone reports it, Site is not responible for content of users media publisher: people send content to editors that decide if they publish it or not, Site it then responsible for content

but whatever, I dont really care it they rename themselves or not... it's just interesting discussion about meaning of word "wiki"

Wikis are Web 2.0.

the first wiki was launched in the 90s

wikis are web 1.0

A thing can exist before the term for a thing was invented. Google App Engine existed before "serverless" term was invented, but it IS serverless.

"Web 2.0 (also known as participative (or participatory)[1] web and social web)[2] refers to websites that emphasize user-generated content, ease of use, participatory culture and interoperability (i.e., compatibility with other products, systems, and devices) for end users. " by this definition wiki ARE a tool of the web 2.0

The earlier wiki, the easier to support image formats. I let my UseModWiki support JXL

firefox is doing an upcoming AMA on reddit to discuss how its shaped. maybe make some noise there about the jxl patches needing to be merged and jxl enabled out of the box in the developper and nightly editions

jxl support request had been trending for years on their ideas site and given the code already works efficiently and safely it could be a quick win for firefox mindshare

https://connect.mozilla.org/t5/discussions/here-s-what-we-re-working-on-in-firefox/td-p/57694

wow tabs and menus and AI and still 5 years behind in half of the css and js W3C standards

If the internet was 15 years behind in web standards it was a lot better

https://connect.mozilla.org/t5/ideas/idb-p/ideas/tab/most-kudoed

JPEG XL is the sixth most popular idea

I bet they will have the manpower only for 5 ideas.

you mean n-1 where n is the position of JXL

https://www.computerweekly.com/blog/CW-Developer-Network/Green-coding-Cloudinary-Could-a-JPEG-successor-render-greener

nice !

(mostly written by a ghost writer based on an earlier article I wrote myself: https://unthinking.photography/articles/history-and-environmental-impact-of-digital-image-formats — I reviewed it of course and changed some stuff, but you might notice that it's not fully my writing style)

Isn't it WebP? It does render greener and greener https://www.youtube.com/watch?v=w7UDJUCMTng

and as a consequence it uses only the green subpixels ! some energy again saved on OLED displays

Earlier versions of webp went pinker and pinker: https://www.youtube.com/watch?v=ujBp5B35el4

something must have had a bias towards rounding stuff up originally, and now has a bias towards rounding stuff down — pink is max value for Cb and Cr, green is min value for Cb and Cr...

Well, it's not true, you are just biased.

https://tenor.com/view/reply-ping-discord-thanos-gif-24654532

ok

mozilla leadership will be doing an AMA on reddit about the direction of firefox under the new ceo - *Thursday, June 13, 17:00 - 19:00 UTC*

anyone wanna signal boost interest in jpeg-xl patches updated and **enabled by default** in Nightly, Developper and eventually Stable and ESR edition or raise awareness of changes since 2022, https://old.reddit.com/r/firefox/

AMA is open. I guess you can start writing questions about JPEG XL 🙂 https://reddit.com/r/firefox/comments/1de7bu1/were_the_firefox_leadership_team_at_mozilla_ama/

We got answer https://www.reddit.com/r/firefox/s/i7S0Nmbsav

thats no answer. jxl is not [fad of current year] - avif doesnt even cover *existing* needs and is not futureproof. the smoking gun though is that like webp, avif is shipped almost exclusively by CDNs as smaller substitutes for the original images that are JPG and PNG - so both can be ditched anytime in fact, while JXL is futureproof and can losslessly replace all existing JPGs and still has guaranteed lower filesize

>>> As folks are probably aware, we took a neutral position on JXL several years ago. It appears to be a great format, but there's a very high and permanent cost to adding new formats to the Web Platform, and it wasn't clear that JXL was \_better enough\_ relative to existing formats to justify that cost. Over the years, people have been adamant that we add support for various hot new formats, including MNG, JPEG2k, and JPEG XR. We took a relatively conservative approach to each of those, which in retrospect was clearly the right decision. That said, we certainly don't find the format objectionable and it's not out of the question that we might decide to support it at some point in the future. We do periodically revisit our analysis on evolving technologies like this one, and are always open to changing our mind if the facts suggest we should.

additionally, all they need to do is let contributors update the current patches, even if they dont make if enabled by default on any official firefox release made by mozilla

they dont need to allow that

i can already do that

it's just that there's no point

anyone can make patches

why is jxl support bad in nightly then?

because they dont update it

they dont review and merge changes

because they dont want it

who's actively going out of their way blocking bug-free working patches known to work well without issue, leaving outdated code in the trunk

if it's not on the board, it is not going to be looked at

it's as simple as "there are better things to be working on" even if it is short

At this point Im just glad they even bothered to reply.

you have to remember they don't do it for free.

Maybe if JXL was written in Rust you could promote it as "memory safe image format" and that is popular these days 🙂

integration is a few days' of anyone's time as long as theyre not incompetent.

it doesnt matter at all

if it's not what management wants, it will get nothing

they get handed out working uptodate patches and neither review, discuss, let people discuss, engage with devs or anything - thats just putting roadblocks

it's not free to review

it costs a lot

everything of importance about jxl was already done by outsiders not mozilla's dime

them putting it in and having to manage it costs a lot

them getting someone to look at it for 10 minutes costs a ton

because it also means they're not looking at the other thing that they should be looking at

the ~~other~~ only solution is to pay them to change the priorities

like google does

hardly the blocker you may think it is then

jxl oxide is in rust tho

the bigger concern though is wether someone is actively trying to *prevent* jxl from being mainstreamed (for browsers at least)

that's obvious

ly not

it's simple economics here

investors pay for feature

feature is not jxl

looks like no jxl

im 99% sure they dont do whatever they want

in interop google zurich already offered to do the very best rust-based integrations for all browsers at their own dime

i presume with all necessary maintainance for as long as necessary

standard corporate setting

I still remember when Firefox was a community-oriented project. I miss those times.

like 15 years ago

regarding the reply, there was almost no demand for MNG, JP2 and JXR *anywhere*. for mozilla to claim otherwise is an attempt to imply jxl is a fad

all the replies are ai generated

no way would they get real responses

they didnt even do any evaluation then or since. its like their entire "position" is based on hearsay, not any kind of research

i guess thats expected when you lay off the engineers and promote the bluehaired activists

what are you talking about

their big layoffs were mostly outside of Firefox engineering...

and the activism is done by the Mozilla Foundation, which has a separate budget (from donations) from the Moz Corp that develops Firefox (mostly from Google)

think of it this way if they looked at this then they'd also have to look at all the other garbage and if they're adding other people's features left and right, it would be more of a bloated mess than it already is

but yeah nobody is going to pay for that

it costs like at least 1k for just a full evaluation of a feature

and that's with 1 person

I've certainly wasted lots of those

remember Mozilla hubs?

libjxl clearly works when compiled to wasm, but it's kind of big, and slow compared to native. The former is fixable if there's a CDN version multiple sites use. WebGPU is coming, how much could it help in decoding? It's a chicken and egg thing also. Apple did their part but can Wasm + WebGPU advance things from the web app implementation side?

I wonder when AVIF2 arrives if they will also claim that it has no significant benefits so they wont implement it. 😄

Even if native support appears one day, I bet it's going to be 8-bit and missing HDR and floating point, so a good implementation running in the JS sandbox would remain valuable.

doubt highly that Web GPU will be able to help whatsoever because it's, well, it's GPU.

GPU is very helpful for JPEG 2000, but not sure if WebGPU is or if it'd need CUDA-only features. JPEG XL I don't know anything about, to even guess if it applies. I'm just thinking that's one way to gain some speed lost when the code isn't running natively.

> WebGPU is coming, how much could it help in decoding? not much, the latency of shuffling data back and forth from the GPU is too high for single images.

Don't forget we're dealing with wasm, which is really slow, so there's a good chance it would actually help.

ofc assuming it works

Well, if the end of the decoding pipeline contains some steps the GPU can do, then it can also blit the result on screen. But if the CPU has to do something per pixel near the end, then it's a total non-starter.

do you happen to know typical Mpix/s numbers for WASM libjxl?

it was... ok, main issue is filling is locked by other wasm threads decoding

I'm getting about 2 megapixels per second of 16 bits per channel RGB data, with a single worker thread. It depends a lot on the encoder settings.

oof

i found jxl-oxide wasm to be very Fast. However, I haven't updated the standalone Java one and the one that Tirr has on his demo requires some other crap that makes it a little bit of a pain to deploy wherever.

What would be the first place to start looking, if I want to understand the jxl decode pipeline? I mean I'm in any case decoding jxl in Wasm and then reprojecting it in WebGL or WebGPU. I'd like to know if there's any steps (let's say XYB color transform or anything) that could be moved from Wasm to shader, then maybe profile them and see if there's anything worth the effort or not.

I replied something on Reddit: https://www.reddit.com/r/firefox/comments/1de7bu1/comment/l8h22m0/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button

They did lay off the entire codec team at Mozilla though (the Daala folks, nice people)

yeah

I also replied to this comment: https://www.reddit.com/r/firefox/comments/1de7bu1/comment/l8h74g0/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button

what's the status on abort() in libjxl?

in progress

https://github.com/libjxl/libjxl/pull/3639

Microsoft offered to pay more than Google. They refused.

Their whole argument seems be simply "AVIF got released a bit sooner than JPEG XL, so that's why we use it". Even though they were warned that JXL is coming, they were requested not to hurry and evaluate when both are ready.

Likely there are some hidden incentives from AOM. "If you add this, then you get a no royalties for those patents, discounts for those services, etc". When adoption is higher, they'll change to punitive tactic: "if you don't add this, your search result will be de-ranked, etc". Those things are not rare at all, they usually get aired to public when the court is investigating unrelated things.

odd is how google search, google images and googlebot dont support avif to this day. from some webmaster circle that videos with avif (?) thumbnails dont get crawled - sounds like a SEO visibility downgrade in fact

i think theyre under no illusion that jxl is unquestionably the better and more futureproof format. feels these schenaigans were meant to buy time for avif to hopefully get less bad and promote its most current code against outdated snapshots of jxl in tests designed to obtain numbers implying its the better format, with no consideration for what image quality they produce (iirc a jpg-tier mess in the low range noone should use in any scenario)

<@594623456415449088> you wanted an exemple of "if it's not 1.0 I won't touch it" kind of argument? 😅 Here you are https://discord.com/channels/794206087879852103/822105409312653333/1250918677168259163 ... it doesn't mean it is a good argument

Is it stable, tho? I remember thumbs plugin wasn't updated for a half-year due to changes in API.

> "The libjxl API is not going to change drastically. The decode API has been stable for quite a while now (2-3 years)." \- wb

There have been some functions where a deprecated (unused) argument has been removed from the signature in December 2023, which did require some applications to make some trivial fixes (remove the unused dummy argument from the function call). Other than that, I don't think there has been any change at all in the decode API in the last 3 years or so (since version 0.4, iirc), only additions.

No offence, but those are weasel words. It's either stable, or not stable.

sounds like a false dichotomy

it's possible for the decode API to be stable while e.g. the encode API isn't

I wonder if it's possible to write tests that use all public API in most possible ways and then test all commits to automatically count how many times it was broken per year

I guess tests need to be manually adjusted on breakage, so I guess only the first one will be found

Isn't that what the conformance tests kinda already do for every PR?

no

If API is only changed in backwards compatible way, for example by adding some new features, is it considered stable?

in the semver sense, yes

in that it would be 1.1 -> 1.2 and not 1.1 -> 2.0, right?

(or 1.1.4 -> 1.2.0 and not 1.1.4 -> 2.0.0, whatever)

(but also not 1.1.4 -> 1.1.5, because of the additions)

honestly I don't remember what the rules are for patch-level version bumps in semver

I think the rule of thumb I’d go by is that if someone wanted to rely on a specific API, they would want to point to a minor version in their requirements file rather than a patch version

i.e. they wouldn’t want to write that they require `libjxl>=1.1.5`

In semver, you are in principle allowed to making breaking changes in any 0.x.x version, i.e. applications should not assume the API is stable. Once you have a 1.0.0, then any breaking change requires bumping up the major version, any new functionality requires bumping up the minor version, and patch versions are only for bugfixes and other non-API-affecting changes.

In practice, we have stayed at 0.x for now to reserve the option of making breaking changes if those would turn out to be needed, but ever since version 0.3, we have considered the decode API stable in the sense that we have always avoided to make any breaking changes to it — a bunch of new things have been added (similar to minor version bumps in a stable API) but very few things have been broken. If you made a simple decoder that works with libjxl 0.3, then it should still work with the current libjxl — the only breaking changes afaik were the change in signature of `JxlDecoderGetColorAsEncodedProfile` and similar functions (where we had a redundant argument that was deprecated in 0.7 and removed in 0.9) and the removal of the `JXL_DEC_DC_IMAGE` event and functions (which I don't think any application was using anyway) in favor of a more general handling of progressive loading. We could have called version 0.3 version 1.0 and called it officially stable, but then we would have had to move to 2.0 by now and/or keep some things around that we'd prefer to remove.

Anyway, I think we will have a 0.11.0 soon that will not introduce any breaking changes, and I think it will have all the major things we wanted to have for 1.0. So maybe there will be a 0.11.1 and 0.11.2 to fix some more small bugs that might get discovered, and then we can have a 1.0 release and finally silence this argument that "libjxl is still experimental and has an unstable API", which I think hasn't been true since 0.4 but as long as we remain at 0.x people will see it like that.

in the end it's just firefox's typical braindead circular logic

*they said they dont want to add it because "it might need to be removed in the future" *they said that chrome not adopting may cause it to lead not having major adoption *they said they can remove codecs that arent adopted by all major browsers

if chrome does adopt it, it will become a staple and they need to support it anyways, if they dont adopt it, they could "remove it at any time"

Here's a real argument I made up just now: "our adopting it would make zero difference compared to what Chrome does, so if we add it and they don't, we're just wasting engineer hours, and if they adopt it, we have to adopt it anyway"

heres the thing, firefox still serves they claim 240 million users, this is still a significant number of users

I think I might call it something closer to kettle logic (https://www.logicallyfallacious.com/logicalfallacies/Kettle-Logic)

Yes, that's basically what's going on. Except that they're spending more time of highly-paid executives on coming up with excuses for not adding JXL support, than it would cost in engineer hours to accept the patches that were already tested in various firefox forks.

oh sorry, it's 179'000'000 users

They are also unwilling to remove it, either. So it's in a perpetual limbo of half-way implemented state. On one hand maybe it means that there's hope, on other hand, maybe they don't have enough resources even to remove it.

maybe little difference to jxl, arguably some difference to Firefox’s users (less loading time for high-quality images)

yes

Firefox is 33% of all browser engines. Together with Safari, it's 66%.

well there are still some niche ones out there [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

so maybe 32.999% xD

Exactly. If Chrome adds JXL support, Firefox will have to follow anyway. There will be people using JXL without fallback as soon as it works in Safari and Chrome. Firefox represents 2% of the traffic we see; while we will of course still ensure fallbacks, many web devs won't bother with that. If Chrome doesn't add JXL support, then the main objection of Firefox ("we will be stuck with it forever so we have to be extremely careful!") evidently does not hold.

I suppose what bothers me most about the Firefox position is that they pretend to have done their own independent assessment and came to an independent conclusion on the merits of JXL, while in reality I cannot see any evidence that they spent any time whatsoever on doing any kind of technical evaluation (as opposed to what they did back in the early days of webp). If they would just say "we have no time to make an informed decision, we will just do whatever Chrome does", that would be fine. But now they're effectively allowing Chrome devs to say "look, we're not the only ones who think JXL does not bring enough benefits", while I think Mozilla came to that position only because they believe Chrome's AVIF team (more than they believe basically anyone else who knows something about image formats).

my biggest issue is that firefox still pretends like it's some "community project" that actually cares about it's users

they dont

my question gave them the opportunity to make an honest and substantiated answer, they preferred to make a politically mangled excuse 😅 it's a fail

is u/IDUnavailable you?