Brunsli cannot decode JPEG that was compressed in JPEG XL's reference software's unofficial build

[Mithgol]

Looks like an interoperability problem. Steps to reproduce:

Step 1. We'll use the following picture of the “Dude! Let Me In! I'm A Fairy!” meme:

Step 2. When I drag-and-drop the meme at https://google.github.io/brunsli/ to the transcoder, the following JPEG XL file is created:

(ZIP archive of Brunsli's JXL file)

When I drag the JPEG XL file back to the transcoder, the returned JPEG file is byte-by-byte equivalent of the original (step 1), I can confirm it using fc /b original.jpg decoded.jpg on Windows.

Step 3. This time I'll try to repeat step 2 using JPEG XL's reference software. I do not build it myself; I'll use an unofficial build (for Windows) distributed by user Jamaika on Doom9 forum; that build is originally hosted on sendspace.com, but here's a backup copy:

(ZIP archive of Jamaika's build of JPEG XL's reference software)

When I run cjpegxl_jxl --version it reports version 0.0.1-6334944f (seems to correspond to the latest commit in the public repo of JPEG XL's reference software).

When I run cjpegXL_jxl -s 9 on the original JPEG file on Windows, the following JPEG XL is created:

(ZIP archive of JXL file generated by Jamaika's build)

When I run djpegXL_jxl --jpeg on this result, the following JPEG file is decoded:

Its size (84 836 bytes) is larger than original's (80 496 bytes) and it lacks all of the Exif metadata of the original JPEG. However, ImageMagick's comparison magick compare -metric ae original.jpg decoded.jpg nul reports that these files are equal pixel-by-pixel, though not byte-by-byte.

Step 4. When I drag-and-drop the JPEG XL file from step 3 (generated by Jamaika's build) at https://google.github.io/brunsli/ to the transcoder, the following error appears:

Brunsli cannot decode the JPEG file that was compressed in JPEG XL's reference software's unofficial build.

Step 5. Vice versa, when I use Jamaika's build's djpegXL_jxl --jpeg on Brunsli's JPEG XL file (from step 2), the following JPEG file is decoded:

It has the same number of bytes (84 836 bytes) that Jamaika's build's decoded from its own JPEG XL (step 3), but much worse quality.

The above steps were performed in Windows 7 Professional 64-bit (Service Pack 1) running on Intel Core i7-3770 CPU.

The results may indicate that Jamaika's build is built incorrectly.

The results may also indicate that JPEG XL's reference software's authors tried to fix their own version of #80 but failed (the decoded JPEG file started to retain only pixel-by-pixel compatibility instead of its former byte-by-byte, but what's the point if the decoded file becomes larger, and lacks metadata, and does not have full interoperability with https://google.github.io/brunsli/ then).

Would someone kindly make their own build of JPEG XL's reference software and check what's really going on?

[eustas]

JPEG XL specification is an umbrella for several codecs and "containers". "Brunsli" is just one on codecs. That is why it can not decode all the JPEG XL files.

Quality degradation is something new. Going to investigate that on the next week.

[eustas]

Just checked with freshly build binaries on OSX: indeed, --jpeg option causes degradation. I believe it is misleading; at least it should have better explanation what is does. Currently there is no way to ask JXL CLI to restore original JPEG. There is, though, a "to-do" to add that ability.

BTW: one of JPEG XL CLI tools - cbrunsli - could be used to produce files compatible with https://brunsli.dev page. Unfortunately it is not included in Jamaicas build.

[Mithgol]

Brunsli encoder has a separate CLI and Brunsli decoder is not (yet) included in JXL CLI.

It makes sense, and thus the issue's closed.