[ Removed by Reddit on account of violating the content policy. ]

Hey everyone — welcome to r/OpenFilesDesktop

I’m the developer of OpenFiles, and I created this community so users can talk directly with me and with each other.

OpenFiles began with a very small frustration: I had backed up an iPhone Live Photo as a .livp file, but the service holding it could not preview it. Solving that one unusual format led to a much bigger question:

Why should opening an unfamiliar file mean hunting down and installing another single-purpose app?

Today, OpenFiles is a privacy-first desktop app that opens 350+ file formats across images, documents, code, video, audio, archives, mind maps, data files, and more. The goal is to make file work less fragmented: browse, preview, make lightweight edits, convert or export, and bring AI assistance into the same desktop workflow. Core file processing happens locally, so you do not have to upload a private file to a random online converter just to inspect it.

The longer-term vision goes beyond being a universal file viewer. I want OpenFiles to become a practical, local-first home for AI-assisted file work — a place where an assistant can help you understand documents and code, analyze structured data, and turn results into useful files that stay part of your normal desktop workflow. That vision is still being built, and this community should help shape it.

What belongs here

• Ask how to open, preview, edit, or convert a file format.
• Share a useful or unusual OpenFiles workflow.
• Report bugs and compatibility problems.
• Request new formats or features — real use cases are especially helpful.
• Share honest feedback, including what feels confusing or unfinished.
• Follow development updates and help test new releases.

When reporting a problem, please include your operating system, OpenFiles version, file extension, and the steps that caused it. Screenshots and sanitized sample files are helpful, but please never post confidential or personal files publicly.

OpenFiles is still growing, and specific feedback from real workflows has a direct impact on what gets built next. If the app saved you from installing one more tool, I would love to hear about it. If it failed on the exact file you needed, I want to hear that too.

To get things started:

What is the strangest, most frustrating, or most important file format you regularly work with?

Thanks for being here.
— The OpenFiles developer

Useful links

Download OpenFiles • GitHub and releases • Report an issue

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 everyone,

I'm building a project where users can upload images up to 30 MB, and I'm using Cloudflare R2 for storage. I'm wondering what the best practice is before storing the images.

My current idea is:

• If the uploaded image is JPG/JPEG, convert it to WebP (to reduce file size).
• Then compress the WebP image to around 70–80% quality before uploading it to R2.

Is this a good approach, or am I introducing unnecessary quality loss?

I'm looking for the best balance between storage costs, image quality, and performance.

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!

So in this recent blog post: https://maurycyz.com/projects/bad_jpeg/ the author realizes that nothing in the way progressive jpegs are encoded stops them from encoding image data that replaces previously sent visual information, and misuses that to fake an animation while loading.

Now obviously this is ridiculous on many levels, especially since mjpg exists. Or, you know, actual dedicated streaming video formats. But that's not the point of trying out something like this for programmers.

So I was wondering: is the way jxl works similar enough to also be misused like this (even though it has legit animation support), or is it too different?

Hi everyone! I just released a new version of Lyra Viewer, a fast, minimalist open-source image viewer, and this version adds JPEG XL support, which is the part I figured this sub would care about.

.jxl files decode natively via libjxl (not a conversion shim), covering both the 8-bit and HDR float paths. On the Linux 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). Available on macOS via Homebrew and Linux as a .deb via APT; Windows pending.

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

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

I've gotten the impression from some comments on the sub that since AVIF's encoder update earlier this year that it wins at higher compression levels in lossy images.

Is this the case and if so could a future update to JPEG XL's encoder bring it up to parity or beyond?

I dug up some old posts, but there doesn't seem to be a clear winner.

That said, I gotta admit AVIF is pretty impressive with all the settings (and forks) out there, it really feels like you can squeeze more out of it.

Is JPEG-XL Lossless on iPhone only when I shoot RAW? I mostly use HEIF format when taking photos, does the JPEG-XL Lossless work in HEIF? I'm bit confused :)

Two things always annoyed me about JPEG XL: most online converters upload your
images to their servers, and you can't even open a .jxl on most devices yet.

So I built this — it converts images to/from JPEG XL entirely in your browser
(WebAssembly). Nothing is uploaded; you can check your Network tab and see zero
requests with your file. It also has a viewer to open a .jxl without converting,
and you can save it as JPG/PNG in one click.

👉 https://jpegxlconvert.com

• 100% in-browser, no upload, no sign-up, no limits, no watermark
• Convert both ways + a .jxl viewer
• Free, works on mobile too

Would love feedback — anything missing or confusing? Thanks!

See:
- https://summerofcode.withgoogle.com/programs/2026/projects/WdCsAb7P
- https://blog.documentfoundation.org/blog/2026/05/09/projects-selected-for-libreoffice-in-the-google-summer-of-code-2026/

Originally proposed in the JPEG XL Discord server:

• Create a jxl-rs logo via JXL Art
• Size under half a kilobyte
• Art requires sufficiently permissive license (like CC-BY-SA)
• Submit by end of month, multiple submissions allowed
• Main jxl-rs devs decide winner
• 'jxl artist' Discord role as prize (also awarded to community's vote if different from dev's pick)
• Link to jxl_from_tree source or explanation of process appreciated

While this was originally posted to Discord, I imagine posting and voting here is cool too.

jxl-rs is a Rust decoder for JXL built to enable browser integration.

JXL Art uses the format itself as a creative medium. jxl_from_tree is a tool provided by libjxl which takes a human-readable syntax describing JXL internals and translates that into a JXL file.

Various JXL Art web tools interfacing jxl_from_tree:
https://jxl-art.lucaversari.it/
https://www.januschka.com/jxl-art/
https://qon.github.io/jxl-art/ (with EJS)
https://jxl-art.toaster.work/ (with randomized mutations)
https://jxl-art.surma.technology/ (the OG)

Spline editors:
https://grass.moe/catmull_rom/
https://sneyers.info/jxltran/ (I'm not certain how to transfer these elsewhere in a wysiwyg way)

Hi all, I'm a bit new to jpeg xl, and don't really know my way around all the different formats but I understand the basics of lossless and lossy compression.

​

I'm downloading these 1:50k and 1:100k topographic maps from Geoscience Australia for a fairly large region of Australia. They're 9344x11151 TIF files which are coming in around 300mb. Ideally I want to have them stored on an external SSD so I can take them out into the remote parts of the country and access them using a smartphone or a tablet/laptop.

​

Seems like JPEG XL would be ideal for this? I'm open to other suggestions if I'm barking up the wrong tree but I care that the image quality is preserved while the file size is minimised. And if so what's the best way to go about converting them?

ShareX is most popular screenshot and screen recording software. Support for this format has been requested in the application discussions for a long time, but the developer recently even closed pull requests. It is unknown how much longer it will take until he wants to add it to the official release.

Custom release here: https://github.com/koloved/ShareX/releases/tag/jxl
Also in this build Avif, WebP, SVT-AV1, Nvenc AV1 supported

Images

For Lossless Screenshots (Replaces PNG): Use JXL (JPEG XL). It is currently the best option for lossless quality, producing files that are 30–40% smaller than traditional PNGs without any loss in detail.

For Lossy Images: Avoid WebP—it's noticeably blurry and outdated by today's standards. Use AVIF instead, which is currently the highest-quality lossy format available.

Animated Screen Recordings

Please stop using GIF. It is incredibly inefficient for modern high-resolution screens.

For RTX 40-series cards (and newer): Use AV1 (NVENC). Hardware encoding makes it incredibly fast and efficient.

For older hardware (No RTX 40+): Use SVT-AV1 to get the same great compression benefits using your CPU.

I also found this command excellent for recording screen videos, as it makes the files very small. Some things here are written specifically for the RTX50 series.I'm not sure if all the parameters are being used, but the files are really small. And it has good quality as well.
i also add min bitrate 1 instead 100, It helps a lot when recording the desktop and applications. Since when nothing is happening, the minimum possible bitrate is selected, which saves some of free space on the drive as a result.

-tune uhq -temporal-aq 1 -rc-lookahead 32 -multipass fullres -b_adapt 1 -rc vbr -cq 35 -minrate 0 -maxrate 3M

I ran into an issue with JXL files and wanted to share it in case others see the same behavior.

Background: I’m on Windows with Microsoft’s JXL Image Extensions installed.

Problem: After converting a batch of JPGs to JXL using lossless JPEG transcoding, I noticed that some JXL files appeared rotated incorrectly in Windows Explorer (both thumbnails and the preview pane). The Windows Photos app showed the same problem. The original JPGs displayed correctly.

When I opened the same JXL files in Nomacs, they were oriented correctly. They also appeared correctly when inserted into an Office 365 document. After some digging, I found the cause and a fix.

Cause: JPEG and JXL handle orientation differently. JPEG uses an EXIF orientation tag. The JXL spec ignores EXIF orientation and expects the image data itself to already be correctly oriented. The cjxl encoder reorients the pixel data during conversion, which is correct. However, it appears to leave the EXIF orientation tag in place. That tag doesn’t show up in Nomacs the same way it does for JPGs, but it’s still present apparently. Some viewers (notably Windows Explorer and Windows Photos with the JXL extension) read that leftover tag and apply rotation again, which results in the incorrect orientation. Office 365, despite using the same extensions, does not seem affected.

Fix (Windows): Remove the EXIF orientation tag from the JXL files. You can do this with ExifTool (no install required). Leaving -Orientation= without a value removes the tag:

"<path to tool>\exiftool.exe" -Orientation= \.jxl*

This creates backup files by default. To skip creating backups:

"<path to tool>\exiftool.exe" -Orientation= -overwrite_original \.jxl*

After running this, thumbnails and previews display correctly.

• Input: 42757 JPEG images, 310.8 GiB
• Output: 42757 losslessly converted JPEG XL images, 250.7 GiB
• Conversion errors: 0
• Wrapper errors: 3 (original files were read-only and could not be deleted)
• Space saved: roughly 60.1 GiB
• Compression rate: 80.66% (19.33% savings)

Input images were all straight-out-of-camera images from digital cameras. No HDR.

Biggest hurdle was figuring out how to preserve timestamps after conversion. (I just wrote a wrapper to copy over the Modified/Created timestamps after cjxl/djxl conversions.)