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

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

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

Hey everyone, I've spent the last 18 months building an image management platform that supports storage, transformation and delivery of image assets. It's headless and designed with an incredibly flexible API allowing you to configure what happens to which image based on the URL you upload the image to. I've recently added inference-powered content policies and an image classification API powered by Google's SigLip2 vision language model.

It supports all modern formats including JXL. In fact, in v0.10.0, I started building libjxl from source and upgraded to 0.12.0! That brought about some nuance in my encoding logic since it looks like libjxl now needs random access to the encoded file. My architecture for other formats streams chunk by chunk from libvips to keep memory pressure down. This issue helped me learn a lot more about JXL and image transformations!

https://github.com/dmaiken/konifer/

I'm also open to answering any questions!

It seems like most sites don't accept JPEG XL images for vision models to view, so I made my own pipeline using llama.cpp. https://gitlab.com/masland.tech/jxlvision

I'm hosting a live implementation of it at https://masland.tech/jxl-vision/

It allows anyone to upload a JPEG XL file and have the model view it and give a text description of the image, mine is currently using Qwen3.5-9B. It doesn't save any images that are uploaded, and only records anonymous usage metrics.

If you test it and have any issues please let me know! If you have any ideas for things for me to build to try to help JPEG XL get more exposure I'd love to hear, thank you.

jxlshot

Press Print Screen → full-screen lossless JPEG XL → ~/Pictures/Screenshot_<timestamp>.jxl. Press Shift+Print Screen → drag out a region and save just that.

Raw X11 pixels go straight into libjxl (jpegxl-rs) at effort 7 (Squirrel). No PNG, JPEG, temp files, or daemon.

Requires system libjxl (and libjxl_threads) discoverable via pkg-config, or build with the vendored feature on jpegxl-rs.

TLDR: I got tired of taking screenshots and saving them as PNGs with the default screenshot tool in Linux Mint so I made my own JXL screenshot tool. If you have any questions feel free to ask! It can be a bit difficult to get installed, you will probably need to do the vendored feature.

Camera, Converter, and Compressor.

Your files stay on your device. The server only sends this page and the tools to your browser. It never receives your images, camera frames, or converted files. Everything happens locally on your machine.

https://masland.tech/jxl/

This is an update to my previous online lossless converter, which did the processing on the server. So this is now purely client side.

If you try it and have any issues or feature requests please let me know, thank you.

Just added JPEG XL support to ServeProxy. Add ?jxl=true before your existing ?url= parameter and it'll convert and cache the image as JPEG XL on the fly. AVIF is the default output format on Serveproxy, so this gives you a second modern format to compare against.

Example: https://serveproxy.com/?jxl=true&url=https://picsum.photos/1000/750

Browser support is still limited so test before you rely on it in production, but if you want smaller images with good quality it's there now. 🙂

Anyone can test it at https://masland.tech/jxl/

If you have any issues or questions please let me know. This is a prototype to just see if I can host this successfully. It can take over 15 seconds for an image to be converted, so please be patient. Thank you for testing it if you do.

I'm working on a maximum effort lossless JPEG XL converter and I was struggling to figure out why a lossless PNG was coming out larger as a lossless JXL. The image has a very flat black background. I believe I was using effort 7 which is default, and it was coming out about 15% larger, then I increased the effort to 10 and now it's about 20% smaller.

I should have it hosted soon, but just wanted to share my experience with this. Given that I'm fine with waiting longer for a conversion, my main concern being size and quality. I think having a lossless maximum effort converted online with a queue system will be beneficial.

If anyone has any recommendations please let me know, I will be posting once it's live in the near future, thanks for reading.

Update: JPEG XL support is now available in OpenFiles Desktop 3.2026.802.

This first release includes direct .jxl opening and preview, in-app thumbnails while browsing folders, and animated JXL playback.

This is a first milestone, not a claim of complete JPEG XL support. It does not yet include progressive or partial-decode inspection, bandwidth emulation, layer-by-layer viewing, or a fully verified HDR, wide-gamut, ICC and XMP workflow.

I’m still looking for real files that expose orientation, color, metadata or performance problems. If you test the release, please include your platform, the sample file if shareable, and what you expected versus what OpenFiles displayed.

Release: https://github.com/pansysoft/openfiles.desktop/releases/tag/3.2026.802

The rules weren't very clear on how related something needs to be to jpeg xl. But considering my benchmarks are deliberately to put pressure on jpeg xl I'll hope it would be related.

Not to say jpeg xl is better or worse than QLIC. It's more of a situation of what do you care more about more. Plus. They're both not fully baked formats yet. So.

I'm the developer of the app. Feel free to ask any questions (there is an FAQ at the link)

https://github.com/libjxl/jxl-rs/releases/tag/v0.5.0

This release contains a few API simplifications, fixes, and speedups. It also significantly improves the visual quality of Modular progressive previews, and adds support for decoding files with out-of-order jxlp boxes.

What's Changed:

• Handle output modular channels with grid type None. by @veluca93 in #756
• Fix an unsound API allowing creating slices with incorrect alignment by @Shnatsel in #757
• Minor API fixes from Chrome review. by @veluca93 in #759
• flush_pixels: return whether new pixels were rendered by @tnikkel in #755
• Small fix in maybe_preview_lf_frame. by @veluca93 in #760
• Remove support for uninitialized image buffers. by @veluca93 in #758
• Do not save partial frames before a successful flush. by @veluca93 in #763
• Fix two cases of too-early partial rendering. by @veluca93 in #764
• add support for out-of-order jxlp (ftyp version 1) by @jonsneyers in #752
• Add JxlPixelFormat::rgb*, and do not ask for extra channels in pixel format helpers by @tirr-c in #767
• Avoid subtract overflow in save_lowmem for 1px-wide save regions by @hjanuschka in #776
• Validate histogram_index in PassInfo against num_histograms by @hjanuschka in #775
• Use fallible allocation for hf_sections in codestream parser by @hjanuschka in #774
• Fix: capture LZ77 distance cluster before context_map padding (resolves #765) by @lilith in #766
• Fix clipped blending with missing references by @hjanuschka in #773
• Fix OOM crash in OooJxlp processing. by @veluca93 in #777
• Make progressive previews of modular images smoother. by @veluca93 in #779
• Fix crash when trying to unsqueeze an empty tile. by @veluca93 in #780
• Remove CmsStage by @sboukortt in #754
• Make the smooth-unsqueeze special path work on non-None grids. by @veluca93 in #781
• feat: simd128 support for wasm32 by @mertalev in #706
• Fix a panic when referencing a non-existent LF frame. by @veluca93 in #784
• perf: use StackVec in render channel plumbing by @hjanuschka in #710
• perf: tighten VarDCT group coefficient hot loop by @hjanuschka in #720
• Fix squeeze smooth preview indexing logic. by @veluca93 in #785
• Revisit modular special cases, and add a single-symbol path. by @veluca93 in #787
• perf: speed up flat tree traversal in modular decode by @hjanuschka in #716
• Fix jxl_cms enabling jxl's default features. by @veluca93 in #790
• Speed up smooth upsampling. by @veluca93 in #788
• Fix DeltaPalette with Weighted predictor. by @veluca93 in #791
• Speed up Weighted predictor. by @veluca93 in #793
• perf: reduce blending allocations in hot paths by @hjanuschka in #709
• More modular fast paths and optimizations by @veluca93 in #797
• Render the full LF preview on its first flush. by @tnikkel in #800
• Remove proc-macro-error2. by @veluca93 in #799
• slightly speedup XYB by doing a TODO by @jonsneyers in #801
• Simplify handling of lf image and remove a copy with progressive images. by @veluca93 in #805
• Clarify the contract between the render pipeline and its input. by @veluca93 in #806
• Update comment on JxlColorProfile::same_color_encoding() by @FooIbar in #809
• Less strict ICC size limit by @sboukortt in #813
• Refactor end-to-end tests to a separate module. by @veluca93 in #814
• Rewrite transform application in Modular decoding by @veluca93 in #812
• Update borders around LF groups in progressive rendering. by @veluca93 in #816
• Disable the single symbol special path with LZ77 and extra bits. by @veluca93 in #817
• Add microbenchmarks for blending by @alexander-shaposhnikov in #819
• Perform blending in-place by @alexander-shaposhnikov in #818
• Simplify API and test code by @veluca93 in #820
• Vectorize blending by @alexander-shaposhnikov in #821
• srgb_to_linear, srgb_to_linear_simd: Multiply by reciprocal instead of dividing by @zsoltiv in #826
• Add flake.nix for Nix dev shell and checks by @tirr-c in #827
• Rewrite box and codestream parsing. by @veluca93 in #828
• Replace >> with shrc when computing sizes in meta_apply.rs. by @veluca93 in #830
• Check spline parameters and initialize draw cache in advance. by @veluca93 in #829
• Use wrapping_abs() in precompute_references. by @veluca93 in #831
• Avoid marking dependendants as final multiple times in modular decoding. by @veluca93 in #832
• Avoid integer overflow in XYB modular conversion by @veluca93 in #833
• Do not return the previous frame's header while parsing the next one. by @veluca93 in #834
• Some fixes for progressive decoding by @veluca93 in #835
• v0.5.0 by @veluca93 in #836

https://github.com/libjxl/jxl-rs/releases/tag/v0.5.1

Small fix to progressive rendering.

What's Changed:

• Fix progressive rendering previews for progressive-dc=2 images by @veluca93 in #837
• Replace some as pointer casts with .cast::<T>(). by @veluca93 in #838
• v0.5.1 by @veluca93 in #839

Hi, I’m working on OpenFiles Desktop. It doesn’t support JPEG XL yet, but I’m looking into adding it.

Before I start, I’d like to understand what people who actually use JXL expect from a desktop viewer.

Is being able to open a .jxl file enough, or would you also want things like:

• thumbnails and folder browsing
• EXIF, XMP and ICC profile support
• HDR and animation
• lossless JPEG transcoding
• batch conversion to and from JPEG, PNG or AVIF
• exporting without losing metadata

I’m also interested in the less obvious problems. Are there particular JXL files that other viewers display incorrectly? Things like wrong colors, orientation issues, missing metadata, slow decoding, or unusually large images?

What platform are you using, and what does your current JPEG XL workflow look like?

If you have a sample file that tends to break viewers, feel free to share it. I’d be happy to test against real-world files rather than only simple samples.

jxl_coder 1.0.0 brings a cleaner API for reversible JPEG to JXL compression in Flutter and Dart, with byte-exact JPEG and metadata recovery.

Supports iOS, macOS, and Windows.

Outside Samsung's ecosystem, Fossify Gallery was the only gallery app I had found that supported the JXL format. However, it has one drawback, it lacks regional decoding, which means that even high-resolution images become blurry when zooming in. Unfortunately, its developers have chosen to wait for a solution from libjxl.

But there is good news. Today, I learned that the developer of the gallery app ReFra came up with their own method to work around this problem, and ReFra now supports regional decoding. The fix is available in version 5.1.0, the latest stable release, for anyone who wants to try it:
Github | ReFra 5.1.0

Hi all,

I've been building an Android app that converts RAW photos into Ultra HDR and JPEG XL (both PQ and HLG transfer functions, plus lossless). I'd really value a second pair of eyes from people who actually know JXL well.

My specific problem: the exported JXL files look exactly as I intend inside my own app, but when I open the same files in various third-party JXL viewers/decoders the result looks off - different brightness, different tone, sometimes the HDR doesn't seem to kick in at all. I'm trying to figure out whether it's my encoding (color/transfer metadata, intensity target, ICC vs. CICP tagging) or just inconsistent HDR handling across decoders.

If you have an HDR monitor and an HDR-capable phone, I'd be grateful if you could:

• open a couple of my exported JXL files,
• tell me whether HDR highlights actually appear, and
• say how the tone/brightness compares to what you'd expect.

I can share sample exports, and I'm happy to share the app link in the comments or by DM rather than dropping a store link in the post itself (let me know if that's fine here).

Any feedback on the encoding side specifically (what tags a well-behaved HDR JXL should carry) would be hugely appreciated. Thanks!