JPEG XL

Yeah, could be that they tried to make a pun at this. But since they left out the second part, it's hilarious.

https://blog.fefe.de/?ts=9a7e4b72

for some more German language coverage

For some additional info: fefe's blog is one of the biggest blogs in the german IT space.

https://www.peakhour.io/blog/jpeg-xl-down-but-not-out/

did you get a chance to test? I'm not sure what the dev tools are like in Safari so idk how hard it would be to force a throttled connection.

I forgot

I only have Safari on ipad, which o guess does not have dev tools

I'm just gonna set up a throttled server

this is a good test site: https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php since it's full of pretty high res images that all try to load at once

Is it supposed to look like this on sdr displays?

no

it's supposed to look like this on SDR displays

<@263309374775230465> what browser is that?

looks like mobile chrome

weird, for me, Chrome doesn't load them at all

Thorium

(Safari does)

oh, that's Android

Maybe my phone is using a broken HDR implementation or something like that

I don't find the link for android thorium anymore

Could you give me

https://github.com/Alex313031/Thorium-Special/releases

hdr images on SDR displays are broken on 32-bit Chromium builds on Android

I'm using thorium 64bit

They might be running in the same issue, it used to happen on 64 bits too

I updated https://jpegxl.info/why-jxl.html#software_support

Yes, OpenMandriva and KaOS have jxl preinstalled by default afaik

there might be others that do that, feel free to add those too

Well, for Mandriva they differ in that they ship chromium browser patched for jpeg xl support enabled by default

yes, that too — but also they have libjxl installed by default, viewers with jxl support by default, etc

so I guess the criterion for being included there is "jxl just works out of the box"

(as opposed to distros where making it work requires some user action, even if it's just a `sudo apt install` or something)

that thorium icon is just evil

not even evil, it goes against Google's brand guidelines

please fix

https://www.golem.de/news/browser-safari-unterstuetzt-jpeg-xl-2306-174791.html Slow but finally

Colorless article basically; no strong author opinion 😮‍💨

How?

by removing it

Or maybe thorium should get a better logo?

What exactly is wrong with that logo though?

everyone just thinks it's chromium and I thought chromium doesn't have jxl

yea it is somewhat misleading since it's so close to the chromium logo

It's also basically just chromium

But yeah it's kind of confusing

Can we ask the thorium devs to pick a better logo?

I don't want to remove thorium from that page since it currently is actually the browser with the best jxl support

But it's basically the same as the chromium logo, just with a black circle in the middle instead of a white one

So that's confusing indeed

only thorium users will understand it. And because of that, having their logo on that page is only harmful.

https://thorium.rocks/imgs/Thorium90_504.jpg

Maybe we can use this instead?

imo should just have Safari

I swear more users are on Chrome m91-109 than the browsers other than safari and FF nightly

or should start gaslighting people to thinking that chrome supports it until they actually support it

It's not just about market share / importance, it's also about giving pointers to people who want to use a browser that has jxl support

are you trying to sell an image format or are you trying to sell a web browser

Trying to let people know about an image format and about how they can use it

If there were hundreds of forks with support for the format, then the situation would be different. But given the current situation, I would say those few that went out of there way to support it should be honored by a mention on the page.

yeah what about my version of firefox

i know of at least 3 other people who use it

agreed

Just add big bold labels to icons.

the Waterfox logo being used there is the weird messed up looking SVG version that the Waterfox project keeps using for some reason, I still have the original 1419x1419 image file exported from photoshop which seems to be kinda missing from the internet so it's a good thing I have been holding onto it since 2019

ill probably include it in my next pull request to the website

Also same critique as software_support.md applies: plugins and default first-party support need to be clearly separated.

On by default, behind flag/included plugin, third party plugin

"Should" is a bit too adamant. I think rewording it to "let's be proactive in case google lawyers wake up" would be more productive. Current wording can be interpreted as "it's incovenient for our sites, and it's against the rules anyway, so change it".

I made a simple one that should help to avoid the confusion

Thanks for pointing this out, I made a quick fix modification of that logo, if they come up with something else that is more clearly distinct from the Chromium logo I'll replace it with that.

It looks like that svg is a poor vectorization, I assume the original was a raster image?

what is watersplash ?

yes it was, here is the original file if you are curious to what it's normally supposed to look like. from what I remember it was a icon created by a community member and was apart of a vote around 2019 or so

ill probably create a proper set of optimized PNG, WebP and JXL for it at some point

I thought waterfox was the blue foxy one

that's firefox nightly

I'm adding names to the icons because that seems to be useful 🙂

thanks for the suggestion, did that

<@794205442175402004> what settings did you use when generating the JXL versions of the logos on the "Why JXL" page? I'm asking because I want the encode settings to be somewhat consistent between the ones you generated and the ones I'm gonna generate for the page.

I used -e 9, sometimes with -g 2 if it's an image that is between 256x256 and 512x512

And -d 0

wait doesn't -d 0 map to lossless? because most of the logo JXLs are lossy

are they? I thought I used lossless for both the webp and jxl alternatives to the png

I haven't checked all of them but yeah most of the JXL versions of the logos are lossy

at least the older ones are I haven't checked the new ones

looks like the pale moon one is lossy, the rest looks lossless to me

most are svg

if the intention is to have all of the raster images be lossless then I will check and make sure they all end up as such in my next pull request

doesn't have to be lossless as far as I'm concerned, that just seemed to make the most sense to me since they're not photographic

ah so a mix would be fine, like lossless for most and lossy for the nosiy ones like palemoon

for the waterfox logo it would be nice to have a clean svg that has gradients instead of that bandy mess — but I guess there's no easy way to get that

yeah I'm probably gonna switch it out for a high quality raster version although some of the other logos I have found proper SVGs for such as: - firefox nightly - affinity 2 - gdal

btw are there other linux distros besides OpenMandriva and KaOS that have jxl support out of the box (say in their most default install)?

I know very little when it comes to linux stuff in general but someone in this server probably knows

quite strange, if I use the extension "Jpeg XL Viewer" almost half of the images does not display <:Hmmm:654081052108652544> By disabling it I can see all the images

I haven't used that extension much at all but from what I have heard and seen it has a lot of problems

at least when a JXL image is displayed on a website it works <:dogelol:867794291652558888>

the images that work are svgs, so it just doesn't work at all it seems

maybe file a bugreport for that extension?

the whole point of using the picture tag is that it works regardless of what formats are supported, so if that extension breaks that, it's doing more harm than good

why is apple listed under operating systems? maybe a category that lists companies backing the project and supporting it?

it's meant to represent the other apple OSes (iPadOS, watchOS, visionOS)

i see, but at a first glance it's not necessarily obvious

at first glance it indicates Apple ecosystem support which is a clear and obvious implication imo

feel free to suggest ways to make it clearer, I couldn't come up with anything

The Editor of ImageEngine (an image optimization and CDN service) tested jxl on their service and is very impressed by the quality and size reduction as compared to AVIF. https://mastodon.social/@jonarnes@mastodon.online/110514451957959910

nice to see independent confirmation that jxl actually does bring advantage even over avif

Safari adding support will lead to more people giving it a try and finding out for themselves

I know the images are probably smaller than it anyway, but any reason not to blanket use -g 3 on most images?

I'd be careful with that extension, I had to disable it due to a bug that uses all available RAM and CPU cycles until chrome forcibly closes the page citing lack of memory. Still not sure what causes it, but there's already an issue for it too

on some images, -g 1 does compress better (since it can adjust local RCT and local palette better), and it also allows faster decode when using multiple threads...

Ahh, right, I didn't realise it could do palette per group

what is the behavior of "-g -1"/"default"?

Iirc it's basically g 1 except if the image is only a little bigger than 256x256, then it still does it as a single group (so g 2 in that case)

But that logic might of course change over time, if we find better strategies. E.g. at higher effort it could make sense to sample the image a bit and pick a group size based on some image statistics...

It is a bit janky! I wish there were a lower‐level way to handle images in browsers, but there just isn’t as far as I know.

Maybe try building and using the Git version too, if it isn’t too out of the way for you.

I'm used to compile stuffs, but never tried an Web-extension and don't really want to <:dogelol:867794291652558888>

https://blog.devgenius.io/jpeg-xl-the-revolution-in-image-compression-formats-that-even-apple-cant-ignore-ca4e8c3c6669

> Unlike JPEG XL, AVIF is subject to patents and is controlled by The Alliance for Open Media, of which Google is a member. This key difference, according to the codec documentation website, is one of JPEG XL’s strengths, as it is free from patent constraints and doesn’t require proprietary software. well that's false

I think people confuse HEIC and AVIF

The HEIF container which they both use is patented by Nokia and afaik they have not made it available royalty-free — but I suppose everyone is assuming that containers cannot be patented so it's nothing to worry about.

The HEVC payload of HEIC is heavily patent-encumbered though (and license fees are being paid), while the AV1 payload of AVIF is royalty-free, just like JXL

people generally don't get that difference though, I wonder if AVIF used a custom container

I never wanted to use the HEIF container for JXL, not just because it's so verbose (~300 bytes header overhead in the best case, more if you also want alpha), but also because I don't want to take risks with those Nokia patents

> This project, which spanned over four years, involved the authors of the original JPEG and Google. This is not correct. None of the authors of the original JPEG were involved in the creation of JXL. I think all of those people have retired by now.

The JPEG committee was involved of course, but the most senior members of that committee are from the JPEG 2000 days, not from the JPEG 1 days...

Journalists are paid to write something, not something true

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

Lotta comments from people who have only compared them at low bit rates.

It's tempting to lower the quality until you can clearly see the artifacts, and then compare codecs in that region of the quality spectrum. Nothing wrong with that either, but you cannot extrapolate codec comparisons outside the range you actually tested: if at 0.2bpp the avif looks better than the jxl, then you can "just give both codecs 5x more bits" but it doesn't mean that at 1bpp avif looks better than jxl...

So you have to compare them at the qualities (and in the viewing conditions) you actually want to use, not at the qualities (or viewing conditions) where it's easy to spot artifacts...

Zoom in and see the difference, not generate the difference yourself

Some zooming is fine (say 2x or 3x), because that also happens in reality (e.g. people doing pinch to zoom on a phone, or just getting closer to the screen), and because screen densities differ anyway. Zooming 20x though will reveal stuff that is probably not very relevant for normal viewing conditions. Or rather, if you want to be visually lossless at 20x zoom, you probably better just use actual lossless...

https://opennet.ru/opennews/art.shtml?num=59276

That's cyrillic, so it's probably wrong spacing of fallback font

For me all cyrillic characters are bold. Discord is just broken.

mine seems okay, Windows 11, desktop app

Many proponents of jpeg2000 in the comments.

j2k is pretty nice as far as image formats go, it kind of has all features jxl has, except no lossless jpeg recompression, only suitable for photographic images, and worse compression

if j2k would have gained traction, then lossy webp would have nothing at all to add

the main problem imo with j2k was that it took until April 2014 before the first usable fully conforming FOSS implementation was available (OpenJPEG v2.1)

that's 15 years where the only really usable implementations were proprietary software — there was FOSS software before but it was either incomplete or very slow, so not really usable in practice

I think that was ultimately the reason why of all browsers, only Safari added support for j2k, and of all the use cases of images, j2k only really got traction in those domains where things are expensive anyway so adding some software license cost doesn't make much of a difference (digital cinema and medical are the two big examples of that)

internally, JPEG XL can use palettes, which are like "indexed color" but that's internal as a coding tool, it's not like PNG or GIF where the format explicitly exposes it

I think they're somehow using arm32 binaries while the actual hardware is arm64, or something

Which makes a huge difference

That one Chromebook also uses a 2015 MediaTek SoC, which have pretty bad floating point performance.

Is Avif faster than jxl on mac? How?

They included progressive JXL... Then only show the complete decode results...

For decoding, avif and jxl are not really different. It's mostly in encoding that there's a huge speed difference.

Note that they use 8-bit 4:2:0 avif, which is the fastest possible case for avif.

and they're not testing the 'raw' decode speed, they're testing the speed of the chrome integration of the codec

they have specialized fast paths for 8-bit 4:2:0 avif, while for jxl the integration just uses the same high-precision code path for all images

what they're also not taking into account is that jxl decode is streaming (it starts when the first bytes arrive) while avif decode is non-streaming (it starts when the whole file has been transferred)

and also that jxl decode is progressive and incremental (it will show gradual refinement and partial data) while avif decode is not progressive and could in principle be made incremental but I doubt anyone is going to add the hooks for that to dav1d, it's a lot of work

Possibly outdated libjxl, incorrect measurement of results, unfair testcases

Mostly just measuring something that is not that relevant

Basically avif is an airplane that takes millions to build and can go 50km/h, but first everyone has to go through security, board the airplane, etc before it can even take off. And jxl is a cheap e-bike that can go 45km/h. WebP is a train that goes 60km/h and JPEG is a motorcycle that can go 90km/h but it cannot go to some places (like places in the province of Alpha).

And then they make the point that 50km/h is faster than 45km/h so clearly the avif airplane is superior.

<:PepeGlasses:878298516965982308>

Hype news

I think it'd be great if a small blog post could be written, then everyone can point to that

https://blog.desdelinux.net/apple-ya-admite-el-formato-jpeg-xl-en-safari-y-ademas-presento-un-port-de-wine/

https://gigazine.net/news/20230613-jxl-against-avif/

Writing a blog post about jpegli right now, and I wrote this regarding AVIF's inability to parallelize well: > I found this anomalous behavior interesting as it highlights avifenc's trouble with scaling that stems from issues with the AVIF image format. I would wager a guess that this scaling issue is because of AVIF's use of certain intra-frame coding techniques like directional prediction that share data between blocks, theoretically improving coding efficiency but reducing paralellization & worsening generation loss. If I recall correctly, JPEG-XL specifically avoided intra coding techniques like these in order to paralellize effectively (and improve resilience to generation loss) Is this all relatively correct information?

I think so. At least jxl doesn't have directional prediction and its groups are by design independent to allow both parallel encode and decode.

Ok thanks!

https://giannirosato.com/blog/post/jpegli/

great article <:pepelove:674256399412363284> it's just that having speed in `ms` is a bit misleading

This article says that using XYB with jpegli increases the effective bit depth to 10 bits, but I recall Jyrki saying something on Twitter which I thought implied that it achieves an effective 10 bits even without XYB.

yes, we’ve had success with PQ/HLG in jpegli

banding with traditional encoders/decoders, no banding when jpegli is used throughout

(jpegli enc → non-jpegli dec ⇒ still banding since the decoder would typically throw out the additional precision, but less so with P3+HLG than with Rec. 2020 + PQ)

most if not all browsers use libjpeg turbo for jpeg decoding which has from what I have seen has a massive amount of funding and backing from companies for security and performance so I'm not sure if browsers would want to jump over to libjxl for standard jpeg decoding

would be cool if it happened though

my dream is that eventually jpegli is merged into libjxl (adding an encode option to libjxl for 'compatibility mode' where it produces jpeg output or a jxl that can be reconstructed to jpeg, and where libjxl can just decode jpeg directly)

and at that point applications like browsers can just use libjxl for everything

> yes, we’ve had success with PQ/HLG in jpegli > banding with traditional encoders/decoders, no banding when jpegli is used throughout very cool. Are there any reasons to still try for XYB JPEG? And for this PQ/HLG stuff, what level of color management support is needed? ICCv4.0?

for true HDR, v4.4 / reading the cicp tag

(almost called it cICP like in PNG)

is that because ICCv<4.4 does not say anything about brightness?

(as in max-nits)

I was thinking of earlier when you linked the PQ and HLG PR in reponse to this > The ones produced by libjxl aren't very compatible with legacy decoders and viewers, unfortunately, since you get a washed out picture without CICP support, rather than a correct SDR rendering.

I may have misunderstood something

ICC profiles generated by libjxl now (since https://github.com/libjxl/libjxl/pull/1890) encode a fallback tonemapping in the A2B tag, which should work at least with ICCv4.0 CMSes

not sure about v2

right, whereas v4.4 lets you say “this is PQ” (but not yet the actual max luminance found in the image, AFAIK) or “this is HLG” (where there is no such thing)

Ok, that it'll look correctly on SDR systems that won't tonemap on their own due to not recognizing the cicp tag is what I wanted to know, thanks :)

it’s at least the intent, let’s see if it works out that way 😁

🙏

it’s not the best tonemapping ever but probably better than nothing

and it seems to work at least in eog

well, at least better than nothing for PQ

for HLG, “nothing” actually performs quite well, by design

which makes it possible for ours to be worse 😂

if we consistently find that ours does worse than nothing, we can always try to do something about it (even emulate something closer to that nothing)

<@703028154431832094> some typos: "JPEG became supposedly became competitive" "indicitive"

Oh darn my bad

I’ll fix em once I’m at my computer, thank you so much

"cieling"

Btw I dunno about these images but I often see libjxl e6 perform basically the same as e8, just a lot faster.

While for libaom there are bigger gaps between each speed setting

I consider libjxl e8+ too slow for practical usage (and not worth it). For libaom it depends on the use case but generally slower speeds than the default s6 are too slow to be usable in practice.

Alright, I'll keep this in mind. I can replot with lower speeds, I usually stick with high speed stuff because my system can handle it

Something like comparing JXL speeds would probably be better suited to a deep dive blog post, in this case JXL & AVIF really were only included to be 'pace cars' for the older codecs

fixed, among other typos

I meant higher speeds might be more interesting, say jxl e6 and avif s6 or s7

I think they'd still wipe the floor with jpeg/webp

The speed graph would certainly look different I'm sure but that's probably a blog post for a different day

https://dev.to/robole/safari-goes-all-in-on-images-c4m

I think the software list on github is a bit old and missing a bunch of software

In my Photoshop I can open jxl fine, and it's via camera raw (but that just works out of the box)

Saving jxl is not really convenient yet, you can do it via the camera raw dialog but not via the save as or export dialogs

https://support.imageengine.io/hc/en-us/articles/16739209580301

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

> For most images, JPEG XL will be a better choice when considering visual quality and file size. 🎉

<:Hypers:808826266060193874>

My article :D not as popular as the last two though

https://pdfa.org/its-time-to-update-pdfs-imaging-model/

Oh, if they could make something like pdfx, i.e. zip(xml + resources in separate files).. And for sure use jxl as the only format for bitmaps (well, excepting 1 bpp images, maybe)

Why zip?

Why not? Actually Office formats like docx, xlsx, etc are zips, and I believe it (old zip) was chosen by two reasons: - it does not support solid archives, so each file is accessible without unpacking all previous from it's block - patents As for me - I'm against using old zip in 21 century, but..

If it is a zip file, is it possible to read pages progressively? Example like on browsers you can read pdf pages without fully receiving/downloading.

For that you'd need a progressive zip file

Does it exist?

Well, I see your point. For me important is to have all binary streams (fonts, images, etc) as files. It's just a dream, I know 😔

Well, the point of zip is to serve everything as one file, usually compressed. If you want a single file from it, might as well just serve that single file seperately

But the idea of pdf is to have all things in one file. I just don't like the way they do it 🙂

Yeah

you could compress each file separately and have an index for seeking

you have reinvented zip

you could theoretically read zip progressively, but there are a few problems: 1. the index is at the end (like non-faststart mp4) 2. you need to add the files to the zip in a convenient order for range reading 3. the document text is not interleaved like pdf (i.e. it is text, image1, image2, etc, instead of page1text, page1image1, page2text, etc)

https://youtu.be/1wmJzcJWa8M?t=5609 WordPress panel Q&A. tl;dr: AVIF and JPEG XL browser support is not there yet, JXL is not on PHP, AVIF is, but demands PHP versions that are too new. Webp support on php and browsers is good.

https://linuxfr.org/news/des-formats-d-image

is that right?

> JPEG is supported by all browsers and all image display and processing software. That said, this format is no longer of any interest for most common uses, and can be replaced by WebP for new images. I disagree, WebP does not have high-quality lossy, cannot do large images, and does not do CMYK nor progressive. I cannot really think of any use case where it _completely_ replaces JPEG, though it does complement it.

(quoting the English translation for convenience)

Besides being a bit too much in favor of WebP to my taste, it otherwise looks correct to me.

so we did finalise it in 2022? I wasn’t completely sure 😁

Bitstream was frozen end of 2020, but it took until 2022 before the first edition of the spec was published.

you have something to add ?

not specifically, I have just kind of lost my perception of time in the last ~3 years

Was really 3 years ago now? Crikey.

Not quite, summer of 2020 we were still busy removing brunsli and refining modular mode. But yeah, time passes quickly. FUIF is already 5 years ago, first versions of FLIF about 12 years iirc...

https://cohost.org/reth/post/1729206-just-tried-jpeg-xl

https://web.developpez.com/actu/345394/JPEG-XL-Apple-adopte-dans-Safari-le-format-d-image-sans-redevance-que-Google-a-abandonne-L-editeur-de-Chrome-subit-la-pression-des-utilisateurs-qui-lui-demandent-de-revenir-sur-sa-decision/

https://www.macrumors.com/2023/06/28/apple-releases-safari-technology-preview-173/

I just tested and there's no JXL support on Ventura despite Safari 17 supposedly having it, I guess you need to be running the Sonoma beta if the file format support is baked into the OS. I would rather not run beta OS on my main computer 😬

yeah it doesn't work for me either with `Release 173 (Safari 17.0, WebKit 18616.1.20.2)`

(on Ventura)

but I see there's already a bug open about it: https://bugs.webkit.org/show_bug.cgi?id=258655

it does send `image/jxl` in its Accept headers, but it only shows broken image icons...

Lol @ this thread: https://twitter.com/bonusi2/status/1675869050360983553?t=4_vG2rkoW-EnA1oIYmVLGA&s=19

JPEG XL the anime when?

ChatGPT writes a JPEG XL anime

https://www.youtube.com/watch?v=Kd5YzuhyX7Q

Brief but accurate > It's good, but needs more support

he missed how BMP can contain jpeg and png

BMP is just Windows's image data structures dumped to disk, isn't it?

Yeah I think it’s just raw bytes without any compression

it can have compression

https://en.wikipedia.org/wiki/BMP_file_format#:~:text=The%20compression%20method%20(offset%2030)%20can%20be%3A

(of course, why would you do that)

It's a bit like TIFF

those windows data structures can hold compressed data, so so can BMP

Ah interesting. Maybe MS Paint just never supported it. Because those BMP files are huge

Most BMP that you see are uncompressed.

ICO is also just a container for a few images with different sizes, and Windows supports PNGs inside (since Windows Vista), and huge 256x256 icons are actually almost always PNG

https://fstoppers.com/education/jpeg-killer-file-formats-could-replace-humble-jpeg-636116

Another photographer discovers JXL

This is just a retelling of https://discord.com/channels/794206087879852103/822105409312653333/1126176373589946478

Weird Image Formats

new blog post on XYB jpeg, gonna do this

https://giannirosato.com/blog/post/jpegli-xyb/ Let me know if any of the information is incorrect, especially around color spaces - I'm very new to that stuff. Otherwise, XYB JPEG blew me away!

jpegli decoder and 16-bit buffers can also give different results compared to libjpeg(-turbo), mostly better, but not always ```Encoding BPP Max norm SSIMULACRA2 ---------------------------------------------------------------------------- jpeg:q75 1.0707961 3.94535202 76.93353442 jpeg:q75:dec-jpegli:bd16 1.0707961 3.88703968 76.19583972 jpeg:q75:dec-jpegli 1.0707961 3.88499135 76.12901327 jpeg:enc-jpegli:Q75 1.0735062 2.20334738 79.23031704 jpeg:enc-jpegli:Q75:dec-jpegli:bd16 1.0735062 2.33431164 79.71602908 jpeg:enc-jpegli:Q75:dec-jpegli 1.0735062 2.33712830 79.68734939 jpeg:enc-jpegli:Q75:xyb 1.0726276 2.50501502 78.23824964 jpeg:enc-jpegli:Q75:xyb:dec-jpegli:bd16 1.0726276 2.21471253 78.58082449 jpeg:enc-jpegli:Q75:xyb:dec-jpegli 1.0726276 2.25944107 77.99690812 jpeg:q75:yuv420 0.8205214 3.94654643 74.72916305 jpeg:q75:yuv420:dec-jpegli:bd16 0.8205214 3.87399402 74.16625355 jpeg:q75:yuv420:dec-jpegli 0.8205214 3.89107391 74.11504435 jpeg:enc-jpegli:Q75:YUV420 0.8194998 3.20850482 73.78279640 jpeg:enc-jpegli:Q75:YUV420:dec-jpegli:bd160.8194998 2.99043864 73.63640285 jpeg:enc-jpegli:Q75:YUV420:dec-jpegli 0.8194998 2.98243546 73.52080141```

```jpeg:q90 1.9433379 2.44163524 85.53191736 jpeg:q90:dec-jpegli:bd16 1.9433379 2.52302231 85.05980006 jpeg:q90:dec-jpegli 1.9433379 2.53819058 84.88227213 jpeg:enc-jpegli:Q90 1.9398438 1.38918277 86.79130744 jpeg:enc-jpegli:Q90:dec-jpegli:bd16 1.9398438 1.24298972 87.52674184 jpeg:enc-jpegli:Q90:dec-jpegli 1.9398438 1.25997403 87.48061299 jpeg:enc-jpegli:Q90:xyb 1.9420873 1.21457097 86.55217407 jpeg:enc-jpegli:Q90:xyb:dec-jpegli:bd16 1.9420873 1.06661231 86.94676336 jpeg:enc-jpegli:Q90:xyb:dec-jpegli 1.9420873 1.21090088 86.46655768```

Oh interesting. Does the ssimulacra2 binary use dec-jpegli?

i'm using benchmark_xl

`benchmark_xl --input=xxx --codec=jpeg:q75,jpeg:q75:dec-jpegli:bd16,jpeg:q75:dec-jpegli,jpeg:enc-jpegli:Q75,jpeg:enc-jpegli:Q75:dec-jpegli:bd16,jpeg:enc-jpegli:Q75:dec-jpegli,jpeg:enc-jpegli:Q75:xyb,jpeg:enc-jpegli:Q75:xyb:dec-jpegli:bd16,jpeg:enc-jpegli:Q75:xyb:dec-jpegli,jpeg:q75:yuv420,jpeg:q75:yuv420:dec-jpegli:bd16,jpeg:q75:yuv420:dec-jpegli,jpeg:enc-jpegli:Q75:YUV420,jpeg:enc-jpegli:Q75:YUV420:dec-jpegli:bd16,jpeg:enc-jpegli:Q75:YUV420:dec-jpegli,jpeg:q90,jpeg:q90:dec-jpegli:bd16,jpeg:q90:dec-jpegli,jpeg:enc-jpegli:Q90,jpeg:enc-jpegli:Q90:dec-jpegli:bd16,jpeg:enc-jpegli:Q90:dec-jpegli,jpeg:enc-jpegli:Q90:xyb,jpeg:enc-jpegli:Q90:xyb:dec-jpegli:bd16,jpeg:enc-jpegli:Q90:xyb:dec-jpegli --save_compressed --nosave_heatmap --output_dir=.`

visually I prefer the jpegli decoder, even if the metrics don't agree

and for djpegli: `--bitdepth=8|16 Sets the output bitdepth for integer based formats, can be 8 (default) or 16. Has no impact on PFM output.`

it would also be nice if the comparison was on the most recent build, because https://github.com/libjxl/libjxl/pull/2660

oh shit

Darn, I may just bench that separately, that seems interesting

> The problem is color perception is non-Euclidian, & this is an impossible problem to completely solve. W. David Wright & John Guild were up to the challenge, however, & built the CIE XYZ colorspace to map more perfectly to our human visual system than prior attempts. I don’t think XYZ attempts to solve that problem at all

wikipedia has a paragraph on this: > An equal mixture of two equally bright colors will not generally lie on the midpoint of that line segment. In more general terms, a distance on the CIE xy chromaticity diagram does not correspond to the degree of difference between two colors. In the early 1940s, David MacAdam studied the nature of visual sensitivity to color differences, and summarized his results in the concept of a MacAdam ellipse. Based on the work of MacAdam, the CIE 1960, CIE 1964, and CIE 1976 color spaces were developed, with the goal of achieving perceptual uniformity (have an equal distance in the color space correspond to equal differences in color). Although they were a distinct improvement over the CIE 1931 system, they were not completely free of distortion.

I believe that the CIE 1976 colorspace is the “u′v′” one

(there is also L\*a\*b\*, also from 1976)

https://en.wikipedia.org/wiki/File:CIE_1976_UCS.png

Isn't that the goal of every perceptual color space, though?

as far as I know, the goal of XYZ was “spectra have the same coordinates if and only if they look the same” and that’s it

(well, that and “Y = luminance” and “all matching functions are positive everywhere” (unlike CIE RGB))

(relevant reads on the subject include https://www.wiley.com/en-gb/Colour+Reproduction+in+Electronic+Imaging+Systems%3A+Photography%2C+Television%2C+Cinematography-p-9781119021773 and https://www.wiley.com/en-gb/Color+Appearance+Models%2C+3rd+Edition-p-9781118653104 )

<:FeelsReadingMan:808827102278451241>

I'll look into this after work, I just read the Wikipedia

> In an ideal perceptual color space, the distance of two points in the space would correlate strongly with the perception of color difference. Put another way, all pairs separated by a “just noticeable difference” would be separated by an equal distance. > As it turns out, such a thing is no more possible than flattening an orange peel, because color perception is inherently non-Euclidean. To put it another way, the ratio of perceptually distinct steps around a hue circle to those directly across through gray is greater than would be expected as a circle in an ordinary Euclidean space. > Even so, like map projections, it is possible to make a color space that approximates perceptual uniformity and is useful for various tasks. One of these, a primary focus of this blog post, is smoother gradients.

Via https://raphlinus.github.io/color/2021/01/18/oklab-critique.html

https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-going

am I missing something or is the difference between the two yellow plots not explained?

I think "The dotted lines use 4:2:0 chroma subsampling (yuv420) while the full lines use 4:4:4 (yuv444)"

But I agree that a legend on the side of the graph would be so nice 🙂

does this mean i wont have to keep using JXLook on mac? It's nice but there is the problem of zooming in an image in QuickLook.

Yes, in the next macOS jxl will just work out of the box in Preview and anything else using OS-level image io

NICE!

I think JXLook doesn't support >8 bit color depth

Kinda ironic, but images on cloudinary don't load for me on Firefox. Already disabled any adblocker

it's loading for me, and I'm using firefox

it's delivering AVIF

Yeah, it has to be me. But I wouldn't know what's wrong

Looks fine in Edge

what headers are you sending?

``` GET /cloudinary-marketing/images/c_fill,w_759/f_auto,q_auto/v1688666201/Blog-jpegXL/Blog-jpegXL-jpg?_i=AA HTTP/2 Host: res.cloudinary.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 Accept: image/avif,image/webp,*/* Accept-Language: en-US Accept-Encoding: gzip, deflate, br DNT: 1 Connection: keep-alive Referer: https://cloudinary.com/ Cookie: __cfruid=d55a8dab744993f1426f8459add1a8e5f80e1bec-1689705275; cf_clearance=UYabN.KDTUkeJUD8s25Pj1iRvsjo4eKyh_EjFx4PmoI-1689705355-0-0.2.1689705355 Sec-Fetch-Dest: image Sec-Fetch-Mode: no-cors Sec-Fetch-Site: same-site Pragma: no-cache Cache-Control: no-cache ```

this is what my browser sent

I get a jxl file delivered it seems. ```content-type image/jxl```

ah, you probably have JXL images enabled in nightly

or not nightly exactly

but there's a firefox bug where it can't read jxl but will send the accept header if you have it enabled

Yeah, that must be it. I don't run nightly (afaik) but might have messed with my settings before.

about:config and search jpegxl

probably enabled

(or maybe jxl)

yeah. it's jxl. I was searching for jpegxl and it didn't show the flag. Now it's delivering avif and displaying them correctly. https://jpegxl.io/#blog didn't say my browser supported JXL. Their detection seems to work differently.

they probably scrub the user agent

Thanks for the tech support 😅

Cloudinary respects Accept headers

Firefox still has the bug that it claims to accept jxl if you enable the flag, even though it doesn't (except in Nightly)

kind of crazy that that bug is still not fixed by now

yeah, just disable `image.jxl.enabled` if you aren't on nightly, Waterfox, or Mercury

or you could use waterfox

I was thinking where JXL would fit in the "Extented to/Extended from" link under JPEG, since it's technically built on a lot of different formats

https://dennisforbes.ca/articles/jpegxl_just_won_the_image_wars.html

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

amazing how bad discussions on hacker news always manage to be

> Meanwhile, "JPEG XL" is at best an incremental improvement over "JPEG 2000" from the user's POV, what?

> JPEG XL even bests PNG at non-photorealistic content like charts and figures I guess this person wasn’t aware that lossless webp is actually pretty efficient

Ehh, I'd say it's fair to compare against the most widely used formats

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

seems like here, all anyone can talk about is JXL, so there's definitely still a lot of excitement

Huh, Firefox on Android doesn't support icc profiles

it does on my end

fixed it, gfx.color-management.mode flag was set to 0, changed it to 1

odd

I swear Firefox on Android failed the ICC profile test, so I switched to Chrome, then tried it again and suddenly it worked.

no idea how that happens

Firefox was like “oh no, they're going to switch to Chrome if I don't do something”

all this talk about icc profiles and browsers reminded me of this golden post https://bugs.chromium.org/p/chromium/issues/detail?id=784713#c31

funny, this test https://cameratico.com/tools/web-browser-color-management-test/ says my firefox supports ICC v4, but this one https://littlecms.com/blog/2020/09/09/browser-check/ says it doesn't...

yup, the little cms test is much harsher

it uses a lot of extra features of iccv4

because recently ff disabled clut

recently as in last year <https://phabricator.services.mozilla.com/D159273>

oh but that's for output profiles...

oh yeah it's just because qcms is pretty incomplete

ff should have stuck with lcms

but they just had to make it use rust

qcms was originally written in C

https://www.brycewray.com/posts/2023/07/hoping-new-chance-jpeg-xl/

lol.

https://mailchi.mp/uab.cat/last-months-to-apply-to-global-data-compression-competition

the webpage https://gdcc.tech/ is down at the moment, but they have a category for lossless jpeg recompression — it would make sense to submit jxl to that, as an anchor.

Likely other submissions can get better jpeg recompression performance than jxl, if they do not care about features such as streaming/progressive and parallel/cropped decode, which are nice to have in an image format but maybe not really needed in an archive format. But it would be nice to have jxl in there...

There will always be some super specific niche codec tuned for one use case that will outperform JXL, AVIF etc

Having a jack of all trades that is actually supported is better

Does anyone understand Portuguese? 😅 https://youtu.be/Lwl4RFcd1Wc

You can use OpenAI Whisper to get subtitles. It's very good with Portuguese.

I've been having issues with whipser since id been looking into it as a way to automatically generate subtitiles for olive. I wonder if it has improved

It's basically useless: maybe one in ten words is correct translation of transcription. Also many videos don't even have auto-CC.

they just summed up the Cloudinary article, JXL history, and discussed the implementation on Apple

https://gigazine.net/gsc_news/en/20230724-jpeg-xl/

John Snairs, lol

Almost 😅

The reason could be the auto translate from Japanese 😑

I've been called "Luca Vasari" by Italian news 😛

https://en.wikipedia.org/wiki/Giorgio_Vasari

ジョン・スナイアーズ in the original article, could be retro spelled jon sunaia-zu

(u are mostly mute in Japanese)

Far from snairs though

I am aware xD

I was just quoting the journalist of gigazine... I don't know if NE would be more appropriate... Not native speaker here 😁

In IPA notation: /jon snɛijers/

The spelling is actually quite close to the pronunciation

Japaneses have a long tradition of slaughtering prononciations 😅

no er sound

as far as I'm aware "Sneyers" rhymes with "Slayers"

Nah, the ɛi sound is not that

maybe you pronounce "slayers" differently than an American does

It's not the "ay" sound like in "say" (/e/, like the French é), it's the "ea" sound like in "bread" or the "ai" sound in "said" (/ɛ/, like the French è) but longer and diphthonging into /i/.

odd, I hear “say” as ɛ

but indeed, the wiktionary and the cambridge dictionary agree with e

https://dictionary.cambridge.org/pronunciation/english/slay

😅 Don't worry too much about a language which transcribe love as *rabu* and Mac Arthur as *makkaasaa*

the original Japanese names of https://bulbapedia.bulbagarden.net/wiki/Articuno_(Pok%C3%A9mon), https://bulbapedia.bulbagarden.net/wiki/Zapdos_(Pok%C3%A9mon) and https://bulbapedia.bulbagarden.net/wiki/Moltres_(Pok%C3%A9mon) are in English

bulbapedia transcribes them as “Furīzā” (freezer), “Sandā” (thunder) and “Faiyā” (fire)

in French, they went for ancient gods: Artikodin, Electhor, Sulfura

(the French translations for the first 151 Pokémon are explained here by their author https://www.liberation.fr/apps/2016/06/pokemon/)

https://youtu.be/2eIeoIfYoL4

https://bugs.chromium.org/p/chromium/issues/detail?id=1451807#c21 > At this point it seems more likely a political issue and the team refuses to stand up for standards that the community decides upon. > > This isn't rocket science, and sometimes, just sometimes, it's better to skip the process and do the not-brain-dead thing and _reopen the dang issue_. *deleted* <:KekDog:805390049033191445>

to be fair, doesn't seem the most constructive comment 😛

on the other hand, it is some truths

ofc it wasn't the best way of saying it

https://dev.to/jonarnes/get-ready-for-jpeg-xl-today-204j

oh another one: https://bugs.chromium.org/p/chromium/issues/detail?id=1451807#c22 > Chromium is the only browser that has no jpeg xl support, even with experimental flags. > this is absurd and needs to change. > I'm pretty sure google just want to force people into using webp instead. I mean, yeah I understand their feelings (and have the same), but if we gonna "attack" Google with this kind of repetitive messages, it could perhaps lead to a worse situation ?

on the other hands, perhaps saying these things is needed...

No idea what is the best approach, just keep it respectful and polite, and no need to make conspiracy speculations. Just asking for feature parity with Safari is enough.

If Chrome wants to force anything it's avif, not WebP at this point.

People forget it's a bug tracker, not the YouTube comments

Seems almost copy pasted from here <https://support.imageengine.io/hc/en-us/articles/16739209580301-JPEG-XL-jxl-in-ImageEngine> And a shame there's no mention of the double PNG savings on average

yes. before commenting, it would be nice if people could ask themselves “what will my comment bring to the discussion?”

if the only information that the chrome people will get out of a comment is “there exists one person who is angry about this” , maybe it’s not worth posting

and the speculations about the reasons for their decision (circumstantial ad hominem) are out of place in any case

(on a bug tracker)

(I’m not saying people can’t write blog posts about their speculations)

It's probably better to offer chrome devs a way to add jxl support without losing face than to make them look evil and demand they now admit their guilt.

yes, face is considered central to social interactions https://en.wikipedia.org/wiki/Politeness_theory

I recently rediscovered an old gem https://chipsandcheese.com/2021/02/28/modern-data-compression-in-2021-part-2-the-battle-to-dethrone-jpeg-with-jpeg-xl-avif-and-webp/ and a tech blog

I could be wrong or it could've been a bug in the old encoder, but it's strange that it has such high filesize yet still lowers the bitdepth from what I can tell (Blacks turn to greys with blocking artefacts)

> WEBP encoding and decoding is also super fast compared to AVIF and JPEG XL. > > All in all, WEBP is a better format than JPEG and has close to 100% browser coverage by now. An OK choice for most cases. hmmmmm...

I mean I don't see much wrong with that statement, there are cases and features that JPEG has over WebP but recommending people to use WebP as something that is relatively fast and most browsers support is fine besides they say/state that it's an "**OK** choice for most cases"

All that talk about face... Gives me Chinese Xianxia flashbacks

Sounds like you are looking at the decoded PNG sizes and metadata wasn't restored from the original.

WebP being an OK choice for the web is true for 80% or so of the cases. It's always better than PNG for SDR web use cases. For low to medium quality, it compresses a bit better than JPEG at the cost of no progressive.

Probably, I'd guess the comparison site they used only shows the uploaded file's size instead of being able to set the actual format's size

progressive loading and focused priority decoding of interesting areas sounds like a huge deal for image-based ad displays and image webhosts in particular

with quicker display and less storage/bandwidth consumption, it should be possible to significantly increase profitability or make profitable services/subscriptions that were in the red

https://ieeexplore.ieee.org/document/10205928

Does anyone have a pdf copy of that web page?

not one I’m allowed to share, I’m afraid

> JPEG XL has improvised compression efficacy and image quality

unfortunate typo

i love improvisation

i once tried to record myself playing a piece I composed myself (the only piece I bothered actually writing down), this one: https://sneyers.info/jon_old/music/pf.pdf

here's the recording: https://sneyers.info/jon_old/music/pf.mp3

first 3 and a half minutes are kind of faithful to the score

and then the score ends and I just keep going for another 4-5 minutes or so, improvising 🙂

some of my favourite music was improvised

but not JPEG XL’s image quality 😁

or was it 🤔

I suppose lossy encoder heuristics are a kind of improvisation in some sense

it feels like lilypond was used 😄

correct

https://twitter.com/lafibreinfo/status/1693246855784579447?t=H1ORPNHhiuO61uOeWZ8i-Q&s=19

Isn't that A - E rating from food nutrition scores? <:KekDog:884736660376535040>

XD

yes, quite funny to use exactly that scale

E makes fat files 🙂

> JPEG XL est un format ouvert et libre de droits qui permet la compression d’images fixes avec ou sans pertes. JPEG XL n'est pas basé sur un codec vidéo. JPEG XL est une combinaison de deux formats d'images récents : Pik et FUIF (ne les cherchez pas dans le tableau, ils n'ont pas été publiés, ils ne sont donc pas présents). FUIF intègre lui-même les travaux de FLIF qui est lui dans mon tableau. > Compression : JPEG XL compresse de 10 à 15 % de plus que AVIF, à des réglages de vitesse d'encodeur où l'encodage JPEG XL est d'environ trois fois plus rapide qu'AVIF. Les gains de compression sont bien sûr plus élevés par rapport à WebP (environ 20 à 25%) et MozJPEG (environ 30 à 35% - notez que MozJPEG étant lui-même 10 à 15% meilleur que les encodeurs JPEG typiques comme libjpeg- turbo). Source > JPEG XL est conçu pour être plus efficace que les formats existants et il intègre toutes les fonctionnalités de l'AVIF. JPEG XL vise à remplacer les formats existants pour tous les usages courants (et pas uniquement pour le web). → > JPEG XL is an open, royalty-free format for compressing still images, with or without losses. JPEG XL is not based on a video. JPEG XL is a combination of two recent image formats: Pik and FUIF (don't look for them in the table, they haven't been published, so they're not present). FUIF itself integrates the work of FLIF, which is in my table. > Compression: JPEG XL compresses 10 to 15% more than AVIF, at encoder speed settings where JPEG XL encoding is about three times faster than AVIF. Compression gains are of course higher compared to WebP (around 20 to 25%) and MozJPEG (around 30 to 35% - note that MozJPEG itself is 10 to 15% better than typical JPEG encoders like libjpeg- turbo). Source > JPEG XL is designed to be more efficient than existing formats, and incorporates all the features of AVIF. JPEG XL aims to replace existing formats for all common uses (not just the web). <:Hypers:808826266060193874> and quite interesting table (in French)

I've also never heard of HiFiC https://hific.github.io

it's not exactly production ready

I don't really understand what that means 😅 I shouldn't use it because bugs are expected to happen?

it's *very* slow

as in, 10000x more compute/pixel than JPEG XL

of course, on a G/TPU it's fine

but I don't think anybody is under the impression that this is a codec you should actually *use*

don't generative codecs require humongous coefficients tables to be decoded ? what you win in the file, you already lost it in the decoder ?

decoder is pretty big, yeah

I am not sure that's strictly needed though

Just need to put this somewhere to test it

I jammed that into the slide comparison on the site, not bad for such a low bpp image, although obviously highr is better for JXL

No is not good

Use this

HiFiC is for images, not videos <:KekDog:805390049033191445>

Who firkincz downloads Britney Spears images?

Use those settings at Min 82 max 140 with max gr 23 and cpu 0

And will be better than any Jon Sneyers encoder

>jpeg on Compare preview not webp not avif

the plot thickens: cambridge says “e” is the sound in “head”

but there, the wiktionary agrees with me (and not with cambridge) that it’s /ˈhɛd/

>not webp *good*

Why hate webp 🧐

because my Android phone doesn't even support it <:PepeHands:808829977608323112>

Android phones should support WebP by now.

apparently, full WebP supposed was added in Jelly Bean, over 10 years ago.

the preinstalled (OEM?) image gallery app doesnt necessarilly. format support differs amongst those

Google Photos should support WebP images though.

My last phone (Samsung S8) didn't have most of Google's apps pre-installed. I guess TheBigBadBoy might have an older phone with all OEM apps.

oh, I have installed LineAgeOS (Android 11), with microGApps I really didn't know webp was supported by Android, because the default gallery image does not (as well as many music players I tested with webp cover arts) :/

my bad for saying dumbshit then...

Must be AOSP apps being outdated as usual then.

Android even supports webp app icons.

I hate when people say "android supports" and then proceed not to say the version in which support was added.

it's a "works on my machine" all over again

windows supports tar, zstd, 7z, and rar

With slow decompression speeds and no progress bar.

im not surprised, webp is well, webp, implementations are buggy as always, I know some apps disabled it out right because of that

its a shame aves is kinda annoying to use because of the nomedia stuff because it would otherwise be a really good app

why do you not like these encoders fab

Poor quality for square images as is color blind by design and it relies only on the space by not using transform

Its meant for camera

because of XYB?

Fab is speaking a language which I couldn't understand

it's called Italian

This is the only language I know https://282fd5fa7.github.io/LACE/

And also speak daily