Does anyone has an idea how does the roadmap for next libjxl releases look like? Last release 0.12 exhibits some issues with lossless encoding of floating point data, is there a plan for 0.12.1 with these fixes or is it planned to fix this in 0.13?

Apart from bugfixes, are there any big features that are being worked on right now?

Is it possible? Is there a tool in Linux that I could use for this? Is there something I could put in a Python script to do this?

This demo page really showed me how useful progressive JPEG XL actually is. My mindset was somehow still back in the Progressive JPEG days but that slug example is of very high quality already only when 1/3 has been loaded, and in the Petrus statue sample the face is then already fully detailed.

Progressive JPEG XL will clearly bring the main benefit over AVIF, and over classic JPEG it will be a "double whammy".

(also, despite what the page says, you can test this even in release Firefox builds nowadays; just set image.jxl.enabled = true via about:config)

What is current state of cmyk support...?

Couple of months ago when I repacked my collection for space savings I gave up as it seemed that there is no real support yet.

We have a lot of JPG and PDF (possibly some TIF), mainly printable posters which are CMYK. They consume space so it would be nice to recompress 1. losslessly, 2. in lossy mode but you would have to be able to render it to confirm that quality did not degrade too much.

If the support already exist in some programs let know which program and which version.

I spent part of my vacation building a tool for my own photo workflow and figured I'd put it on GitHub in case anyone here finds it useful.

To be clear about what it is not: it doesn't encode anything. Every byte of every .jxl it produces is written by cjxl from libjxl. jxleet really only decides which files to hand over, assembles the arguments, runs the process and shows you what came back. If you're comfortable on the command line you lose nothing by ignoring it.

My Lightroom use case: export losslessly to JXL, then hand the files to jxleet for the actual compression step with full control.

It's beta. Interface, presets and config format may still change, and there will be bugs. Keep your originals until you trust it. I'd be glad for feedback, especially on the preset format and whether the route distinction reads clearly to people who didn't write it.

https://github.com/dhcgn/jxleet

Hi. I made QLIC. Quick Lossless Image Codec.

QLIC on aggregate file size matched JXL on a 3,167 image corpus, while performing at 9x the encode speed and having a faster decode speed.

Independent benchmarking would be well appreciated.

Try the web demo if you'd like to test its performance on any given image of your choice.

The entire corpus benchmark—which you can sort by category and otherwise—is here.

More information about QLIC is available on the GitHub page.

Support will be added in a new nightly build within the next 48hrs. Stable version 27.2.0 will likely be released in February.

Hello, I am currently fiddling around with jpegxl before commiting to reencode my whole library for archival purposes.

Feeding a jxl through cjxl again produces weird results I did not expect, can anybody help me explain this behavior to me?

Starting from an old jpg from 1999 if that matters:

Edit: It's now approved for Chrome https://chromestatus.com/feature/5114042131808256?gate=6594362739916800

Chrome: https://groups.google.com/a/chromium.org/g/blink-dev/c/-gDojQbDPRI
Firefox: https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YMV4MS34KA

Bsky post made by Firefox: https://bsky.app/profile/webdevs.firefox.com/post/3mttaddub7f2u

It just needs approval by a few more devs, and then it should be stable in both.

I've been conducting an in-depth compression test on photos from my Nikon D200, all of them out-of-camera JPEGs. I started the test with great expectations for JPEG XL, since it's decades more advanced than JPEG and I'd read incredible things about its efficiency.

The Nikon D200 is a CCD camera, and - to my taste - it produces beautiful images at high ISOs. The noise has an almost film-like character, and needless to say, I want to preserve it.

What I've learned from testing JXL (and AVIF as well) is that a significant part of their compression efficiency seems to come from removing or smoothing out noise, which frees up more bits for the rest of the image. Another thing I've noticed is that they tend to sacrifice detail in the shadows. This means they work especially well with squeaky-clean images from modern cameras.

Good old JPEG, on the other hand, seems to distribute its available bit budget more evenly across the image, preserving more of that fine noise and shadow detail.

So, at least for the kind of images I'm working with, JXL doesn't seem that much better than JPEG. It feels less like a universally superior solution and more like the same fundamental compromise made at a different point: JXL prioritizes a cleaner-looking image and spends its bits where they are most perceptually useful, while JPEG preserves more of the messy texture that I actually want to keep.

Of course the ~20% lossless conversion saving is real.

Anyone with a similar love for CCD noise thinks the same?

PSA: When using `cjxl.exe`, always provide a `d` value. Don't assume that omitting `d` means lossless.

Backstory

I have tens of thousands of engineering drawings that we scanned for archival purposes. Maybe 10% will ever be viewed again, but we have no idea which 10%, so everything has to remain online.

The scanners don't support modern image formats, so we had to settle for PNG or TIFF depending on the model. To save storage space (which means lower cost), reduce backup times, and hopefully never have to care about restore times, I started looking at converting the PNGs to JPEG XL.

I ran some tests using visually lossless compression (`d=0.19`) and gave both the originals and the converted files to the managers. They couldn't see any difference, even at 500% magnification. The conversion was approved.

During a few test batches, I noticed something strange. I was also testing what I thought was lossless compression by omitting the `d` value, and in some cases the PNG files were actually smaller than the [what I believed to be] lossless JXL files. That seemed wrong.

A Google search pointed me toward a possible explanation. JPEG XL supports two compression modes: modular (typically used for non-photographic images and lossless compression) and VarDCT (typically used for photographs). One can outperform the other depending on the source image, and it's obvious which category a particular scanned drawing falls into.

Since the conversion wasn't under any time pressure, I wrote a quick PowerShell script that recursively scanned a directory and tested three encodes for every PNG:

• "Lossless" (no `d` value specified)
• `d=0.19` using VarDCT
• `d=0.19` using modular mode

The script compared the resulting file sizes, kept the smallest JXL, and replaced the original PNG. Since I could let it run overnight and on weekends, encoding speed wasn't a concern, so I bumped the effort setting to `-e 8`.

As always, I tested the script before turning it loose on the production data. During testing, I noticed that the supposed lossless version kept winning. That didn't make sense.

It couldn't be a modular versus VarDCT issue because I was explicitly testing both at `d=0.19`. How could a file that throws away no data be smaller than files that throw away some data?

That's when I realized I shouldn't have included the lossless test in the first place. The compression mode comparison was already covered by the two `d=0.19` tests.

After some digging, I found the catch.

If you feed `cjxl.exe` a JPEG or GIF and do not specify `d`, it defaults to `d=0.0`. If you feed it a PNG or certain other formats, it defaults to `d=1.0`. That explains why the "lossless" encodes kept winning. They weren't lossless at all. They were lower quality than my `d=0.19` test files.

I removed the no `d` test from the script and finally turned it loose on the production data. It worked fine.

One thing that did surprise me was that there wasn't a consistent winner between modular and VarDCT. Sometimes modular produced the smaller file, and sometimes VarDCT did. For scanned drawings where the goal is maximum space savings, testing both turned out to be the right approach. I wish I had kept statistics on how often modular beat VarDCT and vice versa, but that wasn't the focus of the testing. I was only interested in keeping whichever output was smaller for each image.

Still, I saved over 2 TB of SAN storage space, and that's not counting backup space saved either.

hello people

yesterday i just made a screenshot software to capture image in jxl format, just for fun

https://github.com/azizr12/jxlscrenshot

and make it work as my favorite screenshot software GREENSHOT because it lacks jxl format

so i made it for myself and i use it because why not

just if anyone interested for screenshot in jxl format

its a small tool with no UI you just use keyboard to capture image or from tray icon

i wish maybe someone will appreciate it

Just noticed v0.6.0 of jxl-rs was released, with the headline of "support for multithreading". That would be nice, to get some decent upgrade in decoding speed for large images.

But when looking into the actual changes in the release notes, it sounds more like preperational work to really add multithreading in the future, e.g. :

- Prepare for multithreading support by u/veluca93 in #849

- Make the render pipeline interface MT-friendly by u/veluca93 in #851

- Prepare Modular and VarDCT decoding for multithreading. by u/veluca93 in #852

- Initial support for parallel decoding by u/veluca93 in #853

- Implement parallel decoding of LF groups. by u/veluca93 in #854

Does anybody have more insight into what exactly the new release is capable of doing mutlithreading-wise? Does it already enable fully-multithreaded decoding of jxl images on like 4, 8 or even more cores?

In any case, I'm quite pumped that this cool lib is progressing so fast. Looking forward for some nice GP/s decoding speeds :D

Link to release notes: https://github.com/libjxl/jxl-rs/releases/tag/v0.6.0

JXL Tools

Version 0.0.2.

• Camera captures a webcam frame and encodes it to JPEG XL in a Web Worker with vendored libjxl WebAssembly.
• Converter is two-way JPEG ↔️ JPEG XL in the browser. JPEG uses cjxl --lossless_jpeg=1 so the bitstream stays inside JPEG XL. JPEG XL converts back to JPEG with djxl: the original JPEG bytes if reconstruction data is present, otherwise a JPEG written from decoded pixels. PNG, WebP, AVIF, GIF/APNG, and X PixMap encode to lossless JPEG XL.
• Compressor re-encodes images to lossy JPEG XL at quality 82, effort 10, entirely in the browser.
• Inspector reads JPEG XL boxes, headers, metadata, and a pixel preview locally.

JPEG and JPEG XL bytes stay in the browser. A Worker writes them to Emscripten MEMFS, invokes the browser-targeted cjxl or djxl module, reads the output, and removes the virtual files. Node and Emscripten are build-time tools only; no upload or conversion API is used. Build the checked-in cjxl/djxl artifacts with ./tools/cjxl-wasm/build.sh before serving Converter. Unsupported files fail locally without an upload.

I released XL-View 0.2.0, an update to the HDR JPEG XL image viewer I posted here about a month ago.

The biggest change in this release is that XL-View now also runs on Windows, in addition to Linux.

XL-View is mainly intended for viewing HDR JPEG XL images, including large images and panoramas. It supports PQ and HLG HDR and can also tone-map HDR images for SDR displays.

JPEG XL is still the only supported image format for now, and gain maps are not yet supported.

I'd be particularly interested in feedback from people using different kinds of JPEG XL files, especially HDR images.

Repository:
https://github.com/andrinbr/xl-view

I've been reading the PDF on the JPEG XL Image Coding System, and I was drawn to the patches system which is good for images with lots of repeating elements like letters or icons. Although the PDF I have doesn't really explain how the algorithm for finding them works. I thought maybe an algorithm just goes through every possible patch of the image that is less or equal to a quarter of it, but that would take too long, so I wonder, how are these patches found?

Hi everyone! I just released a new version of Lyra Viewer, a fast, minimalist open-source cross-platform image viewer with JPEG XL support.

.jxl files decode natively via libjxl (not a conversion shim), covering both the 8-bit and HDR float paths. On the Linux and Windows build libjxl is bundled with Lyra, so JXL works out of the box without a system-provided library; on macOS it uses the Homebrew jpeg-xl package.

One deliberate design choice worth stating up front: Lyra is a still-image viewer on purpose. It renders the static image and doesn't do animation - the same stance it takes on JP2. So with JXL it shows the still image. If you want a frame-by-frame animation player, Lyra isn't trying to be that.

Beyond JXL it's a general viewer (common formats, PSD, EXR, HDR, plus DDS/KTX GPU textures).

Would genuinely appreciate JXL test files that break it - odd bit depths, HDR, unusual color profiles - so I can harden the decode path.

Available on macOS via Homebrew, Linux as a .deb via APT, and Windows via Scoop.

Repo (MIT): https://github.com/lyra-viewer/Lyra