JPEG XL

Meta loves jxl

i thought you meant serving JXL

Well, that too. I'm pretty sure instagram might be one of the first adopters of the format

They could already be saving some money by serving it to apple users.

And they have all the capital they need to trailblaze

could anyone check on mac safari or a jxl supporting fork

I think the iOS photo picker transcodes to JPEG92

Every new format's early adoption on the internet is always for thumbnails

JPEG XCII ?

JFIF

Okay and? TF? Not sure about you, but i don't have time to sit there and code out a Github profile that makes me absolutely no money. Wild you trying to come for me about using AI in the literal pioneering days of AI. Just because you have a skill issue, doesn't mean others do. Keep your ego in check and have a good day.

<:weirdge:778473410341896222>

ANYWAY back to business. This is what the dev of this app said but I'm not a dev so not sure what exactly he's saying? Haha: Ima be honest I have no idea if I can even use this as an output without any of the the infrastructure or adoption in place. The application uses python so if your stuff isn’t in there it’s nearly going to be impossible based on my skillset to use it

His tool is built using python but he doesn't know enough code to incorporate a new output format - his words. Anyone know of a great GitHub to throw my way as a start for my research?

I'm not a python expert but does his tool use an image library like Pillow for example?

https://github.com/olokelo/jxlpy

Not sure yet, but I listed out a healthy list for a starting point: https://docs.google.com/document/d/1A7uuIsxstGbceDBJyNhSv9LBiGx-Kb517R30TZNLBoM/edit?tab=t.0#heading=h.c55u52m22dx

For those who dont use google

https://www.libvips.org/2017/09/01/libvips-for-Python.html

vips supports jxl output too.

As well as many other image formats

WAIT WTF I thought that it was idk backwards compatible. If he has built in support for JPEG, isn't that supposed to be one of the benefits that you can go back and forth from jpeg to jxl and back easily? Or am I misunderstanding that

So wouldnt he already basically have support built in?

vips doesn't support lossless transition of existing JPEG I don't think

You need to use libjxl for that, probably there is a python binding to libjxl

Or maybe not

But vips has a good python interface

Turns out they're using Cloudflare's image processing which doesn't currently support JXL, so it would be a heavy lift to add. <@794205442175402004> would they be a competitor of yours. Any insight into them supporting it?

<@826537092669767691> you work at Cloudflare, right?

jxl-rs might be prerequisite

jxl wallpapers approved for the upcoming Fedora 43: https://pagure.io/fesco/issue/3376

Nice to see that the other ticket specific to GNOME OS could be resolved as well

they shouldve generated and distributed lower complexity or standard effort lossless jxls

outputs from maximalist optimizing arent representative of the average user's typical experience

on an aside, seems there could be a freeze exception to get jxl part of base install for ubuntu 25.04 due this month (the gnome-based one - all other editions of *ubuntu based on other DEs seem to have libjxl preinstalled)

<@794205442175402004> quick Cloudinary question – what volume of each format do you guys currently serve per day now that JXL support has presumably grown? What is the most served format? (I’d guess WebP?)

The only reason they're switching to JXL is because of the space savings, so sacrificing the savings to fix decode speed would be pointless

Currently: 34% webp, 27% avif, 20% jpeg, 3% jxl

Gotcha - and you guys use libwebp for this, I’m guessing? And this volume (including JXL) is billions per day, right?

Total fluctuates around 15 billion images per day

And yes, we use libwebp

Gotcha

Could you look at the % numbers just for requests from browsers that advertise JXL support?

i suspect 3% couldve turned to 15+ % if jxl was sent at a higher priority than the other formats, given almost 40% of the phones actively used in us, canada, uk and japan run a version of ios+safari with jxl supported (according to caniuse)

About 28% of requests come from browsers supporting jxl, and of course we only send jxl to those, so about 10%. There is still plenty of room to make that a higher percentage, but it will take some time.

🤞

I forget, what's blocking enabling JXL by default? Just more browsers supporting it?

It's mostly our pricing model, we are moving from basically bandwidth driven to impression driven, and it is only enabled for customers on the impression driven model since otherwise we shoot ourselves in the foot by saving bandwidth. But updating contracts takes time, we cannot just modify existing contracts obviously.

oh right

isnt there some free tier with jxl processing/serving? (still described as FLIF on their site btw)

Haha, I remember now, when you explained that earlier. How your old pricing model discourages bandwidth saving

<:JXL:805850130203934781>

Can you expand on how this works? why would upgrading the image format impact impressions?

It sounds like the older pricing model is based on is based on the bandwidth the customer uses, so changing to JXL for those customers would reduce the company's income by reducing the bandwidth the customers use.

Ahhhh

More context: https://discord.com/channels/794206087879852103/806898911091753051/1329530250815733862

oh interesting, gotcha. that makes more sense

Keynote, Pages & Number got big updates today. I'd filed a bug saying HDR JPEG XLs didn't work in Keynote and it's fixed, but not noted as one of the supported HDR formats: https://support.apple.com/en-ca/guide/keynote/tan700f60676/mac

So close and yet so far on the optimize image formats <:AngryCry:805396146322145301> https://support.apple.com/en-ca/guide/keynote/tan12af068f9/14.4/mac/1.0

seems ubuntu finally approved everything about making jpegxl available out of the box in base ubuntu editions from now on starting 25.04

oddly libjxl was preinstalled on all other ubuntu editions (kubuntu, xubuntu...) except the gnome-based one

https://bugs.launchpad.net/ubuntu/+source/jpeg-xl/+bug/2099691

not quite related but snap version of gimp now integrates libjxl too but apparently 0.7 - likely gonna be updated since its far easier to ship upstream code than old slow frankencode with effort-wasting backporting

thought to mention since snap and flatpak guarantee consistent availability of jxl decode/encode whatever distro you use, especially non-rolling or non-mainstream ones

If those decode speed issues crop up again, someone inform them of the faster decoding work we're doing. Low values are twice as fast with minimal impact on density

Does this include gtk pixbuf thumbnailer?

Well some slight good news on the Safari front. The latest Tech Preview has support-ish for HDR images. I'm testing the HDR page against Thorium and they aren't quite as bright at the top end, but close. I'm wondering if they're doing EDR instead of full HDR. Looks much better than the current shipping version of Safari however. Was trying to take a picture, but not really working.

Safari Preview top, Thorium middle, shipping Safari bottom

The HDR Image here: https://jpegxl.info/images/liquid-abstract-colorful-texture-background-ai-generative.avif looks exactly the same on both browsers though. Which means when the Preview launches, I can kill that hacky video thing we have for Safari.

And I can replace with a proper HDR JXL

Nice!

where can I get the source for that image <:av1_woag:852007419474608208>

I took it and cranked up the color and HDR elements, but it's from here: https://www.freepik.com/free-ai-image/liquid-abstract-colorful-texture-background-ai-generative_41369647.htm

This was the file I converted to the other forms (before I made half of it non-HDR)

Wow it looks bad on Discord.

Someone really ought to make an HDR JPEG demo page using jpegli instead of "ultra HurrDurR"

Just to show "hey this is possible... look ma, no concatenation!"

I dunno if jpegli supports PQ/HLG input/output though

How bad would banding be?

Since jpegli has an internal precision of 12 bits I think it could handle HDR content quite well

Oh, encode AND decode using jpegli

Not terrible. PQ loses 1 bit perceptually compared to SDR on average across the luminance range, but since it is perfectly distributed across luminance, it actually looks better than SDR in dark areas at the same bit depth.

HLG is equivalent to gamma 2.4 with 250 nits peak for the lower, most relevant part of the curve. The log portion is also fine since it only goes up to 1'000 nits.

it does, we’ve tried it

(or some ancestor of jpegli)

both worked well, but HLG was somewhat more resilient to being decoded by not-jpegli

using P3 primaries instead of Rec. 2020 might also help a bit

WASM jpegli that decodes to 16bit PNG would make it easy to demo

Also, in what cases does it get the higher precision? I assume only in YCoCg and not XYB's internal RGB storage

What about the libjpeg `jpeg12_` API

Can jpegli just implement that for parity with libjpeg_turbo?

It would solve some compatibility problems if jpegli implemented the high precision API

Even in the photo that looks better! That’s very exciting

I have another Cloudinary question <@794205442175402004> if that’s alright – more like two actually: 1. was the deal with Visionular for Aurora1 just for AVIF, or also for AV1 video? 2. With your older pricing model, if it is bandwidth-based, couldn’t you just match the existing bandwidth of an older image format with a newer one & serve better looking images at the same cost to the customer? That seems like a win-win

1. For both. We switched to libaom for still images and svt for video. 2. The issue with that approach is that in the old pricing model, customers also pay per encode (per 'transformation') so customers have an incentive to enable fewer formats unless the bandwidth saving is worth it.

1. Was the main interest in the video performance or the AVIF performance? 2. So then the ideal scenario for both Cloudinary & customers is that a format like WebP gets 10% better overnight or something, as opposed to a newer codec entering the picture?

Or maybe that doesn’t help Cloudinary because customers then pay less for bandwidth

Unless it just means better pictures. I’m thinking about tune iq

AKA Jpegli

true - I wonder if they’re using it

1. Both, but probably mostly still images. 2. The new pricing model makes more sense than the old one. In the old model, incentives are kind of messed up on all sides.

We started rolling out jpegli but had to revert due to some weird bug that caused random crashes in production. I now think it may be related to avx512, which we use in production for libjxl too, but it may not be well-tested in case of jpegli.

I am now on holidays but when I am back I will start pushing for another try at jpegli rollout.

I’m guessing you currently use mozjpeg, which is pretty good either way

How about tune iq? Julio & I have been wondering for a bit whether or not you guys are interested, since it is double digit percent improvement on AVIF

Currently it's mozjpeg and libjpeg-turbo, mostly libjpeg-turbo is for q_auto:best

huh, why libjpeg-turbo over mozjpeg? Speed?

How does it do in terms of consistency? Currently we use libaom tuning for ssim, with an AI model trained to predict which q setting we need to reach a given quality target. That's needed because it is quite inconsistent (the quality you get at a given q setting depends a lot on the image content).

I don’t think consistency will have changed very much between those two, but I can probably test that. <@297955493698076672> do you know by chance?

At the higher qualities, we found mozjpeg to not necessarily outperform libjpeg-turbo in compression, and it gets a lot slower too.

Ah makes sense. So normally you guys are targeting what SSIMU2 range would u say?

Question will be if we can just do a drop in replacement with the existing q setting model, or if we need to retrain the model, which is more effort.

That’s a good question - I don’t know if I have an answer to that, but Julio might

Also I’m not sure which speed presets you guys most often use

Roughly 50-90, but internally we currently mostly use our own proprietary AI based metric called AIMOS, not so much ssimu2. The actual targets are defined on that scale, iirc something like 0.72 for q_auto:good

For avif we use default avifenc speed (6)

For jxl we use e6 for lossy

Oh wow that’s pretty slow

For mozjpeg we use -fastcrush iirc

Cjxl e6 should be far faster than avifenc s6, like multiple times faster

And then I’m guessing u use webp -m 6?

Nope, webp at default m4

For avif I pushed a bit to go to s6 since s7+ seemed to be quite a bit worse

We cannot go slower than s6, but s6 is just doable

Especially because we do use 420 when possible, which makes it a bit faster

When you do get round to that, I don't suppose you could look into using YBX instead of XYB, and defaulting to 4:4:4 XYB/YBX (in cjpegli) too? Then decoders/viewers without ICCv4 should look far better, pipelines forcing 4:2:0 won't subsample luminance anymore, and files can always be transcoded JPEG XL by default too. At least I think that's right, I get mixed up with YXB...

Hmm that trade-off may be different now with tune iq. Also, as I’m sure you know, webp m6 is closest in speed to aomenc s8

so WebP & JXL are quite a bit faster than avif here, which is great for avif, but probably a bit unfair to JXL

Oh huh, YBX … is that usable in jpegli now?

No, currently it's only XYB or normal YCbCr. Mario thought it was being used, but there's no reference to it in any jpegli files, oddly enough only in JPEG XL encoding

Huh

Scratch that, it's weirder <https://github.com/jonnyawsom3/libjxl/blob/32eb23b2e9bb3d296110092484e054724d921d04/lib/jxl/enc_modular.cc#L776> > XYB is encoded as YX(B-Y)

tune iq is significantly more consistent than ssim, not just across images also within an image (e.g. significantly less "botoxing")

yeah, you'll most likely going to need a retrain, but I wouldn't be surprised if consistency is actually good enough out of the box for Cloudinary's purposes

for avif, 10 or 8 bit? and how do you determine 420 vs 444?

We use 8-bit for SDR images, mostly because decode speed is better (compression performance is slightly better when using 10-bit but it's slower to encode and decode). The choice of chroma subsampling is also decided by the AI model. It's very content dependent if 420 is ok or not.

worst case scenario, you should be seeing the picked q level distribution by the model significantly narrow down

so cwebp -m 4 is ~4-5x faster (user time) than avifenc -s 6

at that point I wonder if avif is useful outside of high-traffic content

jpegli is possibly a better trade-off between speed and compression than either webp or avif, at least at the higher quality range...

Yeah I’d believe that

WebP feels hard to justify unless you use -m 6, where there can be gains above jpegli before hitting higher ssimu2

even -m 6 is ~2x faster than avifenc -s 6

I've cited it a few times without actually testing myself, but it does seem like XYB jpegli beats WebP and trades blows with AVIF https://giannirosato.com/blog/post/jpegli-xyb/

Though you already knew that :>

heh yeah ;)

but that set of four images is kind of limiting, because it favors settings that perform well in the dark

https://www.phoronix.com/news/Ubuntu-25.04-JPEG-XL-Default

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

For jpegli, in the realm of high fidelity compression, does `--noadaptive_quantization` score better on your AI metric when adjusted to the same BPP? I noticed adaptive quantization tends to blur fine detail and score worse overall across all metrics I tested with on at low distances (< 1.5). It also seems to more consistently hit the target butteraugli scores. For example inputting a distance of 0.8 is closer the actual max norm of 0.8, while adaptive quantization seems to undershoot quite a bit giving a max norm of like 1.2. Also turning it off provides little speed up which is nice.

Here is a visual example https://discord.com/channels/794206087879852103/1301682361502531594/1301693257662857260

Maui Image Gallery viewer + kimageformats(AVIF/JXL) = http://188.121.162.14/jxl/pix-4.0.1-jxl_avif.signed.apk

has it gotten any good yet? also no word on upstream support eh?

seems very slow

Author do not plan to add extra features to his APK. But it is merely a packaging thing. After adding few .so files into existing APK & sign again, the new image formats start to work. Anyone can do it.

how as the libjxl so compiled?

I used static build of libjxl, brotli and libhwy there.

i see... wonder why its so slow for me hmmm

how were they built ? got a script ?

cmake -DCMAKE_TOOLCHAIN_FILE=/home/old_system/root/lib/cmake/Qt6/qt.toolchain.cmake -DCMAKE_INSTALL_PREFIX=/home/old_system/root -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_SJPEG=OFF -DJPEGXL_ENABLE_TOOLS=OFF -DJPEGXL_ENABLE_JPEGLI=OFF -DJPEGXL_ENABLE_JNI=OFF ..

microsoft's extension for jpegxl updated from 1.2.24.0 to 1.2.25.0

It would seem 3 jxls i had that displayed no thumbnail nor decoded in Photos now display. However those cant be EDITed within Photos (says 'image is unavailable, try again later')

hmm, I wonder if it needs to be compiled with specific optimizations cause I found it to be pretty slow

Very slow to load huge JXL on Windows 11's Photos, but it opens natively at least

No longer requiring changing .jxl to another or using a third-party app is a BIG win that the Chrome Team would simply ignore

Hopefully jxl-rs will be an even faster decoder than libjxl.

If it's the best of both libjxl and Oxide, then there should be a lot to look forward to https://discord.com/channels/794206087879852103/1065165415598272582/1359843160649498727

bad integrations can hurt first impressions. outsiders freshly discovering jxl always seem to fail somewhere or inefficiently build the jxl libraries in ways that mislead about their real/current capabilities

is there a line of contact with the ms guys making the wic codecs? like a slack room, email adress

Wow. I had no idea jxl-oxide is already faster. That's amazing!

Damn. Now I wish more software used it. Especially Firefox!

I know the plan is for firefox to use jxl-rs. But jxl-oxide and jxl-rs will probably have a similar API and similar glue code so getting jxl-oxide to work first would not be a waste of time in my opinion.

PowerToys Peek can preview JXL (via ctrl + space) as well

Is power toys peek like apple spacer preview thing?

Quick Look*

forgot the name for a second

Yeah

Yes the same function

PowerToys Peek can also preview QOI but Quick Look can't

I know you emphasized "three separate staff members," but this is just one board, yes? We don't need a thousand different "archival boards" and the most popular ones likely don't need to be focused on that, since the main benefit of a Booru-style image board is the tag search to organize large volumes of images from various sources. Basically, they're organized aggregators. So, one option, to have the best of both worlds, is to do backend encoding and serve that up as the displayed image file, and use the "original image" button below the tags to explicitly serve the archived original file. Either way, I think most boards could do this just fine, but the biggest benefit would come from getting the source sites (DeviantArt, SNSes, Pixiv, etc.) to support and prefer next gen codecs like JXL and AVIF. Plus, they could use JXL to save space on existing uploads without touching a single pixel of the artist's work. I mean, everyone here knows this, but it's still an awesome selling point.

Yeah

"Image Optimisation" service by Optimole, a wordpress addon with 200.000 active installs seems to have added support for jxl starting 4.0.0

https://wordpress.org/plugins/optimole-wp/#developers

idk if its any good but it it implements anything well, perhaps folks could do 3rdparty rebuilds/forks based on this implementation

many similar addons seem to outsource the conversion functions to an inhouse script or outdated sqoosh, rarely local in-browser crunching. Note: above is a paid service with a free tier, functionally similar to cloudinary

Photos and PowerToys Peek on Windows 11 can't open some JXL files. Weird weird

any specific types?

msjxl extension was updated recently and some images that previously didnt thumbnail or read now do, albeit with the caveat theyre oddly not editable in photos' editor

PNG of modified photography (confidential) to JXL

Interesting

would it be possible to run jxlinfo on them though?

That's in my office

Tomorrow ubuntu 25.04 should drop with libjxl 0.11.1 preinstalled and some core packages rebuilt with jxl support (same for all other editions, ie kubuntu, xubuntu). Fedora 42 was freshly released too, now with an official KDE edition planned to be as well supported as the Gnome one

note: the *snap* package for gimp oddly uses ancient libjxl 0.7 but should be updated at some point. Flatpak/appimage/repo gimp uses latest libs

> JPEG XL image, 3694x3004, (possibly) lossless, 8-bit RGB+Alpha > num_color_channels: 3 > num_extra_channels: 1 > extra channel 0: > type: Alpha > bits_per_sample: 8 > alpha_premultiplied: 0 (Non-premultiplied) > have_preview: 0 > have_animation: 0 > Intrinsic dimensions: 3694x3004 > Orientation: 1 (Normal) > Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative Via the Clang one

Uh it may be probably the issue from the Clang-compiled library

Hmm it doesn't matter if that's Clang-compiled. JXL generated by either the official or the Clang-compiled library on Windows can't be opened by Photos on Windows 11 for me

The one that I oftern use > JPEG XL image, 10500x10500, (possibly) lossless, 8-bit RGB+Alpha > num_color_channels: 3 > num_extra_channels: 1 > extra channel 0: > type: Alpha > bits_per_sample: 8 > alpha_premultiplied: 0 (Non-premultiplied) > have_preview: 0 > have_animation: 0 > Intrinsic dimensions: 10500x10500 > Orientation: 1 (Normal) > Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative

whats the version number for the msjxl extension and the Photos app ?

It been a while so I'm sharing new release links

https://github.com/Eclipse-Community/r3dfox/releases/tag/v128.9.0 https://github.com/Eclipse-Community/r3dfox/releases/tag/v136.0.4

Does it supports jxl in webpages?

yes

Nice

old pic but ye https://eclipse.cx/images/projects/r3dfox/big7.png

It is a bit strange that Ezgif has an explicit `JPEG to JXL` option, which just does a lossy conversion anyway... I wonder if they don't understand you need to treat them differently for it to transcode

Conversion for conversion

They probably just have a list of supported inputs and outputs and a script that makes a page mapping each input to output which all probably just use imagemagick

compressing images on server..

I'm interested in using JXL in the browser to do ROI decoding of satellite data, i.e. 1. decide on crop/zoom level based on camera frustum 2. send request to server 3. fetch subset of bytes 4. decode bytes into pixel buffer in wasm Is this at all possible with existing SDKs/APIs? We're currently using ECW which is great at ROI/downsampling but doesn't have any means of doing stuff over the network, so we have to generate tiles on the server.

You may need to parse the TOC to know what bytes to send, since the header is still required before groups can be sent, but [jxl-oxide](https://github.com/tirr-c/jxl-oxide) has a cropped decode API and is fully compliant. With a pre-made WASM example available <https://github.com/tirr-c/jxl-oxide-wasm-demo>

Is jxl-oxide merged to jxl-rs?

I don’t think they are not planning to merge either into the other at this stage

tev has added support for JXL, although a binary release with it is still missing https://github.com/Tom94/tev https://github.com/Tom94/tev/pull/282

> tev is the only image viewer I know of that supports most of the features of JPEG-XL Intriguing

tev can play animated JXLs and also display each frame separately

Good I could import JXL during my first AE (2023) lesson

> JPEG XL support is now available in Photoshop Beta. Make sure you have updated to the latest version of Beta, and then you can find it in File > Save a Copy under the Formats menu. > > This feature is still in Beta because we want to hear more feedback from you on what you like and don't like. Please respond here with any feedback! https://community.adobe.com/t5/photoshop-ecosystem-ideas/jpeg-xl-support/idc-p/15294314#M25287

Just please give me JPEG XL compression in layered TIFF so my masked/edited files are not so huge 😭

...and in PDF please

let the implementations cook. my suggestion: new revisions of the adobe formats should have both a max backward compatibility mode (uses previous compression format) and high efficiency mode (jxl). imo thatd ease adoption by requiring decoders and similar apps to be able to decode both (like with dng 1.7) and seed a large pool of compatible decoders

i hope they only implement reasonable 'efforts'. efforts higher than 7 and especially 9-11 should not be allowed even as expert toggles and seem to always sour people on the entire format

Speaking of DNG, do we know what settings are used for its internal JXL compression? I was recently comparing some file sizes of a photo: Original NEF raw: 21,2 MB lossless DNG: 15,1 MB (29% compression) PNG of same image: 21,8 MB lossless JXL e7: 14,1 MB (35% compression) its close, I was just kinda expecting the compressed raw (dng) to be smaller than already developed compressed file (JXL)

And the lossy DNG would be also interesting. I just wonder if it keeps the bit depth

Reminds me of https://bugs.kde.org/show_bug.cgi?id=500877

I forgot to reply to this yesterday, but the answer is, it depends. The specification only says "It can be JPEG XL", so the bitdepth, quality, effort, tile size (Not group size) and other parameters are up to the implementation. Adobe's DNGConverter has these options, though internally splits the image into 764 x 764 tiles, limiting the density somewhat and being horrible to use due to case sensitivity and no feedback for failed commands

For my tests I use https://tinydng.com/, since it maintains the original format and doesn't split the image into tiles

Huh, this must be the earliest adoption I've seen yet <https://mirillis.com/action-history>

FastStone recently released 8.0 version of their viewer, and still no jxl support 🤦‍♂️ Looks like their 'contact us' form is just a black hole

acdsee has no excuse... no dng 1.7 or jxl in 2025 is nuts. if they just had a proper addon ecosystem instead of carrying on with the jpg decoder from 20 years ago

update of unclear importance. microsoft's extension for jpegxl encoding/decoding is now no longer a utility but a "system component"

I just tried it out today for the first time, wasn't aware it was ever not a system component

onward to whitelisting for win10 ?

its technically unavoidable because winstore serves the same apps/games versions to win10 and win11 users so store listings need parity for both platforms regardless of wether the base OS no longer receives updates - as long as winstore keeps working on win1 for at least business users, jxl-capable apps like Photos need to be fully functional on win10 as well instead of prompting for an extension that doesnt show up without any explanation

i wonder if theres a way to know how many installs store listings have

ok, i tried to check what codec is used in DNG produced by Lightroom Classic 14.3 via ExifToolGui lossless: JPEG lossy: JPEG XL (e7)

sadly i cant see what quality was used for jxl

I'll never understand their weird choice of tile sizes for JPEG XL. Default group size is 256 and DC 2048, yet they pick 400 x 416?

Same goes for lossless, 672 x 752 https://discord.com/channels/794206087879852103/805176455658733570/1259095811745251418

Oh right, they were also using Faster Decoding 4 for lossless, which we only just fixed to be 20% smaller and 25% faster

you got jpeg xl when converted to lossless dng? i got just regular jpeg 😕

I was using the Adobe DNGConverter CLI

Which is horrible to use, but does (sometimes) work https://helpx.adobe.com/uk/camera-raw/using/adobe-dng-converter.html

The specification is very vague so these parameters are not required

Correct, but there's also no way to disable it in the offical CLI tool

hmm, i guess in future i will use lossy dng for my raws. I am perfectly fine with "visually lossless" which lossy jpeg xl should handle just fine

and if I am not wrong, this also preserves ability to change white balance and exposure because its still 16bit, which is nice

Depending on implementation, you can control the quality too

Well... This is annoying https://openimageio.readthedocs.io/en/latest/builtinplugins.html#jpeg-xl

https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4584

Goes to show how bad the old config was, if people somehow thought it was just another effort setting, even while being named `DECODING_SPEED`

if it's any help I found where the doc itself is in the repo: https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/f7cd3a19c3771e39b2cac8b87bf716fbea8314b6/src/doc/builtinplugins.rst?plain=1#L1300

Fossify Gallery 1.3 released https://github.com/FossifyOrg/Gallery/releases/tag/1.3.0 Now a lot of JXL images load that wouldn't with the older version, although any JXL with a non-sRGB colourspace displays wrong

But at least it displays at all

what was the jxl change they did?

unforunately they dont squash translation commits

Nothing according to the changelog, I assume that the underlying library was updated

https://github.com/FossifyOrg/Gallery/commit/68aa07781678bb569cf47d88e8bfc61452d8c12e

Probably this commit

ah I see

a shame that jxl coder doesnt seem to have much documentation

At least it is now almost fully functional

well thats good indeed

was there any perf changes?

It feels the same to me

sadge

seems fossify updated the jxl decoder from 2.3.0.1 to 2.4.0.7

2.4* brings an upgrade to coil3. decoding limited to 16mp by default, optional for devs to change to fullsize (ie for gallery apps)

idk if that changed anything for images not loading at full resolution

all images I've tried are now loading

only non-sRGB images are failing, but still kind of displaying

As seen here

10bit sRGB JXLs also display wrong

sad

as long as there is no regression

yeah I have a fair amount of jxl files that dont render properly, but the amount of jxl files I have that dont render at all is pretty much none

possible discord jxl support in the future 👀

a good way to sell jxl is promoting more efficient apps that load content and possibly even more ads snappier than the website in a browser

load jxl inside the discord apps, leave bloated originals and blurry versions to browsers

<:JXL:805850130203934781>

Possible Jpeg XL support incoming for Blender <:Stonks:806137886726553651> https://devtalk.blender.org/t/2025-06-10-blender-admins-meeting/41008

please depth map support please depth map support

(I haven't read it yet)

[Direct Link](<https://devtalk.blender.org/t/2025-06-10-blender-admins-meeting/41008#p-152926-new-dependency-jpeg-xl-4>)

IIRC OIIO has depth map support, but the PR is very minimal currently, only supporting RGBA

https://projects.blender.org/blender/blender/pulls/139397

If anyone has been following WWDC, a few things of note: "WebKit shipped support for HDR video in Safari 14.0, in 2020. Now, in Safari beta for iOS 26, iPadOS 26, macOS 26 and visionOS 26, WebKit adds support for HDR images on the web. You can embed images with high dynamic range into a webpage, just like other images — including images in Canvas."

It's been coming and going from the Safari Tech Preview. More going than coming.

Safari details here: https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/

And the only place I've found JPEG XL reference: > Over the last few years, we’ve filled in a lot of the pieces to more fully support a wide range of codecs and containers. We were the first to support JPEG XL and HEIC on the web, and in Safari 19, we’ve added Ogg Opus and Ogg Vorbis to the list of media we support.

And Google still gives no fucks about JXL.

Keep up the fight…

There's one here too: https://developer.apple.com/videos/play/wwdc2024/10177

From this video: > The fundamental Idea behind the Adaptive HDR technology is to store in a file a fully backward-compatible SDR baseline representation of an image. Together with specific metadata and a map, that preserves the spatial locations of bright areas of the scene. This map is commonly called Gain Map because it allows for gaining parts of the SDR image to increase the brightness. When the Gain Map is applied to the baseline rendition, it will produce a beautiful HDR output. A sharp eye may have noticed something peculiar in the slide above. The title says Apple Gain Map, and not Adaptive HDR. This is not a mistake. Since 2020, iPhone cameras have been capturing images with embedded gain maps to enhance their appearance. Over a trillion images have been captured in this format! You can find more information about Apple Gain Map on the Apple Developer Portal. > > What is new this year is that we are driving an effort to standardize the Gain Map technology. > > We are standardizing the mathematical formula for creating and applying the gain map to the baseline SDR. Adaptive HDR encodes the map as the logarithm of the ratio between the HDR and the SDR signal. It also defines new metadata and how to store the new information in common file formats like HEIF and JPEG.

Will need to listen to the whole thing.

Isn't it Safari 26?

Probably, yeah

Is it too late to find that Telegram for macOS allows JXL for uploading as images? Although they would be ultimately converted to JPEG

Telegram has JXL support on all desktop clients for quite a long time already

It also decodes JXL when sent as a file

mobile support is weird, before it prompted you to open an app but now it tries displaying it to nothing, although AVIF works just fine

probalby work fine on IOS

https://helpx.adobe.com/photoshop/using/whats-new/2025-6.html#:~:text=Explore%20AVIF%20and%20JPEG%20XL%20File%20Support%20in%20Photoshop

Options when you save:

Slightly underwhelming, especially compared to Krita (Thanks Kampidh), but it gets the job done

I wonder what mapping they have from photoshop quality to libjxl distance

Yeah, Mario posted it 3 messages ago :P

What are the Photoshop Extras in metadata?

from their webp doc, supposedly print profiles/settings, paths, guides etc

only way to know for sure is checking but photoshop extras sound theyre meant to accomodate the subscription, sync and collab system so that file can be consistently edited wherever

Grrrrr. > The upcoming iOS 26 update adds a new Screen Capture menu to the Settings app, under General. In it, there are a few useful toggles. > > First, there is now an option for HDR screenshots. When this format is selected, any HDR photos or videos in screenshots will actually appear in HDR with full dynamic range, when viewed on newer iPhone models and other supported devices. > > Apple says HDR screenshots use the HEIF image format. There is still an option for SDR screenshots, which are saved as PNG files.

https://www.macrumors.com/2025/06/17/ios-26-improves-screenshots-in-three-ways/

Fast lossless my beloved 😔

**JPEGXL** 😤

I'm a month late, but Irfanview got updated to support JPEG XL compressed DNG files. 400ms uncompressed, 600ms JPEG92 lossless, 800ms lossy, 700ms effort 2 lossless. Odd results, since extracting the JXL codestream results in 100ms decode not 400 Can't tell if it's just the heat over here, but my CPU is getting more angry than before updating even on the uncompressed file...

Wonder if that uses lossless or lossy for HDR screenshots

Not sure if HEIC (or at least apples implementation) would support it

Yeah, that's what I was thinking. But it would be odd to go to lossless for screenshots have using PNGs all this time.

Lossless HEIC is as advanced as lossless AVIF

Another note from that presentation. HDR images now supported in Preview, Quick Look, Messages and not just Photos.

power of multi-threading

Which part? Because Irfanview uses multithreaded JXL decoding, but it's loosing 300ms somewhere compared to djxl

🤨

<:WhatThe:806133036059197491>

So HDR screenshots will be lossy and using subsampled gain maps? Ugh that could lead to pretty ugly artifacts... Why not just use lossless 10-bit jxl that just captures the actual screen content exactly?

This is what happens when the marketing team speaks instead of the engineering team. "It's backwards compatible! Don't worry about the dozen downsides..."

_Only Apple can do._

Users are going to enjoy blurry texts over the most advanced HDR screenshots ever

I wonder how much bitdepth is realistically needed for "convincing" HDR gainmaps, and if it is feasible to just encode the map as lossless

I suppose this depends on how the HDR image is converted into an SDR image and a gainmap.

Take a watch of the video, but I think you can also do a 'normal' HDR image without a gainmap (10-bit HEIC). Hopefully that's what the screenshots are.

NeoChat (communication app Matrix network) is able to view JXL images. Linux/Windows client available at https://origin.cdn.kde.org/ci-builds/network/neochat/release-25.04/

Neochat for Android can be installed via F-Droid app by adding KDE repo into it: https://cdn.kde.org/android/nightly/fdroid/repo/?fingerprint=B3EBE10AFA6C5C400379B34473E843D686C61AE6AD33F423C98AF903F056523F

is it no longer crashing all the time? nice if so

can't log in

It works on my Android phone but it's true I had to try multiple times to log-in. Development for Android is not so easy like for Linux/Windows unfortunately.

yeah, guess ill be waiting around for another client, maybe I should pester robrix to support jxl hehehe

It's not new, but I think this is the only online converter to do JPEG Transcoding https://compress-or-die.com/jxl

It defaults to lossy, and stripping reconstruction data, but if you set it to lossless then it does actually work

im confused as to what this means

This graph is from the AVIF vs JXL article by chromium team I think. I'm assuming "transcode" means encoding? (idk why they call it that)

They (the chrome avif team) compared speeds at slowest, default and fastest speeds, but that's of course rather meaningless if you don't also consider the quality/bpp curve you get at those speeds.

Could do with some help convincing them 😅 https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-format/41155

Bit depth can actually be set per extra channel, so you can have a uint8 RGB image with a float16 depth channel, a uint12 alpha channel, and a float32 whatever channel. The only thing that you cannot have is different bit depths for R, G and B: the three main color channels are supposed to have the same nominal bit depth.

(though if you would want to do something like rgb565, you could efficiently store it at a higher nominal bit depth and libjxl would use channel palettes to reduce the range of the channels to 32/64/32 shades)

I edited my comment with your quote, but I don't suppose you'd like to reply yourself, in case there's more corrections or questions you could answer?

Hello! I'm one of the people on that blender devtalk thread above. Just finished some testing comparing lossless compressoin ratio/performance for floating point (fp16/fp32) images. Among things already existing in OpenEXR, plus upcoming OpenEXR mode based on HTJ2K, plus JXL. https://github.com/aras-p/test_exr_htj2k_jxl and the summary graph https://raw.githubusercontent.com/aras-p/test_exr_htj2k_jxl/refs/heads/main/img/mac-m4max-20250625.png -- at least on this data set, libjxl does not look very impressive :/ But it is also very possible that I did something wrong.

For the decode speed, you could try adding `JXL_ENC_FRAME_SETTING_DECODING_SPEED` along with the effort <https://github.com/aras-p/test_exr_htj2k_jxl/blob/main/src/image_jxl.cpp#L363>. It's not been tested on floats yet, but should perform similarly with it scaling better with more threads. ``` Decode (MP/s) Default Lossless 43.01 Faster Decoding 1 76.60 Faster Decoding 2 84.31 Faster Decoding 3 142.22 Faster Decoding 4 169.22 ``` For me, PIZ EXR loading is 2x *slower* than default lossless JXL, with the JXL being 32% smaller for a Float16 render. Not sure what's going on but smells fishy.

you looked at efforts 1,4,7 ? https://github.com/aras-p/test_exr_htj2k_jxl/blob/33f9c963547ae82920f7c0324bf8d916c131fc6a/src/main.cpp#L78

I would try efforts 2 and 3 too

Lossless float is something that is not implemented in a very efficient way in libjxl right now. A float16 buffer first gets converted to equivalent float32 values, then the float16 gets reconstructed and bitcasted to uint16 which is then stored in int32 buffers to be encoded losslessly — and the same in reverse order on the decode side.

Obviously in principle a lot of that could be avoided, it's just the price we pay for using float32 internally throughout in libjxl, so we can avoid having to implement more than one variant of all internal processing.

When I tried effort levels 2,3,5 they were roughly along the lines in between other levels on ratio/throughput graph

This is definitely skewing the results somewhat https://github.com/libjxl/libjxl/issues/3511

I ran a test using `Blender43.exr` as linked in your repo, comparing libjxl v0.9 and what will be v0.12 (v0.9 lacks multithreading, so only effort 2. And my builds don't have EXR support, so using PFM as an intermediary) ``` cjxl Blender43.pfm Blender43.jxl -d 0 --patches 0 -e 2 JPEG XL encoder v0.9.1 b8ceae3 [AVX2,SSE4,SSSE3,SSE2] Encoding [Modular, lossless, effort: 2] Compressed to 40311.4 kB (38.881 bpp). 3840 x 2160, 0.070 MP/s [0.07, 0.07], 1 reps, 16 threads. cjxl Blender43.pfm Blender43.jxl -d 0 --patches 0 -e 2 JPEG XL encoder v0.12.0 7deb57d7 [_AVX2_,SSE4,SSE2] Encoding [Modular, lossless, effort: 2] Compressed to 72068.8 kB (69.511 bpp). 3840 x 2160, 20.722 MP/s [20.72, 20.72], , 1 reps, 16 threads.``` Doing a decode speed test using FFMPEG, the v0.9 JXL loads nearly twice as fast as ZIP EXR ``` EXR speed=0.172x bench: utime=0.219s stime=0.031s rtime=0.233s JXL speed=0.299x bench: utime=1.547s stime=0.141s rtime=0.134s``` Trying my own float16 image, Irfanview reports JXL as 2x faster than PIZ EXR at effort 7. Effort 2 makes it 5x faster to decode, while still being 23% smaller

That's without any of the faster decoding levels too (Because 0.9 is too old for it). Though level 3 is roughly equivalent to Effort 2, with some extra tools like RCTs

So something is definitely wrong, either I'm getting much slower EXR decoding, or you're getting much slower JXL decoding...

Especially since JXL can only use LZ77, which should be on-par with RLE, PIZ and ZIP for decompression AFAIK

Yeah I’d like to know what is going on too

If you build libjxl from GitHub it will still have support for EXR ``` cjxl -d 0 --patches 0 -e 2 Blender43.exr Blender43.jxl JPEG XL encoder v0.12.0 97319fe4 [_AVX2_,SSE4,SSE2] Encoding [Modular, lossless, effort: 2] Compressed to 30446.6 kB (29.366 bpp). 3840 x 2160, 65.699 MP/s [65.70, 65.70], , 1 reps, 32 threads. ``` Only a little bit smaller than the EXR but decode speed is still faster ``` EXR speed=0.317x bench: utime=0.123s stime=0.004s rtime=0.127s JXL speed=1.54x bench: utime=0.477s stime=0.059s rtime=0.026s ``` ImageMagick and ssimulacra2 report a difference for the encoded JXL. Though this is nothing new, I had written about this happening a few months ago on this server already ``` ImageMagick: JXL f4deffc38cf5d4352941247d72631a632b09dd70a2a6fa6bd5a6709848ed7c77 EXR abce12354037460d9b72065dd0e3c5840699f6b0ba24fb3bc7aabcf1a9ca81d7 ssimulacra2: 95.55762514 ```

And for good measure: Fast decoding at effort 7 All still smaller than the EXR ``` FD1 speed=0.581x bench: utime=1.754s stime=0.036s rtime=0.069s FD2 speed=0.731x bench: utime=1.416s stime=0.027s rtime=0.055s FD3 speed=1.59x bench: utime=0.462s stime=0.023s rtime=0.025s FD4 speed=1.91x bench: utime=0.402s stime=0.015s rtime=0.021s ```

Huh, you're getting much denser and faster encoding than me, even with me using the old build's density and main's speed

with the only difference being EXR input being used instead of PFM it seems?

Using intermediaries such as PPM often leads to decreased density in my experience

I haven't done a comprehensive comparison regarding that, but it happened every time I tried

3x faster encoding, with me having an extra 20%~ boost from using a clang build, hints at something going wrong with PFM

isn't PFM implying all 32 bit floats?

Somehow I read RGBA and RGB as Float and Half when picking what file to test...

But regardless, you can see that it's quite handily beating EXR, the question is why it didn't in your tests

But also, y'all are picking Blender43.exr from my test, which is like "the least interesting" for the use cases talked about in the original blender devtalk thread (since it is "just" a RGB image with 3 color channels, and nothing else). That is not what typically is used in compositing workflows, which is what the whole thread started about. Images with dozens of channels are way more common.

Which do you think we should try?

probably which ever is the most complex file, I haven't looked at the repo so idk which that would be

Blender41.exr is the largest/most complex one of the bunch

Ok brb

740MB sheesh

Need to enable SWAP for that

that is not even large by film production standards! 🙂

true

I just downloaded a 24GB TIF from NASA

Your size info on GitHub states 740MB for Blender41.exr, but the file is only ~400MB

Well thats unfortunate, my cjxl built from main fails to open this EXR. Blender43,.exr worked fine

I have the list pulled up now from the repo and Blender35.exr or Blender40.exr should also be decent for testing if Blender41.exr is a bit too beefy for anyone here to test

> Your size info on GitHub states 740MB for Blender41.exr, That table lists raw uncompressed size, not exr size.

> cjxl built from main fails to open this EXR Maybe it does not support non-color channels? or mixed precision among different channels?

Ok, I keep getting "Getting pixel data failed" for that EXR

What compression type is the EXR, just ZIP?

Yes

``` compression: 'zip' displayWindow: [ 0, 0 - 3839 2159 ] 3840 x 2160 dataWindow: [ 0, 0 - 3839 2159 ] 3840 x 2160 channels: 37 channels 'Composite.Combined.A': half samp 1 1 'Composite.Combined.B': half samp 1 1 'Composite.Combined.G': half samp 1 1 'Composite.Combined.R': half samp 1 1 'View Layer.AO.B': half samp 1 1 'View Layer.AO.G': half samp 1 1 'View Layer.AO.R': half samp 1 1 'View Layer.Combined.A': half samp 1 1 'View Layer.Combined.B': half samp 1 1 'View Layer.Combined.G': half samp 1 1 'View Layer.Combined.R': half samp 1 1 'View Layer.Depth.Z': float samp 1 1 'View Layer.DiffDir.B': half samp 1 1 'View Layer.DiffDir.G': half samp 1 1 'View Layer.DiffDir.R': half samp 1 1 'View Layer.DiffInd.B': half samp 1 1 'View Layer.DiffInd.G': half samp 1 1 'View Layer.DiffInd.R': half samp 1 1 'View Layer.GlossDir.B': half samp 1 1 'View Layer.GlossDir.G': half samp 1 1 'View Layer.GlossDir.R': half samp 1 1 'View Layer.GlossInd.B': half samp 1 1 'View Layer.GlossInd.G': half samp 1 1 'View Layer.GlossInd.R': half samp 1 1 'View Layer.Noisy Image.A': half samp 1 1 'View Layer.Noisy Image.B': half samp 1 1 'View Layer.Noisy Image.G': half samp 1 1 'View Layer.Noisy Image.R': half samp 1 1 'View Layer.Normal.X': float samp 1 1 'View Layer.Normal.Y': float samp 1 1 'View Layer.Normal.Z': float samp 1 1 'View Layer.Position.X': float samp 1 1 'View Layer.Position.Y': float samp 1 1 'View Layer.Position.Z': float samp 1 1 'View Layer.UV.A': float samp 1 1 'View Layer.UV.U': float samp 1 1 'View Layer.UV.V': float samp 1 1 ```

"just zip" within OpenEXR of course means "a simple delta filter, followed by deflate". It is not just literally running zip on raw pixel values.

JXL supports both, but the EXR handling has been a bit... Iffy... As of late due to compilation issues. I wouldn't be surprised if it's encountering a problem

try one of the EXRs I mentioned, if it still fails then I guess it's an issue with how cjxl handles EXR input

Yes, I just mean > compression: 'zip' Keeping it simple :P

Yeah, I wrote about issues with EXR a few months ago, shortly before EXR was removed from the repo

just find an intermediate format you can convert to that retains as much as possible and cjxl supports because I don't think you are gonna be able to get direct EXR input support to fully work

We know multi-channel works due to previous mulitspectral testing https://discord.com/channels/794206087879852103/794206087879852106/1247491487181180940

It works in general, I have verified using sample multi channel images from OpenEXRs github

Maybe just because these files are too large

The problem then is retaining the channels. Which format supported by libjxl is able to do that?

I don't think any of them can, right?

PAM can <https://github.com/libjxl/libjxl/blob/876aa4771fe57b8bcd3953bb48a1b2c11bc94c42/lib/extras/dec/pnm.cc#L236>

But IIRC you have to manually make a frankenfile... And that's assuming it can store floats, which I'm not sure

I don't *think* we've had any test images with mixed precision before, so it could be that the EXR decoder isn't plumbed into libjxl for per-channel data types yet. <@794205442175402004> any ideas?

probably gonna have to end up using the API directly for the time being to at the very least generate a lossless JXL with all the channels intact for easy testing through cjxl

Looking at EXR reading code in libjxl, it was only supporting RGB(A) images (any extra channels would be ignored) and always returning FP16 data, due to usage of RgbaInputFile

…which is what my code is trying to do 🙂

Some images from https://github.com/AcademySoftwareFoundation/openexr-images also cannot be encoded by libjxl. Most do work luckily

Ahh right, now I remeber. EXR support was lacking the extra channels and full floats due to them requiring the use of a more advanced API

Don't suppose you could upload one of your encoded JXLs? Then we can do further testing on encode/decode speed with the extra channels and full floats

~~I was just attempting to compile their repo so I could send the binaries here and y'all could generate your own multi-channel JXLs~~ just realized it doesn't output files just the results whoops

Feel free to make pull requests to make EXR read/write support better in cjxl/djxl

TBH, I think we only really had EXR support in the first place to have some input format that has premultiplied alpha and float types, which are missing in PNG.

But it would make sense to make the support more complete

The internal representation of PackedPixelFile we're using as generic uncompressed in-memory representation should be expressive enough to do anything EXR can do, I think

Probably not _everything_, EXR has many very exotic things, like “deep EXR” that stores variable amount of data per pixel; I’m pretty sure JXL can’t do that 🙂

That said, I’ll take a look at making a PR for better EXR reading

*Technically* you could combine extra channels with layers in JXL, to store the extra samples of Deep EXR, but let's get extra channels and variable precision in cjxl working first 😅

variable amount of components per pixel is indeed something jxl cannot do — but you could of course just put dummy values in the missing components...

Anyhow, right now I'm looking at changing `dec/exr.cpp` to no longer turn all input EXRs into FP16 (issue #465), that is going well. Next up, make it support more than color channels and stuff that into "extra channels". Will make a PR once I have something.

Thanks for helping us out, EXR support has been spotty for years now. Maybe support could even be re-enabled by default, if it doesn't break everything again

Alright I have things _almost_ working in making cjxl be able to read & encode extra channels coming from EXR files. However there's some strangeness with mixed precision channels, FP32 ones when the rest are FP16 seem to be garbage in the resulting file (as observed by djxl dumping extra channels). However as far as I can tell, the data I am passing in is fine. Strange! https://github.com/libjxl/libjxl/pull/4312

Could be some bug in modular encoding where it doesn't properly look at the correct bitdepth per channel but assumes everything is like the first one

It is very much possible that I wrote buggy code that implicitly does that

<https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-format/41155/25> > What are the file sizes? (And, I’m assuming single-layer each?)

Already deleted the files, but from memory FD1 and FD2 both were 28,8MB FD3 was ~29MB FD4 was ~30MB

Don't suppose you could run them again quickly along with effort 2? I'd do it myself but I don't have any builds with EXR support (v6, 8, 9, 10, 11, 12 <:SupremelyDispleased:1368821202969432177>) Here's the link to the file again https://aras-p.info/files/exr_files/Blender43.exr

<@794205442175402004> looks like if I just change `jxl.cc` call to `JxlEncoderSetExtraChannelBuffer` from using the main color format (`&ppixelformat`) to `&pframe.extra_channels[i].format` then it all starts working properly. But overall I have no idea what I'm doing, so not sure if that's the right fix.

That does sound like a fix. If one is f16 and the other is f32 then of course it will be garbage...

my guess so far at why I'm seeing very different EXR encode/decode speeds than you, is maybe things you are testing (ffmpeg/imagemagick/cjxl) do not actually do multi-threading for EXR? I should check what ffmpeg does...

Hmm, good point. I'd be surprised if FFMPEG wasn't, unless they wrote their own decoder instead of using the library?

Ffmpeg _does_ have their own EXR code, yes

O h

Would it be alright if I repost those draft pages in response to this issue? https://github.com/libjxl/libjxl/issues/4310

That doesn't solve this specific issue of too many reset positions though...

It's in response to the comment about gain map tail data, and mentioning https://github.com/libjxl/libjxl/issues/3882 too

Actually, I'll split my comment and move the draft images to that second issue

Ah yes for gain map data there's a different problem.

Actually there are two problems with gain map jpegs: compressing the gain map more efficiently (by applying recursive jpeg recompression to it, instead of just Brotli), but more importantly maybe: keeping it semantically as a gain map in the jxl file too. Otherwise a gain map jpeg recompresses to an SDR-only jxl.

Yeah. With how much of a mess UltraHDR causes, for such little gain~~map~~, almost makes you wonder if Google did it just to spite JXL :P Almost certainly not, but shunning a real HDR format and then slapping 2 JPEGs together while calling it 'a true HDR image format' is a bit... Hmmm

also forcing it on everyone as well since iirc now all of the new Pixel phones and such output them

I have to say, I'm excited to see the multilayer results given how well we did for multispectral images. -e 2 -E 1 should be pretty competitive on size and not too bad on speed

Ok, I'm back with my EXR vs HTJ2K vs JXL comparisons for lossless compression of floating point images. Latest code here: https://github.com/aras-p/test_exr_htj2k_jxl Learnings since last time: - All these codecs have large variability between different images. Like if you say "JXL is very good at compressing Blender43.exr" that is true but it might be worse at compressing another image. This is pretty obvious. - JXL can give best compression ratio of the compared ones (at effort 4..7) - JXL is slowest of the compared ones (at all effort levels), at both compression and decompression - Do _not_ use ffmpeg to benchmark JXL vs EXR performance! ffmpeg uses libjxl, but for EXR it uses their own code (which is very compact & easy to read, but not necessarily fast), and all single threaded too. - There's "Mop" codec in the charts, which is not an image format at all. I'm just mis-using a fairly popular & small geometry compression library to compress image pixels, pretending they are vertex data. Curious find is, that at least on this data set, it absolutely smokes everything else on the pareto front chart, while being 26 kilobytes of executable code (compared to say JXL that is 6MB). - My understanding is that libjxl floating point lossless compression has not been a focus (yet?), maybe this will inspire someone to improve it, if the spec/format allows it. - It could also be that JXL is way more strong at lossy compression, which is a whole another topic of course.

the benchmarks I've seen of lossless jxl have almost all been for 8-bit or 10-bit images, where it usually does really well compared to other formats. In principle I don't think there's anything in the format that would make lossless floating point worse, but I'm quite sure that it hasn't been a development focus, yeah.

Good feedback, and good motivation. There's been very little requests or testing around Floats, so I'd expect significant improvements are possible. It may even be like progressive, where a malfunctioning coding tool was doubling the filesize. We fixed that for 0.12, but it was annoying to track down

is EXR even compressed?

i thought it was just the container

EXR is indeed a container, it can hold multiple compression formats

all of them lossless but one or two iirc, things may have changed since I last looked into that stuff tho

EXR is compressed, yes. Has 4 (soon 5) lossless compression codecs (RLE, ZIP, ZIPS, PIZ, soon HTJ2K), and 5 lossy ones (PXR24, B44, B44A, DWAA, DWAB)

why not just use JPEG XL as a payload in EXR

damn things have changed lol

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

wouldn't HTJ2K also count as lossy or is that not an intended use case for it within EXR?

Within EXR right now HTJ2K is only lossless. Maybe they will add a lossy mode later on, I’ve no idea

Adobe 'added' jxl support to the Photoshop, but it is.. strange. White rectangle 800x600 px saved as 75 (in PS values) lossy weighs 15 KB, 99% of it of which are PS metadata without any compression:

Psd file or jxl file

You would think they would use brotli boxes, but nah too lazy ig

Adobe software loves to add bloated metadata to images they work on. IIRC Photoshop eve has a document history entry that unsurprisingly can be quite large.

I found out last night that they're using v0.9 for DNG, so no chunked encoding and 19 months of bugfixes are missing https://discord.com/channels/794206087879852103/805176455658733570/1390181961292582922 I'd have no doubt photoshop is also on an ancient version with misconfigured settings

no surprise. excellent implementations require the support of folks most intimate with jxl, especially with file formats since they require much more care compared to dlls that can always be easily updated

that said, it should be possible to make a 3rdparty export addon. many implementations flatten the image and merge all layers without any notice (ie gimp) or use lossy alpha for what shouldve retained lossless alpha for edges

The strange thing is, Eric Chan who's lead for camera raw has been on the reddit frequently in the past, but never asked for any advice or opinions

"Use brotli boxes". Adobe's T9: "Did you mean 'bloaty'?"

they're the kind of company to add a high res preview in raw TIFF format at the beginning of the file

Given they're using v0.9, now I'm wondering how performance would be with a modern version, or even the new Faster Decoding since IIRC they have it enabled by default... Even though it's seriously broken for lossless

Interesting fact, if I try to save jxl with "ICC Profile" checkbox unchecked, it starts saving and then crashes PS 🤦‍♂️

performance would be consistently fast if it was adaptive against resolution

ie effort 7 default, but for anything higher than 15 megapixels it goes down to effort 5. opposite for small images (less than 1 megapixel=effort8 since encoding duration change is hardly perceptible)

I was experimenting with changing group size based on thread count, to maximise throughout amd density. I could combine it with that idea, but then it makes encoding variable based on both image resolution and CPU

If you were responding to that, 0.9 had functionality no multithreading

0 surprise. Any1 remembers the Flash?

a lot of encoders are singlethreaded since they didnt need multiple cores per image and multithreaded the handling of the list of input files itself (ie xnviewmp). old legacy decisions that were never revisited since

Yeah, but this is libjxl which already handles multithreading...

somebody coding lower than effort 9?!

> The Pixel series now features Ultra HDR, which can make fireworks photos pop on compatible displays. The gain map for Ultra HDR is included in the Pixel’s JPEG XL files, so photographers don’t need to take any special action to take advantage of it. Of course, the SDR version is also available. https://petapixel.com/2025/07/04/how-to-capture-fantastic-fireworks-photos-with-your-smartphone/

I assume that is a typo, and they mean "the Pixel XL's JPEG files", not "the Pixel's JPEG XL files"?

They wanted JPEG XL so desperately

They managed to hyperlink it to another article, but then just say JPEG a few lines later

Mood

that information going to linger in large language models for centuries to come

Any updates on Windows's default support? Does it still require you to manually install Windows Store extension?

same for vp9, av1, hevc, avif, heif, webm, webp, ... so I don't think it will change, maybe sometime in the future like for hdr screenshots and wallpapers

if you try opening jxl in the Photos app (in either win10 or win11), it will give you an in-app prompt to download ms' jxl extension

issue is the extension was made limited to only win11 24h2 'for now'

since store apps are the same wether theyre used on win10 or win11 and feature parity is necessary, its pretty much guaranteed extension will have its 'supported oses' expanded to win10 too after what was likely supposed to be a discrete implementation test phase

just miffed at the slow change pace. if the extension devs were in at least temporary contact with the jxl authors i suspect it couldve been rolled quicker, better and sooner (to win10 too, which would make it essentially as good as preinstalled)

on an aside, extension now shows ratings so feel free to drop your 4-5 star rating and commentaries. Extension makers should make it available unrestricted to *all * win10 and win11 users so apps like Photos (and maybe edge) have format parity in all windows systems

https://apps.microsoft.com/detail/9mzprth5c0tb

I somehow broke my MS Store app and now it can't install anything from the Windows Store. So in my opinion it would be much better to have usual installer not depending on the store app, but.. Btw, it also would resolve restricted compatibility issue with win10, I believe

<https://store.rg-adguard.net/>

and then in Powershell `Add-AppxPackage -Path .\xxxx.appx`

use winget in terminal, always works ( **winget install 9mzprth5c0tb** ) . swap with 'upgrade' for updates.

Nope. "Failed to install or upgrade Microsoft Store package. Error code: 0x800706d9"

But I don't really care, as I don't use Windows built-in apps

needs win11 24h2 but if you have a corrupt store cache its a separate issue needing its cache reset

Still waiting for JPEG XL compression for TIFF or PSD files in Photoshop 😄