JPEG XL

I want it in PDF

TIFF is monolithic and PSD could be bodged like the DNG spec. Krita were considering it though, and we did benchmarks https://bugs.kde.org/show_bug.cgi?id=500877

tiff shiiit

DNG is an instance of TIFF, iirc. So I think you could probably also make a non-DNG TIFF with jxl payload, in principle. Not sure if anything will decode that though.

It'd still be nice to allow JXL in MKV using the RIFF(?) tags in FFMPEG

well you can put pretty much whatever you want in a tiff

Yes but some compression types are more standard than others 🙂

I just thought if you can use ZIP and JPEG compression for TIFF in Photoshop why wouldn't you be able to use JXL compression?

If JXL supported metadata similar to TIFF we wouldn't really need this. But since JXL does not, it being the payload in the TIFF container with TIFF's support for metadata would be good

In my case metadata is the greatest roadblock in the way of total JXL conversion locally

Using exiftool to map certain metadata to other fields is just a workaround, not a solution to the problem

What metadata does jxl not support? It supports exif which is basically just tiff without the image...

Also arbitrary XMP data or brotli compressed data

Is there anything stopping you from putting the jxlc in a Brob for memes

it's invalid iirc

brob box cannot contain box where its type starts with `jxl`

Ahh

would be funny though

can brob comtain brob

Also not

And also not jbrd

The main problem is that metadata fields get shifted around, making it not 1:1 i terms of metadata to the source file. One example I have seen in different threads is the `PNG:Parameters` field, which is used to store prompt information in AI image generation. This field is lost completely lost of not manually reassigned to an unrelated XMP field. Which is kind of a bad, yet a great example, because this field is not a field specified in the PNG spec. But it shows that JXL currently fails/is not equipped to deal with such arbitrary metadata. https://exiftool.org/TagNames/PNG.html `Some of the tags below are not registered as part of the PNG specification, but are included here because they are generated by other software such as ImageMagick.` Another example was that due to locale differences/unicode issue a few files I have have an incorrect field "C¡mera" instead of "Camera". JXL also fails at this. While this one obviously is not the fault of JXL, but that of the software leading up to this point, it nonetheless leads to the loss of metadata – if I hadn't paid attention. A lot of images also contain IPTC and "Photoshop" from this [TIFF](https://stsci-opo.org/STScI-01G8GZNXYCJZP89S5GHDV364ZY.tif) from [webbtelescope.org](https://webbtelescope.org/contents/media/images/2022/033/01G70BGTSYBHS69T7K3N3ASSEB) for example. For one, the original TIFF has ``` Subject : NGC 3132, Southern Ring Nebula, Eight-Burst Nebula Title : Southern Ring Nebula (NIRCam Image) Object Name : Southern Ring Nebula (NIRCam Image) Keywords : NGC 3132, Southern Ring Nebula, Eight-Burst Nebula ``` The JXL only has ``` Subject : NGC 3132, Southern Ring Nebula, Eight-Burst Nebula Title : Southern Ring Nebula (NIRCam Image) ```

There is more, but I don't need to specify each field here

Regarding the "Photoshop" metadata, this is almost completely discarded, i.e. [Photoshop] Writer Name : Adobe Photoshop [Photoshop] Reader Name : Adobe Photoshop 2022 are gone from the JXL

Currently JXL is without doubt the best choice for images with only EXIF and XMP metadata or even none at all, but for complex metadata it is best to stick with TIFF at this time

I think you are confusing cjxl/libjxl with the JXL spec. There is nothing inherent about JXL that makes it worse than PNG or TIFF at representing metadata.

As far as I know IPTC is not supported in the spec, right?

I am aware of the difference, but in the current state of libjxl being the only encoder readily available, I was speaking only for that specifically

Which is why I was writing as I was

It is not in the spec no. IPTC is basically old deprecated syntax for a subset of Exif fields, so we felt it made more sense to not mention it and encourage applications to use more modern syntax like Exif or XMP. There is nothing in IPTC that cannot be represented also in Exif or XMP.

But nothing prevents applications from adding a custom box called `iptc` and putting stuff in it.

The legacy binary [IPTC-IIM](<https://iptc.org/standards/iim/>) format was largely replaced by XMP.

Even the IPTC itself is calling that old iptc-iim syntax "legacy" and has been promoting XMP for at least a decade or so

Luckily IPTC is quite rare nowadays. I have mostly encountered it with TIFF files from NASA, as listed in my message earlier. The problems remains with arbitrary metadata like `PNG:Parameters` and malformed metadata fields like `C¡amera`.

Malformed fields are mostly ok to ignore imo, but `PNG:Parameters` does not have a real a replacement with XMP

I'm not a big fan of PNG's approach of arbitrary unstructured text metadata. Of course we could just stuff those chunks in some `text` box (with or without `brob`), but to me it seems more useful to have metadata fields that have some well-defined/standardized semantics. XMP is extensible (that's what the "X" means), so there shouldn't be any issue to add a field for genAI prompt parameters or whatever. Putting all the metadata together in a single XMP seems like a more robust approach than having various pieces of freeform text metadata that easily disappear when transcoding from one format to another.

what if the user does want completely unstructured text data, like user-defined or something

like a personal note or something schemaless

i guess XMP can just have a auxData or something

I mean, if you don't care about interoperability since you completely control the workflow, you can just add your own custom boxes or use whatever other convention you like to use. Standardization only matters if you want interoperability.

What happens when it's converted to TIFF? Since TIFF and JXL have equivalent metadata structures, what if you convert it to TIFF first and then to JXL?

What happens depends completely on what the conversion application happens to do...

Well <@167354761270525953> seems to be implying that TIFF is working well, and idk what they are using to convert

libvips and ImageMagick both work well for converting TIFF to JXL. I use exiftool afterwards to copy metadata and file timestamps to the converted JXL

(to verify)

seems waterfox **for android** now includes jpegxl decode and enabled by default

https://github.com/BrowserWorks/waterfox-android/releases/tag/1.1.0

previously, the support was only in the desktop version of firefox, wich was based on firefox ESR (128) but rebasing on 140

first browser with jxl support parity between desktop and android (cromite supported jxl with parity for a few major versions and hasnt restored it yet since a breaking change in chromium)? apart from safari in apple's ecosystem

Thorium has had full JXL support on Desktop & Android for a while now

really outdated and unsafe builds for everything though, no ? (latest ver for thorium android is m126, over a year behind and missing crucial security fixes from upstream)

This is what the Thorium dev says about that: > If you are very concerned about Thorium not always being on the latest Chromium, then perhaps use another browser, or only use Thorium for specific tasks like JPEG-XL or viewing FTP sites. I use it all day, everyday, for work and pleasure, on all my various computers/old phones, since 2021 when I started the project. I've never gotten hacked, or gotten malware. That isn't to say that some zero-day, that they may have patched in a minor revision that Thorium hasn't been updated to yet, couldn't leave Thorium more vulnerable than Google Chrome for instance. It is just that usually, it would have to be a targeted attack, and running this build based on Chromium M130, rather than M132 (the latest at the time of writing), isn't going to turn your computer into some sort of virus magnet all of a sudden. Basically all I am saying is that the complaints and reasoning are very valid, but perhaps some of ya'll are getting a little too afraid and/or heated about it. (People getting mad at me on Reddit, or spamming my email with links to new zero days that have been found in Chromium).

also doesn't work half the time

anyone tried waterfox for android 1.1.0 ? if not yet available from google play, get it from githube (linked above)

Yes I installed from GitHub

just tried it, actually works unlike thorium, but transparency and animations do not display properly

so currently same as firefox nightly (fx has jxl disabled by default though), built without the extra patches for alpha, animation and hdr (probably needs a hdr-capable device to verify) ?

should be a quickfix rebuild away for unofficial and next official builds

In Waterfox windows animation and transparency works properly. Android version doesn't.

hmmm

Some image display properly now, some are worse, and some don't display at all anymore

The jxl library used in the app hasnt received a commit in over 6 months

im still waiting for an alternative, iacobionut's gallery is ok but I found it to be super slow

at this point im considering just using termux and some file app lmao

The not so funny thing is that at least for samsung AVIF is not an alternative, since the samsung gallery is unable to properly display HDR AVIFs, often they don't even load.

Fossify gallery works for displaying, but HDR AVIFs also don't work here

THe most consistent app for loading HDR images, whether AVIF or JXL, is image toolbox, which is not a gallery app lol

it would be nice if aves actually supported jxl [cheems](https://cdn.discordapp.com/emojis/720670067091570719.webp?size=48&name=cheems)

Just use 2-3 different gallery apps so that it all works

surely this is the best option

couldnt aves be compiled with jxl support in? if that code doesnt get upstreamed, it could form the basis of a new gallery app instead of staying unofficial compiles

it uses flutter so someone would need to make a flutter library compatible with the image library it uses and integrate it

We all need create own gallery app

Why doesn't the base android distro come with fundamental basics like a file manager and gallery?

it does? well it has a file manager, not a gallery

I dont think AOSP includes a gallery

On Pixel you only have Google photos by default iirc

it does have one, no one uses it since its super basic and somehow even worse then lineage's gallery

its been deprecated for a while too

Yeah, Google wants you too use their photos APP, of course with an account

google removed them from aosp to force oems to use google's apps or spend a lot to create and maintain their own. aosp shouldve always had vendor neutral apps that reduce duplicated effort but lineage solves that somewhat

anyone remember the 'aosp browser' ?

best chance to change that is lobbying the 'supporters of chromium-based browsers' group that was formed to insinuate chromium is not a google-controlled project with worse practices than EEE (what they want exclusive they release in chrome, what they want forced on the world they commit into chromium instead). a number of its members seem to already be pro-jxl but strongly need to prevent effort duplication so its easy for everyone to push enabled by default

google removed them because they were trash and barely usable. the file browser still exists and is available for any ROM if they want to use it

if there are perfectly suitable open source alternatives, maintaining the upstream peices if crap is nothing but a waste of dev time

most roms even still have a limited version of it, if you go into and app manager and run `com.android.documentsui` you can still run it manually

most roms just use this for loading documents providers but its a fully functional file browser

yeah, the real sad thing is that there is no good foss gallery app. The best three we have are fossify, which we all know what the issue is there. iacobionut's gallery which is regretfully rather slow and is limited in features, and aves which doesnt accept PRs

lineage recently relaunched their gallery app but released without jxl support or a play/fdroid updatable listing - called Glimpse, no longer based on aosp gallery2, rebuilt on Glide

fossify's a good option but imo increasing reach should not keep 3rdparty builds with working patches and if necessary even forks with different names and roadmaps taboo

upstreaming is only *ideal* and should never be the only option

glimpse is abysmal 1/10 gallery

does it follow in the footsteps of previous aosp galleries, or is it bad even compared to them

its one if those generic super simple gallery apps and it has baf performance, can't adjust literally anything in it

its like, a bad version of iacobionut's gallery pretty much

sheesh

termux libjxl package does not enable plugins, so no pixbuf support atm lol

simply compile from source [galaxy_brain](https://cdn.discordapp.com/emojis/657649371038482482.webp?size=64&name=galaxy_brain)

you could probably do a crosscompile from your pc lmao

compiling packages for termux isnt hard, but it takes a dumb amount of space

https://github.com/termux/termux-packages/pull/25477/files gdkpixbuf support pr, it seems to have a hard dep on it for now tho

Seems like the Blender PR finally works, but the resulting JXL has a corrupted EXIF tag from somewhere https://projects.blender.org/blender/blender/pulls/143313

JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 1920x1080, (possibly) lossless, 32-bit float (8 exponent bits) RGB+Alpha Color space: RGB White point: D65 Primaries: sRGB Transfer function: Linear Rendering intent: Relative Brotli-compressed Exif metadata: 54 compressed bytes Seems like we need to focus on fixing metadata handling in OIIO.

Has iOS 26 removed that - (hyphen) between JPEG and XL?

microsoft's jxl extension got updated to **1.2.28.0**

still unreasonably limited to win11 24h2. maybe we should insist its availability is expanded asap to win10 as ms' Photos app and others need file support parity between win10 and win11

im pretty sure MS wants win10 to die asap so I doubt they will lol

store apps are designed to have parity and not being dependant on any particular version of an os or its support cycle. store apps wil long keep receiving updates after win10 is sort of abandoned

here, just as it was arbitrarily set to 26100.0, itd be as simple to set or add 19045.6156- upstream libjxl runs on both anyway

thats my point

M$ won't want it to work on it at all

tbh i think that wasnt considered. awareness of the extension seemed more accidental than deliberate during a discrete wip cycle whose final build is meant to have wider availability once the big moving parts stabilize

Awxkee said in he doesn't plan to update it until this is resolved: https://github.com/libjxl/libjxl/issues/3887

Well, I see where he is coming from, if adding a single lib adds that many megabytes

it would be nice if he also added progressive support 😔

what app would progressive support help?

image toolbox, jxl images produced using it aren't progressive because awxkee's library doesn't have it

oh you mean an encoding flag

So... Irfanview updated the JPEG XL plugin a while ago, and now they're exposing effort 11 with no safeguards 💀

at least it tells you "VERY slow!!!"

this makes more people curious and try

Is it not possible to set quantity to 99 or 98

You can, I was doing lossless

this (proprietary) Java library claims to have a pure Java decoder: https://support.idrsolutions.com/jdeli/tutorials/reading/java-jpegxl-reader

Apparently they have a Discord server too where you can talk to the developers

updated: waterfox for android now reportedly supports alpha and animation in 1.1.3. no word on hdr but since desktop waterfox will no longer track ESR and instead follow regular FF, thatd make consistent support between desktop and mobile

finally some good UI

Yeah, better to just say "do not use efforts above 9"

"Don't" is often interpreted as "yes" to some people

If they try, at least they'll know why they were explicitly told not to :D

I was considering outright disabling non-chunked encoding, only having it enable if you specifically use Patches, progressive, ect

Though... IIRC the highest level of chunked isn't implemented yet

now it works but wide gamut might be broken now

chat is this real (i haven't been updated in a while on jxl news) https://fixupx.com/peach2k2/status/1959732489078861885

Billions must use JPEG XL

i got curious myself and checked, yep it's real

Imagine if this is the first post in <#803379415106584626> in 2 years

it's hard to find any info about their tech stack, so i assume they have their own CDN

most other CDNs would probably not want to be associated with them ig...

the first image in the post shows 2 CDNs one with JXL and one just doing JPEG

the one serving JPEGs has a name that seems closer to the host site using it

both might be owned and operated by the host site idk

I'd assume JPEG is advertisements

as far as i can tell, they're both thumbnails

though interestingly the first CDN is being served over IPv4, the second over IPv6

i can't discern a clear difference as to when one is used over the other, they might just be balancing traffic between the two CDNs

realll

PH on the cutting edge of technology

I mean what did you expect an image codec to be used for? Why you think the net was born?

https://youtu.be/LTJvdGcb7Fs

They're using effort 4 or below with empty EXIF and XMP tags 😔

All 8x8 blocks and around 300 bytes of empty space

Porn often leads the advancement of technology

Chrome team: Pornhub is just a small website

Is there any new report or announcement? I want to add to Wikipedia

Add

The two ways humanity advances. Conflict and Porn.

With so many CDNs using the low efforts of lossy, maybe we should explore possible improvements there. Right now it's essentially XYB JPEG with ANS

The developers of Pornhub should be invited to our server

fresh off the oven - **ACDsee 2026** added support for jpegxl apparently

this is what it says *ACDSee Photo Studio 2026 is ready for the next generation of image formats with support for opening, editing, and saving files in JPEG XL (JXL). Positioned to modernize digital image storage and transmission, JPEG XL offers much better efficiency and quality for photography and digital art than plain old JPEG. Broaden your editing and metadata options with added IPTC metadata support for JPEG XL (JXL), and AVIF formats.*

not directly related, but acd has a photo hosting/backup service so its possible their stack could include uploading and serving jxl

Ok, I just tried opening an animated-jxl in gwenview, and the animation plays but the CPU instantly shot up and remained constant like it's endlessly decoding the image over and over again, and the memory usage of the gwenview process is also steadily, endlessly climbing like there's a memory leak.

Sounds about right

qview ftw but yee similar

https://endless-sphere.com/sphere/threads/heic-format-support.128574/#post-1864230

Jpegli adoption

https://bugzilla.mozilla.org/show_bug.cgi?id=1986393

built one locally, animation is working fine

We're hoping they can add Username's idea of selectable progressive modes in the `about:config` menu, so you can choose between Oxide-style ultra-progressive or libjxl 1:8 full pass progressive

speaking of. does https://google.github.io/attention-center/ work with it currently? <@206628065147748352>

nope, only fully loaded ones show up for now

https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 > For posterity and reference, I'd just like to document here that as of right now, the jxl-rs decoder that we're integrating is not of production performance, It currently decodes ~4M pixels/s on a mediocre laptop, which we expect to improve a lot in the future.

I hope jxl-rs improves on libjxl and jxl-oxide in terms of ram usage for decode, rn that is for sure the greatest painpoint i've had

I imagine you mean for lossless?

just for larger images in general, it can take a good amount of ram to decode, for instance this the png here is just a `djxl --num_threads 1 mona-jxl.jxl mona-jxl.jxl.png` ```ps ➜ jxl-test time djxl --num_threads 1 mona-jxl.jxl /dev/null --output_format ppm JPEG XL decoder v0.11.1 794a5dcf [AVX2,SSE4,SSE2] Decoded to pixels. 7432 x 3877, 16.599 MP/s [16.60, 16.60], , 1 reps, 1 threads. djxl --num_threads 1 mona-jxl.jxl /dev/null --output_format ppm 1.15s user 0.61s system 98% cpu 1.777 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory: 1001 MB ➜ jxl-test time jxl-oxide --num-threads 1 mona-jxl.jxl 2025-09-04T10:33:25.785851Z INFO jxl_oxide_cli::decode: Image dimension: 7432x3877 2025-09-04T10:33:27.958090Z INFO jxl_oxide_cli::decode: Took 2172.19 ms (13.26 MP/s) 2025-09-04T10:33:27.958114Z INFO jxl_oxide_cli::decode: No output path specified, skipping output encoding jxl-oxide --num-threads 1 mona-jxl.jxl 1.40s user 0.81s system 98% cpu 2.236 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory: 1158 MB ➜ jxl-test jxl-oxide info mona-jxl.jxl JPEG XL image (BareCodestream) Image dimension: 7432x3877 Bit depth: 8 bits XYB encoded, suggested display color encoding: Colorspace: RGB White point: D65 Primaries: sRGB Transfer function: sRGB Extra channel info: #0 Alpha Frame #0 (keyframe) VarDCT (lossy) Frame type: Regular 7432x3877; (0, 0) ➜ jxl-test time pngtopnm mona-jxl.jxl.png > /dev/null pngtopnm mona-jxl.jxl.png > /dev/null 0.80s user 0.09s system 98% cpu 0.907 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory: 113 MB ```

mhhh, I wonder where the libjxl memory goes, it shouldn't be that memory intensive... can I ask you to run massif on the decoder?

oh I should run on debug, lemme compile

here ya go :D

`valgrind --tool=massif ./tools/djxl --num_threads 1 mona-jxl.jxl --disable_output`

I wonder what's the real reason why `--disable-output` is not the same as outputting to null

Didn't we already figure out it's because disabling the output defaults to float 32

yep, output is 400mb here, instead of 100ish

something seems off though, can you print the value of `num_buffers` at https://github.com/libjxl/libjxl/blob/main/lib/jxl/render_pipeline/low_memory_render_pipeline.cc#L384 ? (also maybe we should move this to <#804324493420920833> )

Yeah, I just meant `--disable_output` versus outputting to null. There's always been a bit of a memory black hole

Ohhhh, It's happening

Does anyone know who's who in that thread? I recall `saschanaz` as contributor of previous JXL support. Are they from mozilla, or jxl team? And from which crew `Martin Bruse` is?

Ok, `Martin` is from Google Research - `zond` in jxl-rs repo

first person you mentioned is from Mozilla but is very interested in JXL and also the creator of this project/repo: https://github.com/saschanaz/jxl-winthumb/

Ahhhhh, cool

So according to Tirr in this patch series animated/transparent jxls work without additional patches, right?

There was also a user `wvvwvvvvwvvw` who was involved in Firefox JPEG XL support. Was he from mozilla team?

Or he was an original author of the Firefox implementation?

Was that <@288069412857315328> or just similar name?

that's me

Ah, cool

no way jxl actually happening? (i haven't checked in a while)

Apparently there's a chance 🙂

I hope they'll take all functionality from the patches you provided into consideration

it's not done by mozilla...

which means not tracked by mozilla

and not approved by management

I'm very keen on seeing how it goes

The new integration is being done by JXL devs (check the branches) <https://github.com/zond/firefox/tree/jxl-rs>

Thanks for the link. What I mean is that hopefully there won't be missing functionality, like that which `w` patches were filling in the previous implementation.

There seem to be some unavoidable maintenance-delay for merging into the main firefox repo due to Rust version required by jxl-rs <https://bugzilla.mozilla.org/show_bug.cgi?id=1986626>

Maybe some MSRV policy, at least tracking what version of Rust Firefox is using needs to be created for the future

(Previous such minimum rust version update was for Rust 1.82: <https://bugzilla.mozilla.org/show_bug.cgi?id=1945020> and took about 30 days)

Wasn't it Alpha, Animated and progressive? The first two are done, and progressive should be soon I'd assume

Yep, those three, plus there were also patches for ICC, which didin't make into nightly.

<https://bugzilla.mozilla.org/show_bug.cgi?id=1709814>

(dunno if jxl-rs and/or the current Fx JXL implementation are capable of handling ICC

and probably HDR, for which there was no patch, only bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=1709857>

well Firefox itself does not support HDR however that patch for the JXL handling that added color profile support made it so tonemapping worked

I don't necessarily mind waiting 30 days, jxl-rs will look a lot nicer by then, I hope 😄

but https://blog.rust-lang.org/2025/05/15/Rust-1.87.0/#safe-architecture-intrinsics is kinda nice to have

waiting for multithreaded pipeline runner 😉

yeeeah working on it

it's, uh, a bit of a challenge

In <https://bugzilla.mozilla.org/show_bug.cgi?id=1986626#c1> `saschanaz` is considering going for 1.86, but then maybe 1.87 should be the target

yep told them

So jxl-rs will be on the bleeding edge for some time I guess

Oh, nice, there are some estimates of what Rust versions (but no MSRV) will be used for future firefox builds <https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html>

`The MSRV won’t be updated to a version of Rust that hasn’t been used for Firefox Nightly for at least 14 days.` But I think they're not on 1.87 yet

not sure we need the MSRV for nightly to match, tbf

Yep, seems not needed for nightly developement `As a general rule, we update the Rust version used to build Firefox Nightly soon after its release, unless it’s less than 7 days away from a soft-freeze, in which case we wait for the next Nightly train.` Tho the talk in the bug mentioned enabling it in Releases, just with `pref` disabled, so for that case it would be needed

In the comment `saschanaz` says that `the existing AVIF decoder also support it, it should also be able to be done in nsJXLDecoder.` (refering to HDR). I dunno if it's a misunderstanding on my part, and I don't have a display capable of seeing if AVIF HDR actually works.

JXL thumbnails still don't work on macOS 26 Public Beta 6/Developer Beta 9 (25A5351b)

use linux, there everything working

did you miss last year when a mozilla representative said that they'll support jxl once it has an official rust implementation? and a mozilla dev is quite literally tracking development

<https://github.com/mozilla/standards-positions/pull/1064> > To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.

firefox nightly (still on libjxl?) has a lab entry and study going on but its wasted if there isnt an origin trial with at least one website (preferably one cdn or image host) with large enough reach it can provide useful data about implementation, ressource consumption and any other woes

Nightly doesn't even have transparency, once the rs fork is merged then propper testing can commence

sorry for the late ping/message but how do HDR images show up? reason I ask is because tone-mapping is still [marked as a WIP for jxl-rs itself](https://github.com/libjxl/jxl-rs/issues/58#:~:text=to_linear%20(->%20to_linear.rs)-,tone_mapping). here's a page with a bunch of HDR JXLs for testing: https://web.archive.org/web/20240208234112id_/https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php I would also be interested to see how well the non-HDR tests here fair as well: https://kampidh.com/jxltest

I'd expect banding for HDR images, but let me see when I have access to my desktop

oops my build of firefox is garbage collected by nix, will take some time to rebuild

https://www.philips.com/a-w/about/news/archive/standard/news/articles/2025/philips-announces-digital-pathology-scanner-with-configurable-dicom-jpeg-and-jpeg-xl-native-output-in-world-first

unrelated quick reminder for photographers, **ACDsee 2026** now supports read/write for jxl

hmm firefox build fails somehow

r3dfox has it

Now that I read about it, r3dfox has the old C++ jxl but with transparency and animations

I'm not aware of any browsers using the rust decoder yet

I surely hope so!

there's a good chance jxl-rs might be used in Servo. as for most Firefox forks that have full JXL support they are simply piggybacking off of the disabled by default unfinished libjxl implementation and merging in the patches that never got reviewed for it. once Firefox itself removes that implementation and replaces it with jxl-rs then those forks are just going to use the new jxl-rs implementation instead. those include browsers such as Waterfox, Floorp, Zen, likely r3dfox, and whatever else is based on modern firefox.

Yes, and that'd be nice

But not *now*

yeah. speaking of what's the situation with tone-mapping in jxl-rs? I see that it's marked as a WIP however the person assigned to it seems to have never replied back?

"need Rust for ensure safe" are almost an excuse

[Firefox use dav1d](https://hacks.mozilla.org/2019/05/firefox-brings-you-smooth-video-playback-with-the-worlds-fastest-av1-decoder/) for AVIF, you can look [how many ASM in dav1d source](https://code.videolan.org/videolan/dav1d)

probably not the highest priority at the moment, but it will probably happen eventually?

actually insane oh gotta use Rust for everything, but shitty Google codec gets to bypass the requirement

Rust in Firefox was a mistake

To be fair though, dav1d was added years ago

How many new non-Rust libs have been added to Firefox in the last couple of years?

The only mistake is that there is still C++ in Firefox

it will likely be replaced with rav1d eventually

rewriting a browser engine in Rust is _hard_ 😛

what would the benefit be?

it's slower and not particularly safer

Indeed

not yet, but the goal is to be eventually, not sure how long that will take, but prossimo does have a good track record of not abandoning projects.

~~still waiting for spidermonkey rust rewrite~~

I don't think it'll ever be "safe enough" as long as they keep around all the asm files

the asm isn't too bad, but there is still a lot of glue around it, but for me the strength of rav1d is disabling asm, which is fine for me since risc-v doesn't have a whole lot of asm in it rn anyways :D

Even harder when all the mozilla devs working on it get fired so mozilla can focus on important things like giving their admin staff big bonuses and raises.

and those useless so-called "AI" features

finally built and tested with commit [`3de721a`](https://github.com/zond/firefox/commit/3de721abd0f06d010def61848e2815fa855c625c) and they all crashed with segfault

reported to zond, they'll look into it

I'm sure someone's already told them, but could you mention an additional flag to select the progressive mode?

That didn't happen though. Lots of people writing Rust code for Gecko at Mozilla.

So all the servo devs getting fired didn't happen then?

The serve devs weren't working on re-writing Gecko in Rust, so

isn't gecko still mostly C/C++ even excluding spidermonkey?

still a shame that mozilla killed of servo considering how much promise it had

Integrating components from Servo into Gecko was a huge effort that took years. Gecko is still mostly C++, but much Rust development happens directly in Gecko.

I’ve been called spider-monkey before

(title of the comment: https://www.dpreview.com/forums/post/63496916)

Servo was to replace parts of Gecko, piece by piece. They even had an entire project dedicated to replacing c++ gecko components with rust servo components, like webrender!

It was called project Quantum!

Which they abandoned after firing all the researchers

Firefox is on literal life support maintenance mode with hardly any of the budget allocated to developers

The company is being milked dry like a shriveled husk of its former self

The goal of Servo was to figure out how to make a browser engine in Rust. Fully replacing Gecko was never the intent. Like I said, lots of Rust development now happens directly in Gecko instead.

It's running on pure brand reputation now

Also, tf are you talking about? Firefox development is literally Mozilla's biggest budget item.

uhh, no? The Project Quantum project was completed in 2017, and was an effort to re-architect and modularize Firefox. It is what allowed Servo components to be integrated, but it has nothing to do with replacing Gecko with Servo.

It's been a while so maybe I'm remembering wrong, but I thought developer salaries are a small fraction of their expenses, compared to administration salaries and other things that have nothing to do with developing firefox

I stopped keeping up with mozilla news years ago, when there stopped being any good news from them ever.

They used to employ a bunch of codec devs from the xiph research team too

<#806898911091753051>

They used to have all of the smartest engineers on their payroll and they just let everyone go

Preview on iOS/iPadOS 26 can't open JXL

Iridient Developer (raw converter, macos only) now supports jxl, as well as jpegli https://www.iridientdigital.com/

ACDsee 2026 is now available with jxl read/write out of the box. a free 15-day trial is available to check out

I thought it's been available for a month already https://discord.com/channels/794206087879852103/803574970180829194/1410496452228026368 https://discord.com/channels/794206087879852103/803574970180829194/1414654828629721149

preorder phase iinm

apps like lightroom, zoner and acdsee have high reach among enthusiasts so itd be preferable if their jxl capabilities were tested and any anormalities adressed so it doesnt reflect poorly on the entire format

That's assuming they'd actually listen to and fix any problems

implementation woes can be blamed on unfamiliarity with jxl's modern paradigms than unwillingness

even gimp's is kinda mid, flattening multilayer images saved to jxl without even telling you

image-sieve back from the dead to merge jxl-oxide support 0.0

https://github.com/AlienCowEatCake/ImageViewer

interesting, it supports ICC (including XYB), but does not tonemap correctly HDR

does that mean it also doesn’t make use of the tonemapping LUT in our HDR ICCs?

that could be a stopgap solution

Oupson's "Jpeg XL Viewer" for Android just got updated recently and added a gallery mode, as well as PNG export. It's pretty rough compared to a dedicated gallery app, but pretty decent as a standalone option.

Sadly crashes when opening hdr images

Try fossify gallery

I use it daily. And I was one of the users lobbying for JXL support in it (actually, back when it was Simple Gallery Pro, even). So, that's what I was comparing Oupson's update to, mainly. Oupson's viewer has the advantage that it decodes the images at full resolution, whereas Fossify Gallery, using Awxkee's plugin, apparently decodes at initial viewing resolution and doesn't change it when zooming it. So, Oupson's viewer, or ImageToolbox, can be a workaround for large screenshots that you want to read, for instance.

I haven't put any effort into revisiting, tbh I haven't done much android related programing in general lol

Why jpegxl viewer needs internet connection permission?

to view images on the internet?

how

oh, it has "share" function, maybe for it

It need it to open file from internet, with action_view intent. Tbh I only use it with custom intent when I develop as firefox does not offer the possibility to open file in app directly. I should add the possibility to share a link with the app to view the file.

Can you send me a file I can test (and a logcat if possible) ?

wait- I can't open .jxl files in default ubuntu viewer? 😢

Corporate shit OS

I think you need some gdk-pixbuf package, but dont ASk me which one exactly

Give me a few days, I am away currently

glycin

unless they still want you to use the libjxl gdk plugin directly

there are multiple files I have which crash the app, but the error message leads me to believe that it may be to do with resolution

hey what's that in the bottom right corner

<https://pdfa.org/news-and-views-touching-on-pdf/>

microsoft's windows extension for jpegxl just got updated today (now **1.2.32.0**). unclear what changed

i wish anyone would contact its devs and let em know relaxing the system requirement to the latest snapshot of win10 would be cool now that its no longer in early development phase - even if it means limiting its use to only the Photos and/or edge app so apps can have consistency of support (photos app on win10 asks users to download the extension but store puts an illogically arbitrary demand to upgrade to win11 it puts on no other extension like webp's)

So, any news about support?

Well if you read above, PDF is adding support next year, Microsoft are continuing to update their support and Firefox is being worked on

do we know more about whether the addition of JPEG XL into PDF would result into the PDF Association making ISO/IEC 18181 free to access, like they did for other standards that were adopted by PDF?

there was some discussion about that, but I don't remember much of the details

0.0

All the devs wanted JXL to be a free standard, but the abhorrent price of ISO specs made it unfeasible and Adobe are the only ones to have a free agreement with them, so we'll see

oh?

that's a shame

I think they were just doing a face

oh I thought they meant 0.0% chance that would happen

from what I understand, this is the “Japanese school” of emoticons, which puts more emphasis on the eyes (`T_T` `O.O` `-_-` `^_^` `>.<`) rather than the mouth (`:(` `:D` `:O` `:S` `:)`)

right: https://en.wikipedia.org/wiki/Kaomoji

yes it was a face, didn't know it was more Japanese style tho

-# I prefer 0.o tbh

get with the times: “😳 ”

or the new unicode woag 🫪

¯\_(ツ)_/¯

However emojis are originated from Japan too

The west had the same thing on forums

I still dunno the distinction of all the terms, but I know that 0.0 has been used since bbs

A hardware encoder IP has been released. (currently, the following PR is in Japanese only) https://www.shikino.co.jp/wordpress/wp-content/uploads/2025/10/pressrelease20251007.pdf

Oh wow, that's big news!

(not sure why I clicked on the pdf link to try to read it :P)

Commercial Release of Encoder IP for the New JPEG Standard "JPEG XL" ~ Providing a new IP core that achieves higher image quality and compression compared to conventional JPEG ~ Shikino High-Tech Co., Ltd. (hereinafter “Shikino High-Tech”) will begin sales of its JPEG XL encoder IP core, which can be implemented in ASICs and FPGAs, starting October 7, 2025. The JPEG XL standard offers high image quality (HDR support) and high compression efficiency compared to conventional JPEG. Shikino High-Tech’s encoder IP core maintains these advantages while achieving a compact circuit design and low power consumption. Furthermore, with the cooperation of CAST, Inc. (U.S.A.), with whom we began a partnership in March 2025, we will promote overseas sales of the product.

Features of Shikino High-Tech’s JPEG-XL IP Core Shikino High-Tech has been developing and marketing JPEG products for ASICs and FPGAs for over 20 years. Leveraging our extensive experience in JPEG IP core development, we have independently optimized the design to achieve a compact and power-efficient JPEG-XL encoder IP core. Main Features: Circuit size reduction through optimization of DCT size, quantization parameters, and encoding methods. Optimization of circuit scale, SRAM usage, and bus bandwidth in collaboration with the standardization committee. Customization options such as additional I/F features and core modifications. One year of free support and prompt response to inquiries.

This is what ChatGPT 5 Pro gave me: **Commercial release of encoder IP for the new JPEG standard “JPEG XL”** — New IP offering that enables higher image quality and higher compression than conventional JPEG — Shikino High‑Tech (hereafter, “Shikino High‑Tech”) will begin sales on October 7, 2025 of an IP core for JPEG XL that can be implemented in ASICs and FPGAs. Compared with conventional JPEG, the JPEG XL standard features higher image quality (with HDR support) and higher compression. While preserving these advantages, Shikino High‑Tech is offering a JPEG XL encoder IP core that achieves a small circuit footprint and low power consumption. Furthermore, with the cooperation of U.S. company CAST, with whom we began a partnership in March 2025, we will promote overseas sales. **About the JPEG XL standard** A new JPEG standard delivering high compression and high quality, standardized in January 2022 as ISO/IEC 18181 by ISO/IEC JTC 1/SC29/WG1. Key features Supports wide color gamut and HDR, enabling compression and decompression without loss of realism. Higher image quality and higher compression than conventional JPEG, making it possible to reduce storage costs. Optimized for human visual perception through the use of perceptual color spaces and adaptive quantization. **Features of Shikino High‑Tech’s JPEG XL IP** Shikino High‑Tech has developed and sold JPEG products for ASICs and FPGAs for more than 20 years. Leveraging our extensive experience with JPEG IP cores, we have independently optimized the design to realize a compact, low‑power JPEG XL encoder IP core. To minimize the IP circuit, we optimize JPEG XL functions such as DCT size, quantization parameters, and coding methods. In collaboration with the standardization committee, we optimize circuit size, SRAM usage, and bus bandwidth. We can accommodate added interface functions and customization of the core itself. One year of free support with prompt responses to inquiries.

not very different from GPT-5 Instant

Anyway it is very big news. It will now be a lot easier for new models of phones and cameras to start using JXL as a capture format.

Google cockblocking it in Android in 3.. 2.. 1..

I'll be very curious to see the JXLs produced by this encoder.

I wonder if it's very similar to jxl-tiny, or if they found any good tricks to be fancier than that without too much hardware cost.

it should be pretty similar to jxl-tiny, since it's essentially based on that (though with lots of changes in the details to get better data dependencies / reduced sram buffers etc)

It's a shame we didn't find a simple fix to the desaturation first, or blacks being crushed in high bitdepth encoding, but it should be plenty capable compared to existing JPEG captures

I'll type up a short announcement on Reddit. jxl-tiny is lossy only but with control over quality, correct?

Yes. It is a simpler than full libjxl encoding, e.g. does not use block sizes larger than 16x16, and certainly doesn't try to do anything like patches etc.

In the low-quality region it is clearly not as good as full libjxl, but in the range relevant for camera, the difference is small

Yeah, generally larger blocks are rare at such high quality anyway

Actually, that reminds me. Part of the quality regression since v0.9 was block sizes shifting from mostly small to mostly large, smoothing instead of adding noise

Sony, please add it

They originated in ancient Egypt :-)))

I called them modern hieroglyphs sometimes

still no PRs <:SadCat:805389277247701002>

at least no public ones

Will anyone release an IP block of lossless JXL encoding? Having lossy is great to replace JPEG, but cameras usually use lossless for their raw files. Would be great to be able to see more JXL adoption for raw files.

Conversation on another Discord, rumor ofc so take with grain of salt: > Yeah, DCPs are iirc working on a transition to JXLs in the near future though, but that's a "by 2030" thing. > oooh? 👀 > please tell me where you heard that. > Whispers from an industry gathering I happened to be sitting at the same McDonald's as. > So, no idea how accurate it is or can be.

DCPs as in Digital Cinema Packages?

Yeah

I suppose if JPEG 2000 makes sense for DCP then it also makes sense to use JXL for that.

I wonder if they'll want a hardware decode impl for that (DCP systems use, or at least used in the past, J2K IP blocks from Xilinx running on an FPGA)

I would assume that would be nice to have. But hardware decode will require defining a new profile, since currently we only have the Main profile which includes everything, and that's not something you want to do in hardware.

then again on my macbook I can do jxl software decode slightly faster than what is required for the current maximum supported frame rate and dimensions

240fps (120fps for each eye) at 4K?

I know we previously had around 45fps at 4K, but new tests would be a good idea https://discord.com/channels/794206087879852103/803645746661425173/1366548303579189248

is that the current maximum? I was going by https://en.wikipedia.org/wiki/Digital_Cinema_Package which might be outdated, it says 60 fps at 2K, 30 fps at 4K, 48 fps at 2K stereoscopic. The hardest of those is 30 fps 4K which is about 240 Mpx/s, and on my macbook I'm getting around 270 Mpx/s decode speed.

The old benchmark I linked was 500 MP/s with FD4

So it turns out I'm currently at a table with a GitHub developer, and they said they might be able to allow JXL uploads for the libjxl repo

\🙏 https://github.com/orgs/community/discussions/169478#discussioncomment-14135941

I already showed them that on the train to London, and we ran a few tests to confirm it works and just needs whitelisting

Their advice is to +1/ bump the thread but don't spam it

how about avif as well?

They said to open a new discussion

i still looking for android viewer with normal scaling of jpegxl (as Jpeg Xl Viewer do, but gallery app), Fossify Gallery supports jpegx, but has no regional decoding (not sure i calls it right)

Cropped decoding is only in jxl-oxide

I don't understand why someone would want cropped decode because if you display the image first and then zoom, the whole image is already decoded, so imo you should crop that buffer (and not decode a part of the JXL again), no?

For lossy you can only decode the 1:8, 1:64, 1:512 sized preview before doing cropped decode when zooming in

Accidentally discovered that CaptureOne (raw converter from PhaseOne) switched from (probably) jpeg to jxl in their internal previews. However, it is not a usable jxl, viewers can't open it. Converting old cache folder to the new format compacted it's size from 550 MB to 306, impressive.

That brings explanation to this setting

However, C1 can't neither open nor write jxls 🤦‍♂️

Jxl as compression format in psd and tiff when 😄

Not quite, but https://bugs.kde.org/show_bug.cgi?id=500877

Sounds very nice.

Great way to use JXL lossless compression superiority

And I wouldn't even mind high quality lossy tiff (visually lossless)

and pdf

pdf next year probably

Upcoming tiff revision sometime (based on upcoming pdf-based spec according to the TWAIN group)

Oh?

<https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/743a267bbb305b5ce8e395f0530c7768c109d1f4/src/jpegxl.imageio/jxloutput.cpp#L233> ...*What?*

This is the same repo I had to fight with because they thought `JXL_ENC_FRAME_SETTING_DECODING_SPEED` was for controlling encoding speed, and refused to belive me until I showed benchmarks

I am baffled

They should just be using `JxlEncoderDistanceFromQuality`

what the fuck are they doing?

this hurts so much, someone please make a PR to fix oiio lmao

Considering [this](<https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4812>), I don't particularly want to make another PR... But, I'm also the only one who's signed their life away to the CLA, so I guess I'll try and make one

<@794205442175402004> just to double check, does this look like a correct fix for their quality handling? Relevant code is linked above

LGTM

Yeah that was uh... Yikes <https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4933>

No clue how someone didn't notice that before, it's only because a friend tried to use it yesterday and noticed the filesize wasn't changing

mapping `quality` to distance `1/quality` is a very bad idea indeed, I wonder how they ever arrived at that

I wonder how many images have been encoded at incredibly low distances accidentally

SYN+ACK Déjà:// vu:// https://www.mail-archive.com/linux-media@vger.kernel.org/msg84989.html

??? somehow, until seeing this, I was assuming `compqal.second` would be a float from 0 to 1

so q100 would get you d1 and q20 would get you d5, or something like that

It's purely guesswork, but since my friend said quality was staying near lossless, and the code above was using `compqal.second == 100` for lossless, it was the only explanation

When someone makes a jxl encoder with spline support, they should call the feature "spline reticulation"

https://github.com/FossifyOrg/Gallery/releases/tag/1.8.0

Now pretty much all JXL images on my phone are displayed without issue

even 40-50MB ones

still no regional decoding/zoom, so meh

Kinda hard to add that when the library doesn't support it

Indeed... Although the other day I was thinking that adding that in jxl-rs (at some point in the future) should not be too hard

Oxide already has a proof of concept, so you've got a good starting point. Combine that with a 'non-upsampled preview' option, and you can get the 1:8 without blowing up memory usage, then crop decode while zoomed in

I mean, if we only need to skip decoding the hf I'd say it's even easy (the current render pipeline impl can do that basically for free)

Random thought, but I wonder if the iPhone 17 Pro has different JXL encoding parameters than the 16 Pro for its RAWs

*LightningView* 2.3.0 added jxl support, apparently integrating jxl-oxide. It previously added support for jpegxl-compressed DNG 1.7 Available for windows and linux from github. https://github.com/dividebysandwich/LightningView

Affinity v3 still can open and export JXL

A quick popup for exporting is a big bonus

Well it took 2 weeks, but it finally got fixed https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4933#event-20642310809

https://youtu.be/DjUPSfirHek?t=2149

Damn, I just got the timestamp myself haha

back from the backdoor

food for thought: theres at least 4x more pdf readers installed and in use than browser installs (each browser ships their own, edge ships' adobe's own, doc-focused sites ship mozilla's wasm, and adobe reader has more than a billion installs between desktop and mobile)

Between this, getting a VLC hat and all the progress on jxl-rs, today has been a very good day

🥳

what is it with these technical keynotes/presentations by technical people often having absolute dogshit audio

A traffic cone hat?

https://cdn.discordapp.com/attachments/889987478675656796/1434231906668380200/IMG_8693.jpg?ex=69083ccd&is=6906eb4d&hm=5641415529aca6cf2c27a8f8613225c486b413f0845694e04fdde54e2d04af8c&

Photo courtesy of my friend

I actually brought up JXL in PDF while discussing things with the GitHub dev. Apparently it's a magic cone, because the video got linked as soon as I got home

is it just me or what, recently I can't view jxl images on Floorp on newer updates.. o_o

fresh 12.4.0 install, confirmed. odd, image.jxl.enabled is set to false/disabled by default now and enabling doesnt restore support. maybe just a regression in building, floorp was mostly a one man shop perhaps they skipped librewolf's patch for building and enabling jxl in non-nightly

hey they even linked to the community site

this reminds me of the story of someone dressing up as a vampire that wore a traffic cone as a hat from a scene in *what we do in the shadows*, but everyone thought they dressed up as VLC media player so they just went with that instead <:KekDog:805390049033191445>

It was 80/20 people saying "VLC!" or "Nice cone". You can imagine their shock when I said it's literally from a VLC conference

that's great

Unfortunately I forgot the conference was today too, and I'm too hungover to wake up early, so my friend is there without me again

(Someone tried to install FFMPEG onto a thermostat)

LMAO

vimage image viewer, through switching to magick.NET, now supports jxl. https://github.com/Torrunt/vimage

Update to this chart from some time ago: we (Cloudinary) are currently seeing jxl support in around 27-28% of the requests we get (based on the Accept header; it has been fluctuating around this percentage for a year now), and we are serving around 1 billion jxl images per day now, which is about 3x as much as a year ago.

niiiice

one billion per day is crazy. very nice

what percentage of total requests is that, and what percentage of requests from jxl-supporting agents?

6.7% and 24.4% respectively, when I last looked, but this is of course something that fluctuates and usually it's a bit lower than that, in fact it was the first time I saw the daily number go above 1 billion which is why I felt like doing an update 🙂

whats the priority for serving image formats? is jxl always served at the highest priority if supported?

wondering how many jxl-capable clients are served another format instead of jxl

If the user has jxl enabled, it has highest priority. But still many don't have it enabled. And you can of course only get jxl when using f_auto or f_jxl, so if a customer is using f_webp or whatever, it doesn't matter what the client supports, it will always deliver a webp.

what about avif?

second highest priority, if enabled. Third is webp, and universal fallback is jpeg.

Universal fallback should be ASCII art.

I guess the `alt` description in the img tag is supposed to be the universal fallback.

but it should definitely not be ASCII art since that doesn't work well with screen readers or in braille

we need braille art

Blue noise diffused braille that looks like the image it's describing

now, that's an idea

I propose self-descriptive ascii art where the letters that make up the art also describe the image

ASCII dot art already exist, unfortunately most braille readers are a single line.

I'd guess it might be Shopify in the back, but someone said a secondhand finnish site is using JXL https://www.tori.fi/

Well that's unfortunate. I expected Lightroom to be able to export 10 bit JXLs Does anyone know if it is possible with Photoshop?

Meanwhile AVIF is limited to 10 bit only

Ya know technically JXL bitdepth should just be a slider too

Most programs still handle JXL in the "old" way, so that's fine by me.

But given the fact that the 16 bit option is preselected and leads to filesizes above 100MBs with HDR Output, I would like to see 10 bits lol

~~I'm assuming the canvas is only 8 or 16 bit~~ I am smart, this is lightroom

I could of course export to 16 bits and then use cjxl to reduze the bitdepth

It's a camera raw (DNG), so should be 14 bits, but no idea if that is in a 16 bit container

And also it doesn't really make sense to allow me to export rec2020 with 8 bits, does it?

It's been a few years, but Lightroom is still as bad to use as back then

> It's a camera raw (DNG), so should be 14 bits 14 bit before demosaic, then it becomes 16 bpp

But with the whole discussion about how JPEG XL handles bits, does it even matter? In my tests (ages ago) 16->14->12->10 made little difference when in lossless… Besides Adobe's busted implementation. https://discord.com/channels/794206087879852103/822105409312653333/1432194664710144081

For me that link goes to the start of the channel

in lossless, bitdepth should make quite a difference, unless the higher bit depth versions don't actually have more information but are just scaled up from lower bitdepth, in that case in lossless it should be quite similar thanks to channel palette.

it's only in lossy that bitdepth is "just a suggestion", in lossless the bitdepth does mean different numbers get encoded

In that case it makes even less sense that Adobe offers only 8 bit and 16 bit encoding for lossy *and* lossless

Yes, for lossless it doesn't make sense. It matches what they do in TIFF and PSD though. Always using an integer number of bytes per sample.

Fixed it. But looks like maybe I'm mixing up lossless and lossy. Again.

https://www.design-reuse.com/news/202529665-cast-introduces-jpeg-xl-encoder-ip-core-for-high-quality-on-camera-still-image-compression/

So that's the second JXL encoder IP on the market, nice

oh, no, it's the same one > The encoder core is sourced from Shikino High-Tech Co., Ltd.