XnView Software

XnView: MP 1.8.6 - 64 bit
OS: Windows 10 Home - 64 bit

When saving as JPEG XL (JXL) file, using compression 8 and 9 will create a file with bigger filesize than compression 7.

This happens when the original file is 9 MB or larger. This bug doesn't happen on smaller filesize.

To reproduce:
1. Find a PNG file that is 9 MB or larger, e.g. https://svs.gsfc.nasa.gov/vis/a010000/a ... 000000.png
2. Open the image on XnView MP.
3. Choose File - Save as
4. Set the "Save as type" to JXL
5. Click Options, choose "Lossless Compression", then set the compression to 7.
6. Click Save
7. Repeat the previous steps, save the PNG file as JXL but set the compression to 8 and 9.
8. Compare the file size

Actual behaviour (bug): The compression 8 and 9 JXL file has bigger filesize than the one using compression 7.

Expected behaviour: Compression 8 and 9 should have smaller filesize than compression 7. When testing using smaller PNG file (filesize = 2MB), the bug doesn't happen. The saved JXL image has expected filesize that matches the compression level.

Hello,
Also on windows 10. I made some tests with a 11 Mb PNG file, converted into jxl q=90 with effort 7 vs 9. The results obtained by Xnvivew are exactly the same (same weight and same CRC as the results obtained with cjxl.exe v0.11.1 (freely downloadable from github/jxl). In this example, the effort 9 results in a weight very very slightly lower than for effort 7, for a much longer generating time. So the issue, if any, is not on the Xnview side, but on the native jxl encoder side. This issue has been discussed a little bit on github/jxl as, indeed, sometimes effort >7 results are not as good as expected. This is probably why effort 7 is considered the value by default, which appears to be the best compromise in terms of size vs speed.
simon

I see that I have to say a little about the JXL codec.
The EFFORT setting is not the same as, for example, in the WebP codec, where additional bytes are savings. Exactly for the JXL codec is a partial truth. Well, with each higher EFFORT setting, there is added another method of image processing, which either reduces the file, or — attention — increases the quality of the resulting image. And so, for example, if you made an attempt with effort = 4 it turned out that the file is clearly smaller(!), But as if you compared it with the EFFORT = 8 file and the original, you would notice that it is of inferior quality.
So we are not dealing with a coding error, but with a feature of the JXL codec.
You can do any experiments with the help of the Export function in XnView, where you can see the quality and size of the resulting file. It is best to experiment on a small files, where these exchanges can be seen faster.

My the best compromise in terms of size vs speed vs quality is effort = 8.

First, how about compressing about 3-4 of the experimental products [.jxl] into a zip file and uploading them to a secure server this time?

I believe it will only become evidence if other users can reproduce it using the uploaded .jxl files. (Even if they reproduce it with just the original files, no one will be able to determine if it matches your expected results.)