Fast forward 10 months later, I just realized that ReShade already have HDR support and already incorporating HDR PNG as a screenshot format. This tickles my mind to continue experimenting with JPEG XL support again. Furthermore, I just found out that libjxl team also releasing simple-lossless-encoder demo that can fit on a single cc file, this is perfect as this can keep ReShade binary size low and shouldn't complicate the deps, plus I also focused on lossless side for a fast encode (effort 1).

After stealing adapting the demo code, adding few paths to allow few other color profiles (2020 PQ and linear sRGB) and float bitdepth, it finally lives! HDR screenshot with JPEG XL!

HDR Comparison​

For a proper HDR viewing, you should view these with HDR (and JXL) enabled browser and HDR monitor

And here's the PNG one for the comparison:

Not only that it's smaller than PNG, it also encodes much faster:

It seems like in HDR PNG they do some color conversion that contributes to that heavy processing, while in JXL I only did buffer conversion (R10G10B10A2 to R16G16B16) without scaling, preserving 10 bit values 0-1023.

SDR Comparison​

And here's the PNG one for the comparison:

They're pretty similar in speed!

As for the source code, it's still a draft with a bunch of debug prints enabled, but feel free to check here: https://github.com/kampidh/reshade/tree/jpegxl-simple

I also have prebuilt binaries in case of someone want to test it: self hosted link

PS: Do take a lot of precaution when downloading binaries please, as this is NOT an official build and might have bunch of nasty bugs. You also probably should only test it on a single-player game. Use at your own risk, thank you~

I remebered during my college days when I still have a side job to calibrate monitors (that was way back in 2012-ish, when Spyder 4 was released), most of my customers' screen only have around 70% sRGB coverage, I even found some that went as low as 60%! Ouch! Wide gamut, or even a full sRGB coverage monitors were pipedream to most of us, we can only see them in big studios and production houses.

Anyway, I digress with my personal story.

And thus, since the advent of wide gamut displays and HDR these days, color management in browsers became an important aspect. We are no longer bounded by sRGB profile, many new wide-gamut profiles are emerged that can accomodate this shiny new display (pun intended), such as DisplayP3 and Rec.2020 profiles. Therefore, now major browsers have a proper color management to properly view those images, also to pave the road for HDR viewing support.

Well, actually in photography section we already got used to work with wide-gamut profiles such as Adobe RGB and ProPhoto RGB for a pretty long time too.

An Unideal Scenario - Lossy Compression​

Now imagine this scenario, you're just a photographer working with these profiles (say for my example here, darktable's Linear ProPhoto RGB), and you just forget to convert the pictures into a web-friendly profile when deploying them. How well do these modern image codecs handle this? In my experience, wide-gamut linear profiles often hits hard for a lossy image compression... Let's investigate!

For the test image, I will be using this picture of color patches from an old XRite ColorChecker Passport. This was shot with Nikon D810 + 105mm f/2.8G VR Micro-Nikkor lens @ f/8.0 ISO 64 under Broncolor Siros lights.

Lossless 16bpc(48bpp) PNG with Linear ProPhoto RGB - 20.6 MiB

Conversion tools (all with metadata intact, minor impact though):

• JPEG XL: cjxl 0.10.3
• AVIF: avifenc 1.1.1
• WebP: Krita 5.2.3 WebP export

All encoding done with default parameters, only changing the quality parameter.

For the plotting tool I'll be using is my own Color Gamut Plotter written in Qt, however I'm not suggesting that you should try it since it's still buggy and unwieldy at best xD, but feel free to try it if you insist. I also have a showcase video on YouTube. Currently it has support to only read jpg, png, tiff, and jxl as an input. Originally Qt also have webp but I disabled it since I haven't been able to upgrade it to mitigate that one big CVE-2023-4863. Therefore you'll see why AVIF and WebP test files used for plotting is a decoded image (to 16bpc PNG). As for the colorspace display, I will be using peceptual space, Oklab. For JPEG XL, this tool decodes with libjxl 0.10.2 and pulling the pixel data as 32-bit float, therefore you might see the results below that it sometimes gives more total unique colors than the RAW PNG.

Not a perfect calibration, but some was close enough to the colorchecker targets, darktable reported at Max ~4.06dE and Avg ~1.92dE using their color calibration module. We can see how the colors are clumped pretty nicely on the distribution plot.

Comparison At ~1bpp​

Color Plot​

Other than WebP limitation (8bpc) that shows a severe quantization errors, the color plot looks pretty similar. I don't see a discernible shift in color for both JPEG XL and AVIF. However AVIF does seems to clump colors even more, seems like smoothing out the noises? Let's dig more...

Distribution Plot​

We can see how 8bpp (WebP) is barely even suitable for wide-gamut and HDR, only 46,214 colors remain... Other than that, JPEG XL seems to be doing quite well at preserving the color distribution, it has a total unique color count of 4,377,184. On the other hand, AVIF is showing a smudge in color distribution, a slight quantization errors around neutral colors, and having a much smaller unique color count (1,581,283), either due to lower precision (12bpc) or it's indeed softening the colors more.

Close Up Crops & Result Images​

A plot may look cool and such, but how will it differ visually? Here goes a crop to compare:

Here we can see AVIF got quite a lot of smoothing especially on dark areas, and WebP is starting to look like a blocky mess. While JPEG XL holds quite well maintaining color accuracy and textures.

And these are individual result images:

However, you may notice that these result images may look different than the crop image above that I've been converted into sRGB, since these result images are still in Linear ProPhoto RGB profile and may render differently depends on the browser. Ideally, these images should look all the same in a properly color managed browsers.

Comparison At ~0.6bpp​

Few benchmarks that I saw show that AVIF works quite well in low bpp settings. Let's see how it fares in this worse scenario.

Color Plot​

Lowering the quality further, both JPEG XL and AVIF shows that they narrowing the color spreads even more, indicating more noise smoothing I presume? While JPEG XL mostly have proportional reductions in this perceptual Oklab space, AVIF have some colors squished unproportionally, can be seen noticeably in that green and blue patches. I'm not sure how it implies to the overall color accuracy, but the median point of those color patches on both JPEG XL and AVIF didn't seem to change significantly. And let's ignore WebP result...

Distribution Plot​

JPEG XL still holds quite well at 0.6bpp, clocking in at 4,373,618 total unique colors, it didn't seem to differ much from 1bpp result. AVIF shows more prominent quantization errors compared to 1bpp result and seems to 'bleed' the colors even more now, clocking at 1,246,309 total unique colors, an apparent reduction from 1bpp result.

Bonus: JPEG ~0.6bpp​

Mmm, look at that beautiful-yet-nasty 8-bit quantization~ Even so, they still have much more color than WebP! (84,809)

Close Up Crops & Result Images​

In high contrast textures, all formats still performs well to retain the details. But on the low contrast and dark areas, only JPEG XL that can retain the details well. AVIF smooth out almost everything, and most of the color patches are now almost textureless blob of color. While WebP and JPEG is a whole blocky mess now.

And these are individual result images:

However, you may notice that these result images may look different than the crop image above that I've been converted into sRGB, since these result images are still in Linear ProPhoto RGB profile and may render differently depends on the browser. Ideally, these images should look all the same in a properly color managed browsers.

Conclusion​

Both JPEG XL and AVIF perform quite well on retaining color accuracy, but JPEG XL is absolutely have an edge for this scenario, barely losing any details even though it was given a wide-gamut, linear color profile. It's always a pleasure to see image codec / format with great color profile awareness!

Now, I might say that this is an 'unideal' scenario. But how long 8bpc sRGB will stand as an 'optimal' profile and bit depth? Yes, while linear TRC/gamma might not a good idea for web delivery, but as I said before that consumer HDR display is already here, with all confusing standards to choose from (PQ, HLG, etc.), it's beneficial to have an image format that can still compress wide-gamut spaces and/or various TRC/gamma efficiently. And in lossy JPEG XL case, it's even less likely to be bothered by input image's bit depth, since it already store the compressed pixel data in 32-bit float (XYB) internally.

Supposed to be a wingless dragon, but the mask made it more like a dragon-fox hybrid.

Parts Used​

Here's the main parts list:

• Body: Gerifalte Body
  • one of the few fully-armored T2 body 💗
• Arms: Krolik Arms/B
• Legs: N-Amuaira Legs V2
• Head: Moonlight Hair/D

Accessories:

• Head: Sylphos Mask, Rithia Hair Ornament, Cat Eye Contacts
• Others: MC96 Field Walker, Mechanical Fin/B, Dinorex Tail

Let's start the showcase then! :3

Alternate version with Theanaga Hair​

I love this looks too, but that long hair kinda hide the body's silhouette...

Alternate light armor version​

"Off-battle" without leg armor and arms part replaced with Moonlight Arms/2, highlighting the N-Amuaira Legs thigh-high wrinkles at its finest!

Winged version​

Item: Wing Blades Quatre. Don't really like the silhouette, but still looks pretty cool~ x3

Bonus: Absolute territory​

When cold-hard CAST body meets a soft fabric in a form of thigh-high socks~ Ugh, this is too perfect!! 💗

*literally me

Ugh, if only we have big claw arms to complete it...

Parts Used​

Here's the main parts list:

• Body: Ruka Body
• Arms: Ruka Arms/B (should have used the normal version to match the grunge...)
• Legs: Dinorex Legs
• Head: Pro Vosse Head

Accessories:

• Head: Lion Head Shield, Krolik Headgear/B
• Others: Big Robot Shoes/B, Tri Fin Blade, Dinorex Tail

Let's start the showcase then! :3

With the release of version 5.2, Krita brings a lot of JPEG XL improvement! However with added knobs and switches here and there, it can be pretty confusing for a standard user... x3

Here I'll try to give some tips to use it efficiently!

JPEG XL?​

JPEG XL (or JXL for short) is a relatively new image standard by the JPEG committee (yes, the old JPEG that we all familiar with!). It's aimed to be a long-term replacement for web image delivery formats like the old JPEG and PNG. It also have basic animation function like GIF and APNG, and can have a basic layering function as well! Better compression ratio, HDR support, animation support, and up to 32-bit depth support is just a few of their enticing features for me! I myself beginning to phase out PNG for my workflow in digital painting in favor of JXL, especially for lossless storage.. Moreover on HDR pics, no more TIFF for storing simple images!

General export options on Krita​

Here's the Krita's export dialog when selecting JPEG XL format:

I'll try to break it down shortly while copying some of the descriptions from official docs.

1. Save as animated JPEG XL​

JPEG XL has the ability to store small animations like GIF or APNG. This option will save as animated JPEG XL if your canvas has an animation. It is generally safe to left this option enabled even if your canvas is not animated.

2. Flatten the image​

If disabled, JPEG XL has the ability to store frames as layers if it's not being used as animation, this can be useful to store multi-page images like TIFF. Its layered capabilities are very basic, and not designed to store complex layer stacks like PSD and KRA(native krita file) does. However, this option is mutually exclusive with Save as animated JPEG XL, as animated JPEG XL will have the layers flattened. Please refer to the official docs above for detailed limitations!

I don't know what the future will tell, but I recommend to leave this option enabled for web delivery / uploads. ^^

Example of multi-layer JPEG XL image, this one contains 6 layers. Try to open it in Krita 5.2 !

3. Encoding options​

Lossy encoding​

JPEG XL can use either lossy compression like the old JPEG (but much more improved!), or lossless compression like PNG. If you enable this option, it will save as lossy compression and enables some options below.

Quality​

This option sets the desired quality for lossy compression. Higher values look better, but lower values have a lower file size. It defaults to 90. Please note that quality 100 in here doesn't correspond to a lossless like other apps (in more technical term, it only equals to libjxl distance 0.1). For a true lossless, you have to disable the Lossy encoding option above!

Use modular mode​

Use the alternative Modular mode for lossy compression. By default, JPEG XL encodes lossy image with VarDCT mode. Sounds pretty technical to you? In short, VarDCT will look like traditional JPEG compression. You can compare the differences when exporting with low quality values!

4. Tradeoff​

Or as known as Effort in another apps. The bigger the effort, the better the compression ratio will be but the encoding time will be longer!

5. Decoding speed​

Only useful for web delivery optimization to give a faster decoding speed, but generally you should left this option to 0 and barely touch it.

Tips and Tricks​

Originally, it should be a hands-off experience when using Krita's JPEG XL export, meaning you shouldn't fiddle much with the options! But on some use cases, it can be beneficial to tweak those options for a better compression or faster encoding time! Let's see some use cases:

• Lossy web delivery / uploads: Check Lossy encoding and set Tradeoff to 7, you can experiment with Use modular mode as well to suit your needs. For the Quality the default 90 is usually good enough for web viewing, unless you need a specific fidelity / filesize target.

• Pixel Art / small lossless image: Uncheck Lossy encoding and set Tradeoff to 7. For tiny pixel art images (512px or under), you can go with Tradeoff 9 as well to have a better compression.

• Medium to large lossless image: (approx 2k x 2k and up) Uncheck Lossy encoding and set Tradeoff to 1. Indeed this won't be as good as tradeoff 7 for the filesize, but saving time will be much faster.

I need to mention about the trick I often use to reduce color banding, but take note this only works on 16 bpc canvas or more!

Add photon noise! I usually set it around 100-1600 depends on how grainy I'd like it to be and how bad the banding is.

Take a look at some examples of photon noise on very heavy color banding!

this is a very bad case of color banding, that's why I need to bump the noise way higher than my usual setting.

How about the image viewers?​

You can check a list of the supported softwares. I personally use ImageGlass on windows. If you don't want to install other image viewers and okay to do a little registry edit, jxl-winthumb is also a good alternative for seamless support in windows.

Closing thoughts​

I can say that the export UI is not really polished yet (even as a contributor myself!). But I found out that the library that we use in Krita (libjxl) have quite a lot of options that can be fine tuned, and yet I haven't found out the better way to polish it. For example, I'd like to have the photon noise option to be easily accessible and not hidden in the advanced tab... however, I need more objective opinion to improve it even more! Your testing is very appreciated!

Most of the parts are from the base game, but I think it still looks good even on NGS! Totally love the legs part!

Parts Used​

Here's the main parts list:

• Body: Sylphos Body
• Arms: Sapphir Arms CV
• Legs: Grizz Legs CV
• Head: Di Gant Head/B (but this is just a placeholder)

Accessories:

• Head: Sylphos mask, Aile Headgear, Krolik Headgear/B, Rithia Hair Ornament
• Others: Crimpiaco Cape, Fluffy Gloves: White

Let's start the showcase then! :3

Bonus: Pink claw boots on my Personal Space!​

On my post about JPEG XL color analysis I mentioned that JXL stores lossy XYB in absolute, float values that can be requested during decoding process by calling pixel format data_type as JXL_TYPE_FLOAT, where out-of-gamut colors are represented with negative values.

I was recently encouraged by Amyspark from Krita to write my python Color Gamut Plotter to something native, like Qt or web-based. As I also doing hacks and sometimes contributing to Krita as well, I took the Qt path as a base. Furthermore, I'm still more comfortable coding with C/C++ rather than JS, might as well training more with Qt~ :3

And here goes the project result. I added a support for 3D plotting in xyY axes as well for the cherry on top. The 3D is not quite a performant one though, can only be plotted with very small points due to very expensive allocation of one-series-per-pixel needed for the Q3DScatter chart, because the color can't be set per data point, only per series. Thus that's why I also include a monochromatic series to plot with higher density points, although that also a bit sluggish even on my system with RTX 2080 GPU. And for the 2D plot, at first I want to utilize QChartView as well, but hitting the same issue like 3D one, only one color per series and gets exponentially more expensive as the point density rising. Finally I escorted to a custom QWidget, inspired from Krita's CIE Tongue Widget that could be seen when opening an advanced color space selector, adding more features here and there for the ease of chart manipulation. It still wasn't optimized enough and still runs on single core, but it already performs way faster than the python-based one.

Then there was an image file handling issues. The basic QImage itself is already enough to handle most of the common formats like JPEG and PNG. But c'mon, this project was (primarily) meant for JPEG XL as well. And coding wise, integrating libjxl decoding was pretty trivial. But compiling wise, was a bit of a brickwall. I don't know why building libjxl with Qt's MingW kits kept triggering a dll missing entry point or something, even with static C/CXX flags set on libjxl. And even if it does eventually built, there were random crashes when loading specific images. And then I build it separately with LLVM ucrt kits like the one used in Krita build, thus everything works smoothly. Pretty unsure how safe it is to mix the main binary that built with Qt's Mingw kit with deps binary that built with LLVM.. (but since both use gcc and g++, it should be fine I guess?). Anyway, I got it working and set the decode to always ask for unclamped float32.

So here goes the results of some #jxlart plotting, some results were quite stunning with unclamped values! Source JXL art are provided from Jon's official #jxlart page and libjxl discord server.

Credit to Jon Sneyers for the #jxlart sources!

From Jon's Official #jxlart Page​

JXL Logo​

The Smoke Machine​

Minor Misalignment​

Inside The Flying Spaghetti Monster​

Alien Message​

Alien Bushfires​

From Discord and Twitter​

Colored Aurora​

Sierpinski Foam (8K, with alpha)​

Feel free to test it more! I posted the source and prebuild Win64 binaries back in the project's github page.

![Spectral Zephyr](./zeph-spectral.jxl)

Although Docusaurus always complains a lot during compile time:

[WARNING] The image at "{path_to_image.jxl}" can't be read correctly. Please ensure it's a valid image.
unsupported file type: undefined (file: {path_to_image.jxl})

And nope, using JSX didn't work either...

ERROR in {path_to_image.jxl} 1:0
Module parse failed: Unexpected character '' (1:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
(Source code omitted for this binary file)

So yeah, sadly <picture> tag didn't work with JXL here either!

EDIT: Found some workaround yay!​

• The first one is to insert file-loader! before the URL, for example image below:

  <picture>
      <source srcSet={require("file-loader!./dv-nebia-nevia-sub.jxl").default} type="image/jxl"/>
      <img src={require("./dv-nebia-nevia-sub.jpg").default} width="100%" />
  </picture>
  

  However, this method requires a manual insertion for each <picture> tag and will strip any filenames (which is sad!). If the image is still broken, use !!file-loader! instead. Or maybe Docusaurus already fixed the module on the next method!

• The second method requires to fiddle with Docusaurus' webpackUtils source which will use the internal parsing and keeping the filename intact:

  On node_modules, find webpackUtils.js and/or webpackUtils.ts. In my case it's on node_modules/@docusaurus/utils/lib/. Open the file and find getFileLoaderUtils() function, on const rules variable find image field and add jxl to the list:

  images: () => ({
      use: [loaders.url({ folder: 'images' })],
      test: /\.(?:ico|jpe?g|png|gif|webp|avif|jxl)(?:\?.*)?$/i,
  }),
  

  This way we don't need to add file-loader! and just add an URL like usual!

  <picture>
      <source srcSet={require("./dv-nebia-nevia-sub.jxl").default} type="image/jxl"/>
      <img src={require("./dv-nebia-nevia-sub.jpg").default} width="100%" />
  </picture>
  

Example result:

And there you have it! JPEG XL-enabled Docusaurus with fallback image!

Spare me, I'm still a total noob in node.js development... I'm not even sure if those methods are safe, please ping me if you found something!