JPEG XL support

JPEG XL is a royalty-free image codec. While being smaller than JPEGs when used as the primary format, it can also losslessly compress existing JPEGs which is great for space savings, as well as supporting features like progressive decoding that are missing from the video codec still formats like WebP/AVIF (which helps on slow connections or low-spec hardware). The codec is widely adopted by graphics applications like proprietary ones from Adobe & Apple but the open source ones like GIMP & Krita to name a few. One of the ‘interesting’ missing spots for support is the Google Chrome browser & Android–which offers an opportunity to distinguish the platform from Android to which a lot of folks would love to see & would make a headline in the geek world.

At present, *.jxl files do not render in the gallery / file viewer (tho the mime type is recognized) & image.jxl.enabled = true in the browser (no surprise since Mozilla locked it behind Nightly but some browsers like LibreWolf patched out that restriction so users can choose to enable it regardless). What I would like to see is minimally support of JPEG XL in the OS for viewing along with removing that Nightly browser restriction. If it is popular & leads to speed ups / space savings it would be great if the browser enabled it by default & apps like the camera use it by default or transparently compress its JPEG output for all users’ benefit.

The drawbacks are that historically image codecs tend to be a vector for exploitation, but this is still a present threat with the existing codecs as well.

4 Likes

I’m in principle for supporting all reasonable image formats; but the default camera format should remain JPEG - otherwise we are no better than fruitphone sending unusable heic files to everyone long before support is mature.

2 Likes

HEIC didn’t have the same adoption & was nonfree. Today on iOS you can set the format the JPEG XL in the camera application with Webkit supporting it on the web as well. There will always be this chicken-egg issue with formats, else we will be stuck with JPEG & PNGs for literally ever… which is going to be difficult with HDR usage on the rise.

From where i’m sitting they are just as exotic (still!); neither work fully on my desktop (Linux Mint, fully up to date). Seems Winderps can’t handle JPEG XL either.

By all means; introduce it where needed - but don’t swap out the defaults just yet.

3 Likes

That is reasonable, & I wasn’t suggesting a short-term default since nobody is yet. I would certainly like to see basic support since at present none of my images will preview or be able to be used as wallpapers while saving precious SSD space. Many Linux applications from feh to ImageMagick are already on board as well as a qt-jpegxl-image-plugin available on Microsoft GitHub.

2 Likes

I would expect that if you package and install either the plugin you linked or kimageplugins there should be support for JpegXL in gallery. Note that SailfishOS is stuck at Qt 5.6.

3 Likes

One other component that would need support is Tracker3.
It currently doesn’t even do webp afaik.

2 Likes

Hmm… on my work iphone (iOS 18.3) I don’t see an option to change photos taken to JPEG XL. Only options are:
“High efficiency” = HEIF/HEVC
or
“Most compatible” = JPEG.

I do wish the “High efficiency” option would be JPEG XL instead.
HEIF is garbage. It has royalties and it’s inferior to JPEG XL.

if you use 32bit sailfish-os (armv7) then you can have basic support (view jpegxl-images):
https://openrepos.net/tags/jpegxl

64bit (aarch64) users have to wait, sadly…

what would speed up things is having a gdk-pixbuf image-viewer like eog (eyeofgnome) on desktop…

2 Likes