JPEG XL

This seems to be machine translated. "Krita" comes out as "Chalk", which is really funny.

Yes, I assume it was. Also "Version 2022 was released in September 0.7" 🤪

https://mhloppy.com/2023/01/2022-pc-nas-upgrade-bonus-next-gen-image-formats-jpeg-xl-avif/

https://github.com/AOMediaCodec/libavif/pull/761

from mentioned there https://www.reddit.com/r/AV1/comments/yqed62/how_to_create_progressive_avif_images/

I made that diagram and used it in both the white paper and that cloudinary blog post

Jon, dumb question, what languages do you speak? I assume english and dutch, maybe french?

Yes, native Dutch, second language French, third language English (more fluent in English than in French now though), some notions of German.

belgium is at the center of europe and europe a multi lingual place !

🎵 Another guide bites the dust... 🎵 https://gist.github.com/ziemek99/6295222469218427bb160cf849cdaa0c

TL;DR: now it just redirects to Thorium lol

https://blobfolio.com/2021/jpeg-xl/

What a useless, poorly-written article full of junk & misleading graphs

>2021

the author later on wrote a GUI tool for compressing images to JXL, as well as AVIF and WEBP

So maybe he changed his mind

Although, you have to edit the source code and recompile if you want to use different speed/effort settings

It is hardcoded to use the slowest settings even though it doesn't really make much difference

I tested it out and compiled it

after commenting out the effort settings in the source code of course.

:)

by the way, I know that <@794205442175402004> already said this and covered this extensively, but it is just... surreal, to look over the results of the AVIF team's comparison, and see JXL dominating AVIF according to their own data, at bitrates higher than 0.5bpp

They have multiple graphs, of avif vs jxl, at multiple different speed/effort settings, single core and multi core, and JXL consistently shreds AVIF in all of their own graphs

Here's AVIF vs itself at default vs slowest speed:

https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-avif_t-1_avif-s0_avif-s6_ssimulacra2__bpp-0.1-3.0.png

8 threads, slowest speed, AVIF vs JXL:

https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-8_avif-s0_jxl-s9_ssimulacra2__bpp-0.1-3.0.png

Same at default speeds:

https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-8_avif-s6_jxl-s7_ssimulacra2__bpp-0.1-3.0.png

single core comparison looks identical: https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-1_avif-s0_jxl-s9_ssimulacra2__bpp-0.1-3.0.png https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-1_avif-s6_jxl-s7_ssimulacra2__bpp-0.1-3.0.png

These graphs are all on their comparison page, you just have to click the percentage numbers that only show the average bd-rate... after averaging in useless values at the extremes

And buried with a bunch of useless metrics like PSNR

Their own test is a self-own

https://cloudfour.com/thinks/on-container-queries-responsive-images-and-jpeg-xl/

did they provide any info on their image dataset?

Yes

They had 3 datasets

two normal datasets and one bizarre and unusual dataset consisting of vector emojis that have been rasterized and had the alpha channel removed and replaced with a pure black background.

On all 3 datasets JXL outperforms AVIF at bitrates above 0.5bpp

Some of these test images are really good, my eyes hurt from looking at them lol

I love how JPEG XL is the elephant in the room in that header picture 🙂

(reminds me of https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/8zzn4E39BgAJ)

I actually still prefer something like lazysizes.js for responsive images over native because it calculates the sizes attribute automatically. doing that by hand is a maintainability nightmare

yeah, it slows down the initial loading but you can use native image tag for the LCP image if you care so much about metrics

looks like they might be adding it natively to browsers some day https://github.com/whatwg/html/issues/4654

👍

Waiting for layout to responsively load below-the-fold images is kind of a no-brainer, except for the JS dependency. Above the fold is full of tradeoffs (bytes vs time vs complexity). The core idea here is that progressive loading/rendering COULD allow you to extract some more time AND bytes, via two-stage loading; e.g. preload the 1/8 preview before layout, measure the target width directly after layout, and then load up to the quarter, half, or full if you need it. This is POC-able with plain old progressive JPEG + a service worker and some client-side JS. But PJPEG doesn't perform very well (the partial files are huge). I expect JXL will be better? https://codepen.io/eeeps/project/editor/ZdGzya

indeed, it will be a win-win situation to have a workflow which download only a part of a jpegxl for preview, because the part already downloaded is a part we won't need to download again when the full image is requested ! This is pure magic 🙂

https://tonisagrista.com/blog/2023/jpegxl-vs-avif/

why do they say that avif is limited to 3840x2160?? i'm pretty sure it can go a bit higher then that

they also say that avif has progressive decoding

Avif baseline profile is limited to 8k

> If you are browsing this page around 2023, chances are that your browser supports AVIF but does not support JPEG XL. Well it's the opposite for me. JPEG-XL is supported but not AVIF :P

Avif? Progressive? I hope they'll never merge the humongous patch which enables this 😬

practicality has never been an obstacle so far

https://www.youtube.com/live/u68rAnHLeSE?feature=share starting at around 4:18

*4:18:00, almost ended up watching a few hours extra of presentations haha

Shame he got cut off at the end, but to summarise: He works at Google, thinks JPEG XL is amazing, but it has 0 support anywhere and wants that to change.

Hm.. he said PNG came along 15 years ago... isn't it much older than that

Yeah, it's from 1996 or so iirc

I remembered how png was created in quite a short amount of time after Unisys threatened to charge royalties for GIF (which was then the main web format for non-photo still images)

I don't know why he would say 15 years, maybe that's for APNG?

In the same slide he says how APNG wasn't around yet and said he'd get to that, presumably in the part he had to skip at the end

Might be a typo/miscalculation, I think it's 25 years old now, not 15

Actually 26 years already, hm

PNG is a full grown adult with a perspective job now not a high-school student 🙂

way to feel old: “2013 was 10 years ago”

(or: “10 years ago means 2013”)

Way to feel old for me: I remember when jpeg, png and mp3 were new codecs

I even remember the first mp3 I downloaded... After 5 tries over a 33.6kbps connexion 😅

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

the comments on this post, oh boy

The first comment is just too funny for me not to post in PCJ lol https://old.reddit.com/r/programmingcirclejerk/comments/11jm1gj/im_not_okay_with_this_because_its_author_cherry/

Well, the fact that AVIF encoders filter the ugly noise is sometimes welcomed.

but not from fidelity point of view

Sometimes fidelity is not needed. Especially for web content.

if noise reduction is desired, a separate NR filter can be run prior to compression

it’s arguably not really an image codec’s role to do that

i'd rather codec produce some artifact indicating that something was there than photoshop my images to compress better

i would argue it's _really not_ an image codec's role to do that

just like it's not the role of a printer to try to autocorrect spelling mistakes in a document you send to it to print out

also things like "I like the distortion created by this codec" is very much the kind of thing that changes from person to person

Some people like (some small amount of) ringing because they see it as improved sharpness. Some people like smoothing because they see it as noise reduction. I haven't really met anyone yet who likes banding or blockiness, but there are differences in how annoyed people are by it.

I have a small photo printer (a Canon Selphy CP1300) that does, by default (iirc), adjust the brightness of the images you send it so that they look “good” automatically

(but you can go “I know what I’m doing” and disable that behaviour)

adjusting brightness is one thing, and could maybe even be seen as part of the color conversion to cmyk where there are constraints like max ink coverage to be taken into account etc

it's another thing if it starts to photoshop your photos, removing pimples and wrinkles automatically because most people would welcome that

Once you've lost the detail it's gone, with JXL you have the option to keep or remove it later

https://www.roboleary.net/webdev/2023/03/06/next-web-image-format-not-jpegxl.html

Almost every television today comes with a default filter that sharpens the image and increases the saturation

various other “smart” filters, too

most of which I disabled on mine

especially that frame interpolation was quite artifacty

and the default amount of sharpening in the “HDR gaming” preset, unbelievably disgusting

I couldn’t believe my eyes

Apple phones have always had pretty accurate color management but at least in the past samsung phones have just stretched colors to the full gamut of the display because apparently oversatured colors look better in most people’s eyes

https://www.hollywoodreporter.com/movies/movie-news/martin-scorsese-christopher-nolan-launching-filmmaker-mode-tv-setting-1234968/

Maybe a bit off topic but the latest HDMI spec has something called ALLM (auto low latency mode) which makes the TV automatically turn off most image processing filters, but this is mostly intended for gaming consoles because it decreases latency. Also my sony tv comes with something called netflix calibrated mode which turns the image more neutral when watching content via the nexflix app

Can jxl give similar results with avif at lower bitrates with noise reduction filter? Does it look nicer like avif at very lower bitrates?

I think the official line is that JXL hasn't been tuned to work at low quality as well as AVIF yet. in my own tests at low quality AVIF looks nicer but it smooths out a lot of detail. JXL is more true to the original image but the artifacts and blockiness become more distracting

I know that. When people prefer appeal for web delivery, it would be better if there is a option or workflow to achieve appeal at lower bitrates.

It was said before that denoising/smoothing the image shouldn't be the codec's job, but maybe at higher distance levels it could help preserve 'real' detail, depending how annoying it would be to implement

I'm sure it might be possible to make improvements to the encoder but at least currently JXL exhibits macroblocking and ringing at low quality regardless of noise in the image so I think it's something inherent to the format. it reminds me of JPEG1. AVIF has a smoothed and smudged look much like WebP regardless of quality

if you really wanna use lower than usual quality I think at the moment it would be better to simply use AVIF, or wait for potential improvements to JXL in the future

If you want to optimize for appeal, it's generally a good idea to blur the background a bit, maybe sharpen the foreground a bit, boost contrast and saturation a bit. The background blurring can help a lot for compression.

Hmm... Wonder if an encoder could downsample the background separately with JXL

I hate all the stupid and ugly filters that most modern TVs apply by default that reduce fidelity and increase latency.

lol, maybe JXL should have an "appeal" mode, you can activate with the --instagram flag

Better compression ratio, better appeal, less fidelity

more lulz

it's probably quite easy to implement: just run an aggressive EPF before encoding as a denoiser, multiply X and B by 1.1 to boost saturation, do inverse gaborish twice to sharpen the image, and boom you'll have a low-fidelity encoder with tons of "enhancement gain" as the vmaf folks like to call it 🙂

I mean hey, as I said, have it flip on after d 20 or something, at that point you usually have more blocking artefacts than actual detail anyway

Remove everything after the aggressive EPF and it'll work properly 🙂

so this is how codecs die … with thunderous applause

Nobody serious is doing encoding with in-encoder enhancements on purpose anyway.

yeah an image preprocessor, I recommend naming it "instagram mode aka AVIF mode"

But your idea of foreground detection and slightly blurring the background is interesting.

No AV1 encoders do that by default...

Maybe lay off the edge 😂

No need for preprocessing if the codec filters are aggressive enough to do it in decode-side postprocessing 🙂

https://giannirosato.com/blog/post/image-comparison/

my blog post comparing AVIF, JXL, & others using SSIMU2. I'm gonna make the lossless dataset & my data public as soon as I can store it properly

Typo: reasearch

Another typo: "the libjxl reference encoder implementation, cjpeg"

Nice blogpost! And thanks for all the praise 🙂

Ah, will fix!

<:PepeOK:805388754545934396> 💖

currently discussed at https://news.ycombinator.com/item?id=35212522

I feel famous <:Hypers:808826266060193874>

<@703028154431832094> maybe on your blog post you could point to something like waterfox for firefox users? I see you are already pointing people to thorium for chromium

waterfox and palemoon have almost full support for jpeg-xl excluding only really HDR support

the jpeg-xl support in firefox nighty is very incomplete

I'm waiting until Mercury has full JXL support to mention that instead, as it will be more modern

Waterfox is pretty modern it's on the latest ESR version of Firefox

Maybe I will mention it then, although I'll have to give it a spin

There is no equivalent of thorium for fitefox? Agressive compilation and custom patches?

https://thorium.rocks/mercury

My bad, thanks 😅 I feel dumb

<:monkaMega:809252622900789269> what th

I'd like to try it........ but the browser doesn't work. it just won't start https://github.com/Alex313031/Mercury/releases

i've actually gotten better browser test results in waterfox compared to mercury somehow

Do you have non avx2 processor?

Yes i am

May be it doesn't work on those cpus

Yes. Bad software. What's the point of making the "fastest browser" if it doesn't work on old weak processors

It is not a bad software.

it is simply not compatible with your system. not inherently "bad"

I can't start it. Of course this is bad software. How can you argue here?

I thought modern apps can launch even on 16-bit systems, even if just to print a message about incompatibility.

Silent fail is kinda...

For your information. Microsoft Windows said only that support for 32-bit processors is being discontinued. There is no talk about canceling SSE only support, because if you didn't know, you can buy some kind of 2-core laptop with intel right now, which doesn't have avx, now in 2023.

90% of steam users have AVX2 anyway, so this is more of a rare occurance

not sure what it is for all hardware out there though

Well, some people might be trying software (of any kind) on outdated systems, in which case it won’t start. That doesn’t mean the software is bad, just that their system is outdated. In this case, it might be a matter of certain build flags being passed in that prevent it from starting on your system, which I don’t think makes it bad software, just (at most) an unfortunate build choice.

But the entire point of thorium is to be optimized using those build flags for increased performance

It could be better if that software outputs some info like ' your processor is unsupported, missing xx features '

With this argument, you can cancel the linux.

for dzgas, when he says that something is bad you gotta mentally add "for dzgas" and it'll make sense

arguments about compatibility issues when audience is far out of intended one is probably as old as time

see also: gtk4 font rendering on non-hidpi devices

Well. apparently you also need to tell separately. that AVX is optional feature. and "SSE only" is not something that is being canceled. The fact that the software developer did NOT compile it with NON-AVX support is his problem, this is his task, he must do it so that the software works on the systems that are used. I say that the software is bad, because compilation in AVX only mode shows the incompetence of the developer. And I show, it says, yeah, x64 windows - I run it. and it doesn't work. Why is this my problem? Can you tell me since when the build with the inscription win64 became AVX-only?

saying that AVX2 is soo expected when it infact isn't is silly, and so is jumping on software that is intentionally compiled with different architecture options when your stuff doesn't have relevant compat

you guys silly

imo making thorium defacto libjxl browser socially is kinda wrong too due to avx2 stuff but that just ended up happening eh

Yeah, great. sounds great. how to run it?

👆

Thorium doesn't require AVX2

and when it's compiled with AVX2 stuff starts breaking in odd ways

interesting. then why it doesn't run

AVX (non AVX2)?

> It is built with SSE4, AVX, and AES, so it won't launch on CPU's below 2nd gen Core or AMD FX, but benefits from Advanced Vector EXtensions.

oh yeah

Thorium does require normal AVX however there are special builds without this requirement https://github.com/Alex313031/Thorium-Special/releases

oh. okay. so issue was with mercury not having builds like that

just raise an issue on the repo then

----The question is logical - why is there no AVX only inscription on the build name? ----Does the developer even know that his build is AVX only? ----It seems to me that people don't write AVX-only in the build name - precisely because real developers will laugh. lol

mercury will probably start having builds for other cpus once it isn't considered beta/experimental anymore

there is nowhere in the repo's readme that points to it being beta/experimental

by the way, a funny thing. half an hour ago I downloaded Original from github... but this is not a windows build...

Of course the golden man did it 🥹

ah it seems as though I read "ALPHA BUILD, FOR TESTING ONLY" on the latest release and assumed it was for all the builds

either way mercury still seems like it's less figured out compared to thorium

its state is likely alpha still yeah but the communication of that could be better

is that a known issue?

yes, https://gitlab.gnome.org/GNOME/gtk/-/issues/3787 they ended up adding option to work it around after long convincing by community

I mean, to be fair, I believe all even Intel's lowest end CPUs now include AVX2 SIMD support.

<:BlobYay:806132268186861619>

I have a low-power laptop bought in 2019, specifically for use during trips, it consumes little energy and has only passive cooling. It does not make a sound and is the perfect solution to work on it in the back seat of the car. And it doesn't have avx. And I can't run this " fast fork of firefox " on it

I find coherent that an edgy distribution of Firefox which exists for the sole purpose of pushing some edgy compilation options works only on edgy CPUs...

<:BlobYay:806132268186861619>

woah cool where is this stated/said?

https://www.reddit.com/r/linux/comments/11wpenc/comment/jczm6al/?utm_source=share&utm_medium=web2x&context=3

oh wow I found the repo with the patch https://github.com/OpenMandrivaAssociation/chromium-browser-stable/blob/master/chromium-restore-jpeg-xl-support.patch

Nice

<@245794734788837387> Yeah, I showed them the patch to get it enabled, and here we are :)

Openmandriva is the baby that I want to grow into the most powerful distro <:YEP:808828808127971399>

<@164917458182864897> and <@703028154431832094> can attest to that.

Oh dang I didn’t know u were into them

They seem cool, although someone should tell them to get Fosshost off their landing page, that org died

Pretty badass to just ship a patched chromium (as opposed to making a fork)

based

So is anyone persistently asking Google why there's no response wrt "the Chrome codec team" aka Jim Bankowski just randomly disregarding what everyone else says and unilaterally sweeping JXL under the rug to die quietly as intended?

Getting years to gain domination, and to add missing features

A paper comparing JPEG XL with other codecs in face recognition: https://arxiv.org/abs/2302.12593

> Lossy face image compression can degrade the image quality and the utility for the purpose of face recognition. This work investigates the effect of lossy image compression on a state-of-the-art face recognition model, and on multiple face image quality assessment models. The analysis is conducted over a range of specific image target sizes. Four compression types are considered, namely JPEG, JPEG 2000, downscaled PNG, and notably the new JPEG XL format. Frontal color images from the ColorFERET database were used in a Region Of Interest (ROI) variant and a portrait variant. We primarily conclude that JPEG XL allows for superior mean and worst case face recognition performance especially at lower target sizes, below approximately 5kB for the ROI variant, while there appears to be no critical advantage among the compression types at higher target sizes. Quality assessments from modern models correlate well overall with the compression effect on face recognition performance.

Thanks, I hadn't seen it...

https://www.fsf.org/blogs/community/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats

https://www.reddit.com/r/StallmanWasRight/comments/12kaja8/googles_decision_to_deprecate_jpegxl_emphasizes/

https://www.reddit.com/r/programming/comments/12lfgrz/googles_decision_to_deprecate_jpegxl_emphasizes/

https://www.reddit.com/r/rust/comments/12lkg5r/jxloxide_a_pure_rust_implementation_of_the_jpeg/

I can't take their article seriously. They refuse to link to the bug tracker because of nonfree JS. Okay fine. But couldn't you have given us some screenshots from the bug tracker at the very least?

Also this is purely virtue-signalling until they walk the talk by adding JPEG-XL support to GNU IceCat and Abrowser.

> Firefox, through ethical distributions like GNU IceCat and Abrowser, can weaken that stranglehold. *snorts* Yeah, those two rebuilds which are probably even more obscure than Pale Moon (which is a real fork btw) can weaken Google's control, lol...

FSF is pure purism and principles. Which I think is fine and interesting, helps to bring philosophical clarity, though actually living like that is crazy, and from a pragmatic point of view a holier-than-thou approach is probably not the most effective way to make progress...

I feel like the “holier‐than‐thou” is in the eyes of the reader. I didn’t really feel like the article’s author was trying to come across as if they were better than anyone else because they chose to not visit or share a link the bug tracker. Also, I feel like they are not unreasonable to want to avoid proprietary software so actively. The entire premise of their principles (or at least one premise) is that it should be possible to live your life and use computers without needing to run proprietery software, so it would be a bit hypocritical to *use* proprietary software in cases you can just avoid it. Reminds me a lot of Lunduke (when he was more sensible) and what he used to say: In many Linux conferences and gatherings, you find a lot of people using Macs instead. It’s kinda hypocritical to be defending Linux as a usable daily driver, and to not actually use it yourself.

I use a MacBook myself (since Cloudinary gave me one), but I spend most of my time in a VirtualBox that runs Debian unstable 🙂

I see! 🍎 I don’t really have anything against Macs, by the way, I was mostly trying to make an analogy. (Though I suppose your point is that you generally prefer Debian over OS X.)

I use MacOS for browsing (Thorium works fine in MacOS) and for proprietary software like Photoshop and MS Word which I unfortunately do need to use every now and then for my job. For coding, I prefer linux (no strong preference on distro, but Debian is more or less the "mother distro" so it is convenient). Most of the code I write ends up getting deployed on linux servers, so it makes sense to have a working env that is similar.

but _can_ they avoid it here? we’re talking about linking to the page with what they are talking about

I understand not wanting to be too hypocritical but it doesn’t have to go all the way to https://thenib.com/mister-gotcha/ level

I think the difference is that they don’t generally say that people are unethical for *using* proprietary software, but rather for creating it (or promoting it). They recommend against using and promoting it, but that doesn’t mean that they think people using it are being unethical. I understand what you mean, though, where it seems they come across as if saying “I know better than other people by not linking to the issue tracker”. But I think the point is to protest against the people *who created* the proprietary issue tracker by not linking to it. I know it doesn’t seem like an effective protest when people who no‐one has heard about simply avoid linking to an issue tracker, but I think GNU and the FSF are very fond of the premise that small changes are important, since they can build up and potentially snowball into bigger changes. As in, “maybe the goal seems unfeasible, but only when people aren’t convicted enough to act towards it”, and “if no‐one starts because it seems unfeasible, then it certainly won’t happen”, or “there need to be people willing to put an effort in order for it to happen”.

My office provided Macs to everyone with the expectation that developers worked out of Linux VMs.

The FSF article got on Slashdot... and here go the "I need to see the image used on the web (before it's actually supported by web browsers)" comments 🤦 https://news.slashdot.org/story/23/04/16/002204/fsf-says-googles-decision-to-deprecate-jpeg-xl-emphasizes-need-for-browser-choice

I cant decide if that argument is more "chicken and egg" or "Catch-22"

> Maybe I've heard once or twice about JPG-XL, never ever have come across an image in such format. 🤦 Basically saying "I didn't encounter it in the wild yet so it cannot be good" I hate it when people infer technical merits from popularity, especially for new things...

https://www.phoronix.com/news/FSF-Slams-Google-JPEG-XL

don't know why in the FSF post they say AVIF is "patented" because isn't it patent free? unless they mean patented in the non-literal way

There was at least one group that was sort of claiming they may have some patents that might be infringe by AVIF, but it seems to mostly be FUD, and the big players don't seem to be worried about it.

So sort of the same thing as the Microsoft ANS patent debacle with JXL.

Both AVIF and JXL are patented with defensive patents made available royalty-free. In case of AVIF, there is Sisvel claiming to hold patents (in a non-royalty-free way) but it looks like the big players ignore this and assume they can invalidate those patents in case it comes to litigation. In case of JXL, nobody has made claims yet (Microsoft never claimed that their ANS patent is relevant for JXL, and it isn't).

it’s arguably a form of https://www.logicallyfallacious.com/logicalfallacies/Naturalistic-Fallacy

I wonder if there will be AVIF2 when AV2 arrives.

> And when I heard of it, I never even tried to work with it after the fiasco with JPEG 2000 working times and their draconian licenses. red herring

jpeg xl does not have “draconian licenses”

Oh no, not the AV2 talk

hmm? did I say something wrong?

my point was: implement JPEG XL and you are good for photos for next 30 years implement AV1 and you can start working on AV2 already 😄

I think not. Just like there is no WEBP based on VP9 I am sure there will be no AVIF2 based on AV2 because AV2 itself will be released so soon that 1. it might not reach Jpeg XL level 2. it will be even slower and most likely be a bad solution for animations.

In fact, I've seen that Animated AVIF is faster than WEBP and it doesn't seem logical to me. But I don't know to what extent AVIF animation's decoding requirements have been reduced. Were CDEFs used? Or how many P-frames

Did j2k have a draconian license at any point? I think at least the core codestream has always been royalty-free. The main issue is that the best implementation is proprietary (kakadu), but you can use e.g. OpenJPEG or ffmpeg's own j2k implementation and that works fine. I wonder what draconian licenses they mean and if they're not confusing with hevc or something...

oh, still the rANS patent fear-mongering as well

Ah. of course I do not consider AV2 or AV1 as a competitor now. because I do tests and I just see that Jpeg xl is better ☝️ For me it is obvious. But the Animation is the only thing where JPEG XL will never be better. and it's a good topic of discussion for AVIF.

(https://news.slashdot.org/comments.pl?sid=22847168&cid=63453480)

Yeah, I personally consider JPEG XL only for static images (mainly photos). AVIF can rule animations if they want. It makes sense, since it's based on video codec.

Funny comment: > Therefore it is JXL and not JPEG. And whatever Chrome does with it does also mean that I haven't heard of anything which support to create JXL. And if JPEG has flaws, then do JPEG 2.0 and throw away JPEG 1.x after some time(and maybe make some plugin installed by default which support it). I thought that JXL is kinda JPEG 2.0

I agree that one of the problems with jpeg xl is its name

so, drop XL and just call it JPEG?

Quite the contrary

look like weak point of JXL is marketing 😄

Jpeg pro Max ultra

The point is that a very clear and simple idea - Jpeg is bad, it's old, its time has passed. And it just so happens that the name Jpeg XL has the word jpeg in it.

jpeg 2 - would sound much better

but oh yea jpeg2000

Jpg2022

yes you can right away - the best image codec for the next 30 years TBIC30

Well, lets just hope Adobe brings JXL into production... then people can start using JXL as working format and from there pressure can be applied to Chrome.

Wonder what happens If Adobe adds jxl to pdf spec

The best codec for the next 100 years is dzgi.

<:H264_AVC:805854162079842314>

it's interesting how much original JPEG was improved over time... I hope JXL has the same room for improvement into future

From my observations of working with Jpeg xl over the past 3 years I would say that for 10 years I am sure that Jpeg XL will be able to compress 5% better every year after its release with identical quality views. But these are just my numbers from my head. but I have a firm belief that in 10 years the Jpeg XL will be able to compress 1/3 better with identical image quality

thanks 🙂 so JXL can play the long run

Does anyone have quality comparison among early jpg and modern jpg encoders?

Well, can also understand that there are still a lot of plans and work. For example I'm still not satisfied with the way the block positioning system works at the moment, I'm waiting when it will be dealt with much more seriously. But perhaps this too will not be soon. This is one good example of the fact that there is still a lot of work to do. Because jpeg XL has a very large number of blocks which are not used at all. https://discord.com/channels/794206087879852103/848189884614705192/1086238522689728513

One reason why jpeg encoders improved over time is because jpeg is ubiquitous, universally supported by anything. It makes way more sense to improve an encoder for a format that is already widely adopted than to improve one that is isn't...

Even JXL ended up with an improved JPEG encoder in the form of jpegli

we could always pretend that XL stands for "eXtended Life" even if it doesn't really

yeah, JXL must be better in ways that cannot be incorporated into old JPEG... or else why would anyone upgrade to JXL if the same improvements can be included in good old JPEG and be also backwards compatible

https://arstechnica.com/gadgets/2023/04/free-software-group-decries-google-dropping-space-saving-jpeg-xl-format/

looking at that article and the comments it's sad to only see JPEG-XL looked at as a possible replacement for lossy formats like JPEG even though it can function as a really good replacement for PNG which is something other formats like WebP and AVIF can't say

it seems like most of the comments are unaware of JPEG-XL that much at all and the people who are only bring up the benefit of lossless JPEG transcoding and progressive decoding and don't bring up the lossless mode

webp can only sort of replace PNG, thanks to all its limitations, blech

WebP has so many limitations

though most of the time you wouldn't run into them, at least in my case

it can only replace PNG for images that are 8-bit depth and below a certain resolution

As you said, very little mention about the extremely good lossless compression, but most comments seems to be agreeing that they want JXL and google is being stupid

Left a comment filling in the gap, hopefully it might help some of them <https://arstechnica.com/gadgets/2023/04/free-software-group-decries-google-dropping-space-saving-jpeg-xl-format/?comments=1&post=41795959>

WebP has more limitations than PNG, and PNG has more limitations than TIFF, which is kind of interesting since TIFF is older than PNG is older than WebP.

TIFF can do CMYK, 32-bit float, and layered images while PNG can only do RGB, 16-bit int, and no layers.

And lossless WebP can only do RGB, 8-bit int, no layers and at most 16k x 16k pixels.

JXL can do lossless CMYK

tbf, there's no particular reason Portable Network Graphics should be able to do CMYK

:)

TIFF, MIFF and PSD are the only formats besides JXL that I know can do lossless CMYK.

"Portable Network" is not the same thing as "for the web". It means it's a format meant to exchange images in a platform-independent way ("portable") over a network (as opposed to via floppy disks). The latter ("network") is why it has a header that catches accidental sending in ascii mode instead of binary mode, and why it has CRCs all over the place to catch transmission errors.

ah, mb, I thought the intention was for web

of course web was an important use case, but it was mostly meant to replace GIF as an interchange format for graphics

interchange formats as opposed to platform-specific formats like BMP

https://www.macg.co/logiciels/2023/04/google-ne-supporte-plus-le-jpeg-xl-et-cest-un-probleme-136203

a comment: > Du reste, le développeur principal de JXL travaille chez Cloudinary, pas chez Google, et n'est pas très content de la décision de Google.

😁

Congrats Jon on becoming lead dev 😯

> C’est quoi ssimulacra2 ? Un sextoy nouvelle génération ?

Gotta love the French dirty mind

> il n'est pas le seul et devant le tollé provoqué par leur décision de retirer le code de JXL de Chromium, ils ont produit une pseudo-étude ridicule censée prouver qu'il y avait une justification technique.

Harsh but kind of fair point

I'm french too, but I first saw a reference to the game : https://store.steampowered.com/app/712730/SIMULACRA/

Huh, they even mention the FSF statement.

oubliez les dévs qui ont les adresses comme `@google.com`

n'est-ce pas?

<:PauseChamp:755852977574510632>

Ooh, je ne savais pas que tu parlais français. Ooh, I didn't know you could speak French 😄

several years of it in college, ye

https://www.reddit.com/r/firefox/comments/12qngdj/fsf_chromes_jpeg_xl_killing_shows_how_the_web/ top again

https://www.techspot.com/news/98355-google-deprecating-jpeg-xl-own-predatory-interests-fsf.html

predatory ☝🏻

https://www.opensourceforu.com/2023/04/according-to-fsf-google-is-disregarding-jpeg-xl-for-its-own-nefarious-purposes/ "nefarious"

a lot of these articles about the FSF post are missing important information

even the FSF post itself is missing information

Yeah, the FSF post is very concise. (More so than I think is warranted.)

I don't think it's really true that Google has any commercial interest in blocking JPEG XL, in fact to the contrary: it's in their interest to make the web better (since more web usage basically means more profit for Google), and a web platform with JPEG XL is imo obviously better than a web platform without it.

It's imo just a matter of petty office politics and the "not invented here" syndrome (at the department level, since at the company level JPEG XL is actually even to a large extent invented by Google).

Of course the monopolistic market share of chromium is worrying, as well as the resulting power a handful of gatekeepers have to shape the web platform unilaterally without taking any community input. And unfortunately chromium being FOSS doesn't really help: sure, you can make forks, but most of those forks are just going to follow upstream on nearly every decision anyway, and their combined market share is too small to make a difference anyway.

And yet using a Chromium-based browser is still an irresistible urge for many. The amount of market share Chrome alone has is staggering, and the fact that Chromium is open helps them remain dominant

I'm on Firefox but I understand most Chromium-based browsers are faster and more feature complete in many ways. I'd try switching to Thorium if there was a Flatpak

Lots of browsers being chromium-based is fine imo, it's just not fair that chromium is completely controlled by chrome/google as opposed to having some kind of democratic decision process when there are disagreements to be resolved.

The key point is that chromium is open, yet google decides what goes in...

it's not open it's a glass building

we'll need plungers to break in ? like tom cruise ?

I'll bring my finest rock

If we can get forks to have more market share than they have right now, and if forks would deviate from upstream not just when it's on a topic related to their "raison d'être" as a fork, then at least the power of google chrome gatekeepers would be reduced a bit

Generally the point of free software is that if the decisions made by the developer are something the community dislikes, they have the power to create their own variants that don’t abide to those decisions. But the issue with Chrome is that its vast userbase is mostly constituted by people who don’t realise or understand or care about some of the decision Google makes, and aren’t willing to move away from it.

It is kind of a flaw with the premise of free software in general. It accounts for certain kinds of projects, but specially for widely used programs, it doesn’t really work as effectively. If `youtube-dl` stops being updated, people can move to `yt-dlp` and obsolete `youtube-dl` as a community. If enough people dislike a decision made by the developers of a given program, they can move away from it. But if Chrome drops support for JPEG XL (or makes another kind of bad decision), it’s difficult to convince most of the user base that the decision makes it worthwhile to move away from it, just because the user base is so large.

I’m not sure it relates as much to kinds of projects as it does to kinds of features

would we not have similar difficulty if, say, Krita decided to drop JXL?

I compare Chromium more to Linux kernel... If Linux kernel does something unpopular anyone can fork it, but all distros will still use the main kernel. But since kernel development is community driven, there is no problem and no reason to fork it.

Imagine a world where Chromium has 80% market share like it has now, but it's not 66% Chrome, 4% Edge, 3% Samsung, 2% Opera, and then a whole bunch of < 1% small ones, but something like 20% Chrome, 10% Thorium, 10% some-other-fork, 10% yet-another-fork, 8% Edge, etc. It would be a different dynamics for sure...

I'd say its closer to Android (AOSP), where getting something in that goes against the main party's interest is very difficult as they control it. Linux really befits from not being a single company project.

I suppose so. It depends on both, I’d say. For a program with a small community, it’s easier to fork and obsolete programs, but when the community is large, it’s more difficult. I think it’s a matter of the percentage of the user base that understands and cares about the importance of the decision. So it does matter on how significant the feature is, and also the size of the user base.

A browser is just such a big piece of software with so many features and so many aspects to consider, that people generally do not pick a browser based on support or lack of support for one specific feature. Especially if the current practical implications of having the feature or not are rather limited.

If an image editor does not support a format I really like, that might be a reason to switch to a different editor, at least for part of the workflow. But if a browser doesn't support an image format, that's not really a problem for the end user, it's only a problem for web devs who want to use that format.

The end users (i.e. web consumers) decide what browser is popular or not, not the web devs (i.e. web producers)

No sane web dev will use jxl without fallback just to prove some point to browser devs

So no end user will even know that they're missing something

our best bet now is a blazingly fast polyfill ?

Yeah, that’s partially what I meant by “certain kinds of projects”. Chrome is intended for the general public, rather than for developers. Even as an end user, I can disagree on principle with decisions that affect developers, even if they don’t affect me directly. But given Chrome’s audience is so general, it’s difficult to get a large portion of the user base to understand the importance of a feature that doesn’t seem to affect them.

I don't really think that will help. Even if some big websites would start using it, browser devs could still say "see, wasm is good enough, no need to add native support!". It would give little visible signal, because it will likely be very hard to even gather data on how often the polyfill is actually used. And it's a suboptimal solution in terms of performance, ease of deployment, and even possibility to deploy: e.g. for an image cdn like Cloudinary, it's impossible to deploy since we only serve images while our customers serve html — we cannot just magically make them change their html to load a polyfill, and likely the polyfill would have trouble with loading cross origin data anyway...

Considering how little coverage JXL gets in the mainstream media, I thought this was worth a shot https://linustechtips.com/topic/1322697-thread-for-linus-tech-tips-video-suggestions/?do=findComment&comment=15900323

yep, but I was thinking to manga galleries providers as a foot in the door... obviously it is not a CDN, but if the format become mainstream in some environments which handles a lot of images it could start to spread something...

TBF, it's because of mobile.

If Firefox mobile was as fast as Chromium mobile, basically everyone would move to FF mobile.

IMO, this is the problem with Chromium as a whole right now. This is the reality, & it is not changing, so the best shot we have is with an alternative engine

Except launchers have Google search bars that go directly to the Google app with every search built in

I saw that comment earlier and my brain almost fell out of my head

<@245794734788837387> Don't worry, it's sarcasm <:KekDog:805390049033191445>

> every single feature must be maintained forever They say this yet failfox can't visit gopher:// anymore despite being used to. 😔

maintained forever unless removed, ofc

“The web needs to maintain all features for backwards compatibility, except for the ones it doesn’t need to.”

I kinda don't understand why there should be forever backwards compatibility. If there is old feature that is no longer used much why not just remove it with year notice or something. Websites will update and there will be no problem. If someone really needs it they can use older version of the browser.

Or just leave the feature and don't update it. That shouldn't be much burden, no?

Yeah, features are removed from browsers from time to time! It just doesn’t happen that much for certain foundational features.

I think browser-side on-demand polyfills could be a way to deprecate old features without breaking old pages: they would still work, just with worse performance because e.g. the BMP or lossy WebP images on the page don't use native decoders (which are removed) but javascript polyfills that get transparently loaded when needed — if the feature is really old enough, the js code wouldn't even get shipped anymore with the browser but just fetched on demand (which eventually could be never)

Exactly. Basically the opposite of what AVIF said about JXL. Instead of first making polyfill and hoping for native adoption make first native adoption and if it fails and is not popular then downgrade to polyfill.

Also doing polyfill transparently at the browser level, so it e.g. just works out of the box with images in an img tag, and not making it the responsibility of individual web devs to add js to their pages would make a big difference

(like how Chrome displays PDF files: that's not native code, that's a javascript pdf viewer)

in firefox the pdf reader is javascript in chrome it's not or at least it used to not be javascript i'm not sure what it is in more recent versions

also how would a polyfill be done in a possible situation such as for example if native webp support is removed and a website uses webp but has a fallback to jpeg then which is used?

That's why it needs to be done transparently by the browser: the browser can e.g. still claim to support webp when doing http content negotiation, just it loads a wasm webp decoder to do it instead of using the native one (which would be removed)

ha ! then a very good polyfill for jpegxl (if intergrated to the browser) could be an option 😄

Though if there are fallbacks it's not really an issue. The main issue is pages using features without fallback, which breaks the page if the feature gets removed (but transparent polyfills could keep things working, just at some perf cost)

A polyfill integrated into the browser is basically the same as the browser supporting it in a not very optimized way — but with less security surface and possibly less browser bloat (if the polyfill is not shipped but fetched dynamically and only locally cached if it ends up being needed by the pages visited by the user)

Since polyfill would be used for features where better alternative is already available the lower performance wouldn't be a problem

(yet I missed something, the polyfill could be hosted somewhere on a CDN, like jquery or mathjax is and used by any website)

(the issue remains that the quality of the integration is poor and the progressiveness will be painful)

Hosting the polyfill like jquery does has the problem that modern security features will likely not allow the polyfill to load image data from a different domain than the one hosting the polyfill

And also it requires cooperation from the web devs to change their html to load the polyfill code — so old pages would still break (I am talking about using polyfills to deprecate old features in new browsers rather than to get new features working in old browsers)

But the polyfill wouldn't download anything. Just fiddle with ordinarily downloaded <img> tags... I agree about the burden on the developer though. He will have to add an additional <script> line in the header

what about opening an image in new tab/window?

Ehhh, I'm not sure if we want that to be applied to all future image formats... But if this future image format is finalized and is now an international standard (like ISO certified as one), then sure why not. JPEG-XL would fit that criteria

You are right. What I mainly meant is that current mindset is "we only add features that are already widely used because once we add them we cannot remove them and have to support them forever" But thanks to polyfill solution it can change a little and browser authors might be willing to add promising features even if they lack wide usage yet.

Rust jxl encode library > ...Simple jpeg xl lossless encoder with the following features > Lossless encoding > 8 bit -16 bit support > Grayscale and RGB{A} encoding https://github.com/etemesi254/zune-image/tree/dev/zune-jpegxl

https://community.adobe.com/t5/photoshop-ecosystem-ideas/jpeg-xl-is-what-we-need/idi-p/13756494

https://codepoems.eu/posts/how-to-open-jpeg-xl-images-on-linux/

Someone might want to reply to the latest pointing out it has layer support

Done

I still don't understand why Adobe doesn't include optional compression in PSD. I use TIFF just because it offers zip compression. Otherwise I would just use PSD.

does psd store more informations than the layers and their relative positions ?

yes, you can have text layers (which are editable), many blend modes and layer effects, stuff like clipping paths and other vectory stuff, recently they also added layer objects which can be basically anything (a nested other PSD file for example, or vector graphics), etc etc

PSD does have some compression options — it does have PackBits (RLE) and ZIP too, just like TIFF

for some reason Photoshop doesn't really expose much choice though, there's just this global flag "Disable compression of PSD and PSB files"

iirc if compression is not disabled, it uses PackBits for 8-bit images if it helps (on photos it doesn't), and ZIP for 16-bit images. I might misremember though

in any case, all those compression methods are pretty weak and are usually beaten by even jxl e1

also: if you enable "maximize compatibility", it will add a redundant merged image to the file which is uncompressed iirc — this allows applications that don't know how to parse the layer data of a PSD file (for which you can't blame them, the spec of that is incomplete and changing constantly) to still show the merged image

ohh, I didnt realize that. when I see uncompressed TIFF 60MB and PSD 58MB... thats really weak compression

I think I have read something about it like you say that they use ZIP only for 16bit so if I want stronger ZIP compression for 8bit I need to use TIFF

Yeah, but zip isn't great for photos anyway, and for nonphoto RLE is typically not much worse than ZIP, unless you have repetitive stuff

I dont know details, I just know that for my working layered TIFFs using ZIP produced significantly smaller files for my photos so I am using that. In comparison to PSD or other TIFF compression methods. Save as: TIFF Image compression: ZIP Layer compression: ZIP

well, I would rather use lossless JPEG XL instead of ZIP but thats for Adobe to decide

> redundant merged image Oh, I would never call it _redundant_. Without it, you need Photoshop to do complex compositioning (not even other Adobe apps can do it). So, really, instead of _redundant_, I would call it _necessary_. 🙂

Photoshop ignores it when you open the image, it only reads the layer data. But yes, for browsing folders etc it does use it.

It's redundant in the compression/entropy sense: it can be reconstructed from the layer data (even if it takes a big piece of proprietary software to actually do that).

It's obviously not redundant in the sense that it's completely useless. It does help for backwards compatibility (allows opening a new PSD in an old Photoshop and it will at least load the merged image when features were used that didn't exist yet in the old Photoshop), and it makes browsing/previewing faster.

And it makes it possible to load a PSD in other applications than Photoshop, without the layers of course.

It's a bit of a messy catch-all way to do things though. If PSD is just used as an image editor file format, you don't need that merged image (which I guess is why they make "maximize compatibility" optional). If it is used as an interchange format, you can basically _only_ use the merged image (since nothing except Photoshop can reliably composite layers in the general case where arbitrary Photoshop features are used). So for interchange, you're basically sending a way bulkier file than what will be useful.

Basically you can also just make a PNG file with the merged image and a PSD file without the merged image; those two together will still be smaller than a PSD file with merged image.

(except PNG doesn't support CMYK and >16-bit)

True that. But wouldn’t that apply to JXL used as an image editor format too, up to a point? “Web people” would be screaming bloody murder seeing a complex, layered JXL posted by users on the web. Users they think need shielding from such mistakes. Now, I don’t need no shielding, thank you very much, I can bloat any file format to death. But before an identical composite of complex, image editor file format, can be streamed by browsers only as much as needed (as much as a lean composite-only version would weigh), there is a point there, isn’t there?

In some cases, layering can also be beneficial for compression. If it's for example just a photo with some text or logo overlays, doing that as layers (with vardct for the photo and modular for the text/logo) is probably better than doing it as a merged image.

It's a bit like PNG: you can do 16-bit RGB (48-bit per pixel) in PNG, or 8-bit truecolor (24-bit), or 8-bit palette. For interchange, 16-bit can make sense, while on the web you often want to use 8-bit palette and you almost certainly don't want to use 16-bit. Some uses of a format make more sense for one use case than for another.

My point is that a layered jxl can be optimal for interchange if sending a layered image that will 'just work' in anything that supports jxl (even if it doesn't support layers) is what you want to do.

For web delivery, generally you don't want to send a layered image and you also generally want to use pretty lossy compression, so that's a different use case.

PSD is of course not at all suitable for web delivery. But also for interchange it's not so great, since either the merged image is redundant because the recipient will open it in Photoshop (so it's not really used as an interoperable interchange format but rather as an image editor format), or the merged image is the only thing that will actually be used. Either option isn't really great...

Even for native usage it's unnecessarily large. I understand people that want no compression so they can quickly access and save images. But these people have tons of storage prepared for it. Other people, like me, want best lossless compression so they dont have to buy another drive.

Even if fast save/load is your only concern, there is no good reason not to use something like e1 jxl compression. Just the saving in disk io will probably already compensate for the bit of extra cpu usage...

yeah, people are quick to say “storage is cheap”, and, sure, you can find a lot of hard drive storage for not too much, but this omits the cost of managing all those drives

more practical is to buy a larger drive to replace the previous one, and that is not so cheap

and then, in any case, there’s backups to think of

Or in my case after 2 hard drive failures in as many years with no errors or warnings, now I'm pretty much forced onto a single SSD just because I've lost all trust in HDDs now and can't afford a 1:1 SSD for a clone backup. PSD is just a mess in general, was just meant to be used with photoshop and maybe the Adobe suite, but people started using it as a poorly supported interchange across third party programmes and even final copies of textures for 3D models I've seen a lot. (Nothing like using a 160MB PSD rather than a 30MB PNG...) And touching on the saved disk IO, that's one of the selling points for the filesystem compression I've been using a lot on Windows 10 <https://github.com/Freaky/Compactor>. Saving me about 100GB on a nearly full 2TB SSD, lo and behold it manages to roughly halve PSD files and can knock a third off of some blender files too, with the only limiter being drive speed since it's not a 90s compression technique.

You shouldn't trust SSD either.

Well it can't give the click of death and has a set expiry date on the flash chips, so at least I know more what to expect from it

https://9to5linux.com/xfces-screenshot-tool-now-lets-you-save-screenshots-in-avif-and-jxl-image-formats

»While AVIF will be available as an option you can select from the drop-down list of supported image formats when saving a screenshot, JXL is not available there. However, you can append .jxl to your screenshot when saving it.« Huh, isn't the code the same?

I did wonder why it wasn't in the screenshot above

For me it doesn't even show the AVIF option in the combo box

And I do have libavif installed

Yep, it can't save in JXL using the stable libjxl as expected

It needs libjxl-git

But it can save in avif using the stable libavif even tho it is not listed in the combo box for me, lol

Wait a moment... `identify` claims the saved .avif is a PNG... Duh.. for .jxl xfce4-screenshooter tells me it can't save in that format (again: as expected due to missing libjxl-git on my system)

Well that's one way to 'support' all formats

Initially the developer of xfce4-screenshoter wanted to wait to merge JXL support until stable libjxl 0.9.0

I tend to say the problem is the way the article is written

Even with libavif-git from the AUR it seems to save a PNG (and it does not display in the combo box). `identify` can identify other AVIF images so yeah well, maybe the AUR package is missing something but w/e... I installed libjxl-git again and it actually is showing the JPEG XL option in the combo box.

After installing gdk-pixbuf plugins, it is good to run: gdk-pixbuf-query-loaders --update-cache

Also https://jpegxl.io/tutorials/macos/

How does this site detect JXL support? Because right now the text "Your browser does not support JPEG XL" when you browse using Safari 17.

no idea but I assume some kind of javascript test that doesn't actually work

the way we did it at https://jpeg.org/jpegxl/ is nicer, you can just check the bottom right corner of that image 🙂

or https://jpegxl.info/ if you want something more obvious 🙂

someone said that the text is statically in the page source, so it has to be server side

https://firsching.ch/jxl/ does tell you correctly if your browser supports jxl?

> apparently, Safari doesn't support loading jxl format from data URIs > they detect by feeding a 1x1 px tiny image/jxl as a base64 data URI

so this also doesn't work then? https://jpegxl.info/art/2021-04_jon.html

then this should also not work: https://google.github.io/attention-center/

The progressive demo worked on my ipad when it got to 100%

ok, that is at least something

I'm guessing macOS Safari's native support has different bugs than the system framework support that Safari uses on iOS.

does that page work? 😄

this might be the same bug as the one that Apple still has with WebP

some tiny bitstreams for some reason don't decode

for webp we still haven't been able to find a criterion, it's not a fixed filesize threshold that triggers the bug, but there are some (typically small / low entropy) webp files that for some reason don't decode in Safari

interesting...

I could imagine someone doing some DoS-avoidance scheme where they require images of a certain pixel size to be at least some number of bytes

Yeah. Avoid rendering billions of pixels of empty space or something

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

I don't see any comments from any Chrome team member since after the Safari news, so the HN headline doesn't make a lot of sense.

I would call it premature to say the least

:VeryPog:

hehe yes that's quite premature, it's like what, not even 24h after the news broke?

They need at least 4 weeks to think and type about it

what kind of lazy workers are there 🙂

they need 4 weeks to not respond to jon's emails so you never know :D

Thanks for pointing out the tutorial needs to be updated. I currently lack time to maintain the site 😦

Exactly. Sad to hear it's not working on Safari, ugh

it should work if you zero pad it until it's large enough, apparently

ack, so my site's BG at saklistudio didn't get rendered then?

how's it supposed to look like?

something like this

ah, nope

padding it with a bunch of 0's shouldn't be that bad since http compression should reduce the download size they take up hopefully

shouldn't your http server not attempt to compress jxl files

well it would be embedded as base64 in the main html so it should be compressed I assume

or load it with normal jxl file instead..

I think that the small size thing actually affects regular files as well, but I haven't tested it.

ah if it's really small i guess so

like the unrendered ones in jxlart page?

yeah

for example 34 byte iceberg is just a file, not a base64 URI, and it does not render

ah I see

they should get that fixed, I don't know what it is but we actually ran into problems with small webp files on safari

anyway I added an extra XYB CMYK to https://saklistudio.com/jxltests/ however I'm a bit puzzled as why it it's often not get rendered on Thorium

the XYB profile one also does not work in Safari

adding simple collapsible to the original profile so it won't instantly crash waterfox, seems like the XYB one works there

https://www.searchenginejournal.com/apple-safari-17s-hidden-gems-jpeg-xl-font-size-adjust/488647/

^ never heard of this website before and the article is pretty short but it's nice that it highlights progressive loading as a big thing

it would be nicer, again, if safari actually supported progressive loading

for jxl

IIUC it doesn't yet (don't have apple devices, can't test)

Bear in mind it was released literally 1 day ago, still got time

It doesn't

true, though i feel it's a little disingenuous to talk about the benefits of progressive loading when it hasn't been implemented yet but i guess at least the initial implementation is there, hopefully it does support it soon

there is a chance that progressive decoding might work in safari but in a way that doesn't work with the progressive test website because I remember trying to test out WebP incremental decoding in browsers that definitely support it and it wasn't working

a true test would be to try to connect to a website with a JXL embedded while the network connection is throttled

I'll try it tomorrow

Yes, the progressive demo website basically relies on the decoding of partial (but completely transferred) files. A more realistic test would be to run a throttled server, which delivers an jxl image slowly

https://www.theregister.com/2023/06/07/apple_safari_jpeg_xl

I like that the JXL support in Safari is spreading well <:pepelove:674256399412363284>

I wonder what will Chromium team say.

I'm kinda disappointed some of the media sites I consider to be on the better end did not mention the support at all.

One of them literally spamming with new articles during the Apple conference, lol.

No post from Phoronix about jxl safari

Huh

Looks like heise just dropped an article

https://www.heise.de/news/Doch-noch-Hoffnung-fuer-JPEG-XL-Safari-unterstuetzt-das-neue-Bildformat-9180088.html

Now that one of them published it, others will quickly follow.

»Life without Chromium and Firefox is possible: Safari supports JPEG XL« Implying life without JPEG XL is not possible <:KekDog:805390049033191445>

That title probably alludes to a quote „Ein Leben ohne Mops ist möglich, aber Sinnlos“, which translates to "A life without Pug is possible but meaningless" by the German cartoonist/comic Loriot