XnView Software

- Load a 24bit png
- Save as JXL lossless
- Close the file
- Load the JXL
- Save as png
- Pointwise compare the saved png to original file

I used the original image I mailed to you
(see viewtopic.php?p=180604#p180604).
You can save the JXL by yourself.
The diff file is included (try splitting it to the 3 hsl channels).

There may be a bug in the JXL encoder,
or in the decoder
or in both.

i've tried with cjxl tool, and it's the same

I don't understand you.

What do you mean by "it's the same"?

Do you mean the jpx file produced by cjxl
- is the same as the original, or
- is it the same as the jpx file produced by xnview?

xnview is wrong in both cases, as the produced file is different than the original.
(Have you checked that? Pointwise difference; see attachment above)
In the second case cjxl is buggy too.

I am confused.

OK, I tried cjxl by myself for x86
https://artifacts.lucaversari.it/libjxl/libjxl/latest/

With option -q 100
It produces a file that is different (even smaller) than yours.
Decoded with with dcjxl to png
it produces a file identical to the original.

==> The error is only in XnViewMP

Thanks to your detailed description I can reproduce the problem.

This problem is supposed to be fixed in XnView MP 1.3.1. Please check and confirm the bug fix here.

I tried the test image you alread know.
JXL lossless.
I compared your jxl file to cjxl's (v.0.8.0).

Your encoding time is about a quarter smaller.
The file sizes differ - to some bytes.
The binary file contents differ completly.
The image (decoded bei djxl) is...
... IDENTICAL !

Congratulations!
How did you do that?
Produce an (about) same sized file encoded a quarter
quicker than the reference implementation!

nji9 wrote: Fri Oct 14, 2022 8:58 am Your encoding time is about a quarter smaller.

Strange, i use only one core, cjxl seems to use multiple...

I checked anew:

Again I used the newest binaries from
https://artifacts.lucaversari.it/libjxl/libjxl/latest/
(They are derived from the latest nightly official sources).
I used the 64bit version (0.8.0) this time,
which has AVX2 enabled.
I took an 9MPixel image for the test.
(BTW 9MP is quite small, realistic images will be around 20MP,
which will have large impact on encoding time, which are already
high with 9MP!)

lossless:
Contents:
The jxl generated by 64bit cjxl is binary about the same then yours
(some bytes in header differ).
Encoding time:
cjxl (CLI; "preloaded" png? Due to 3rd call): 30,7s
XnViewMP: 34,5s
Multithread (MT):
cjxl obviously is compiled with flag "All available Cores"
but 90% of its time does only slightly more then ST1.3.
The times of MT6 at the start and the end.
XnViewMP does ST all the time.
==> The difference in encoding time of my first test was due I
used the 32bit version cjxl.

-q 90:
Encoding time:
cjxl: 3s
XnViewMP: 5,5s
MT:
cjxl uses the same absolute amount of MT than with lossless.
As the all-in-all encoding time is much less than with lossless
it mostly does MT5
XnViewMP: ST

I think this should clear things up.

BTW
JXL format has an "embed" option for JPG and GIF.
This is lossless, encoding takes about 1s (!!!, instead of 35s)
and generates a file size smaller than the original JPG/GIF,
and also smaller than a new generated lossless JXL
(which is actual kind of flif as far as I know).
All you have to do is "shortcut" the input to output
when feeding jxl encoder.
Maybe worth to offer in XnViewMP?