JPEG XL Support

[j7n]

I had an opportunity to boot into NT6 and experiment with the plugin. Lossless compression is strong. At the default complexity level 7 I can go and make coffee while it works. At complexity level 3 both encoding and decoding speed become faster and acceptable, and the ratio is still better than PNG on photographic data, and on par with JPEG-LS. It does handle screenshots well, but requires at least level 4. Lossless mode makes use of correlation between channels, and also recognizes low bit depth, such as 15-bit.

What is "modular" encoding? I notice that it increases the file size for the same quality factor, and has no effect in lossless. What additional parameters are there to tune for lossless compression?

The GUI should have a checkbox for lossless mode because the slider at 98 and 100 looks too similar.

The 64-bit version is much faster than 32-bit at high quality settings. Compression uses a fair bit of memory, but I didn't see it going past 1.7 GB.

A relative comparison of encoding and decoding times.

Enc JPEG-LS ... <1s
Enc PNG lv 8 .. ~1.5s
Enc q.98 64-bit ~3s
Enc q100 64-bit ~18s
Enc q.98 32-bit ~4s
Enc q100 32-bit ~1s .. cmpl 3
Enc q100 32-bit ~16s .. cmpl 4
Enc q100 32-bit ~26s

Dec q100 64-bit 702 ms
Dec q100 64-bit 452 ms .. cmpl 3
Dec q.98 64-bit 234 ms
Dec q100 32-bit 1466 ms
Dec q100 32-bit 1123 ms .. cmpl 3
Dec q.98 32-bit 265 ms
Dec JPEG-LS ... 296 ms
Dec PNG ....... 94 ms
Dec JPEG q98 .. 78 ms

[JendaLinda]

JPEG XL uses two compression methods: VarDCT and Modular. VarDCT is used only for lossy compression. Modular can be either lossy or lossless. VarDCT is optimized for photographs, while Modular is better for computer generated pictures. The quality setting 100 means lossless compression, so the modular mode is always used.

The command line tool cjxl has so many options, I don't even know what most of them do. I was unable to find more detailed description of the parameters. I found one particular picture, where lossless JPEG XL produced a bigger file than other lossless image formats. I tried some parameters suggested by people on Github and those improved the compression of that one picture significantly.

[j7n]

Can you show the example of such a picture? So far, all images I've tried were a little or significantly smaller at complexity 7.

[JendaLinda]

It's huge pixel art picture (10000x10000 pixels). Not very suitable for testing.

More information about the issue with examples is here:

https://github.com/libjxl/libjxl/issues/727

[Usher]

WinXP is too old, it fell into the vintage Windows family like Win9x. You shouldn't use such old versions of Windows as a main operating system anyway, you can't even get up to date web browsers for them.

Just don't tell marketing tales, please.
1. Unlike Win9x, Windows XP is NT family (like Windows Vista, 7, 8, 8.1, 10, 11).
2. Users won't switch any time to newer system when they HAVE TO work with Windows XP.
3. Basilisk 52 (Firefox/Serpent fork) is good enough as a web browser on Windows XP. However, some XP systems work disconnected from the Internet and they aren't counted in well known statistics.
4. Other 32-bit IV plugins work in Windows XP, so it's more like a matter of a developer care and compiler settings.

[JendaLinda]

Just don't tell marketing tales, please.

1. Of course, Windows XP is NT based. Windows NT 4.0 is NT based as well and it's not supported by IrfanView.
2. You can use Windows XP if you need to, you just won't get new features. Don't tell me the WinXP system is your only computer.
3. Yes, WinXP is running on many CNC machines and other industrial equipment. You don't want to have these machines connected to the internet anyway.
4. JXL plugin is based on libjxl library. Developers of the library have no interest in supporting WinXP, so WinXP will not be supported.

[j7n]

A user of the MSFN forum has compiled the JPEG-XL library such that it runs under WinXP, but he can't add the functions that expose it to IrfanView without cooperation from the author. His version is even bigger, and includes, among other things, Brotli text compression. Having such dependencies makes porting to older systems more difficult. Unfortunately XL is more slow, and requires more memory than was claimed. Wikipedia includes a statement that the speed is comparable to conventional JPEG, which is clearly not the case at practical complexity values.

Ad-block users are also not counted by parasite sites that don't provide useful content. Browser statistics from Wikipedia could probably be trusted if they still provide them. New Moon & Serpent are decent browsers. I do mostly use Windows 2003 because I've learned to deal with it efficiently over many years.

[JendaLinda]

libjxl is still in development, there is room for performance improvements. I was very positively surprised that IrfanView has added JPEG-XL / JXL support so early. In web browsers, JXL support is hidden behind flags.

Supporting ancient operating systems doesn't make much sense. Just a few people would benefit from that. Is it really worth the extra work and hassle?

JXL is often compared with AVIF. JXL seems to be more complete and robust than AVIF. All JXL viewers are expected to be able to correctly decode any JXL image. In the case of AVIF, there are already some problems with compatibility. At the moment, IrfanView is using very limited and buggy Microsoft's AVIF implementation. As far as I know it works only in Windows 10 and later. I'm not sure how adding full AVIF support in IrfanView would work out. The AVIF encoder/decoder binaries are about 15MB each.

[Winnie2]

Any plans to update JPEG XL support in Irfanview to the most recent version, because it features quality improments and bug fixes?

[JendaLinda]

Supposedly IrfanView will be updated to the current version of libjxl in the upcoming version of IrfanView. It was updated to libjxl 0.7 in the last version.

[MikeFletcher]

Thanks for sharing your experience with JPEG XL! It sounds like you've really delved into its capabilities. Lossless compression indeed seems to be a standout feature, especially with its strong performance even at lower complexity levels. And the fact that it handles various types of data, from photographs to screenshots, is impressive.
Your suggestion about adding a checkbox for lossless mode in the GUI is spot on! It could definitely help avoid confusion, especially with similar-looking sliders. Providing clear options like that can make the whole compress image process much smoother for users.?