Lossless transcoding of lossless, arithmetic, hdr legacy JPEG

[gitoss]

Describe the bug
The official JPEG-XL website states "Lossless JPEG transcoding: about 20% smaller" - however, this some perfectly in-spec jpeg encoding methods are not supported and result only in a cryptic error message "JxlEncoderAddJPEGFrame() failed".

To Reproduce
Encode 1. lossless jpeg (cjpeg -lossless 7), 2. arithmetic jpeg (cjpeg -arithmetic), 3. hdr jpeg (cjpeg -precision 12) and convert with cjxl --lossless_jpeg=1. I've attached respective samples.

Expected behavior
Expected behavior would either be a verbose error message (lossless | arithmetic | hdr not supported) or ideally a lossless conversion to jxl. The arithmetic encoding is easy to remove tough (jpegtran -optimize).

Environment

• OS: Windows
• Compiler version: https://artifacts.lucaversari.it/libjxl/libjxl/latest/jxl-x64-windows-static.zip
• CPU type: x64
• cjxl/djxl version string: cjxl v0.9.0 9b275e5 [SSE4,SSSE3,SSE2]

Additional context
... the sample jpeg won't show inline at all or not in all browers, use the direct links.
https://github.com/libjxl/libjxl/assets/10775306/7905df08-0fc2-400e-a64b-66f3221bce0b
https://github.com/libjxl/libjxl/assets/10775306/7e4980f2-58c8-4f71-8816-c78a98207bc4
https://github.com/libjxl/libjxl/assets/10775306/21223d30-2c6d-47c6-9185-495a984ca79b

[gitoss]

Another case seem to be cmyk legacy jpeg files: #2542 #2580

[antermin]

See also: #1172

We don't intend to support all of the original JPEG spec, nor all of JPEG XT. For lossless JPEG recompression, we only support the de facto JPEG format, i.e. what is commonly implemented in browsers, image viewers, image editors, etc. This includes the JFIF and Exif file formats with a payload that is baseline or progressive Huffman-coded, 1 or 3 components, with or without the YCbCr color transform, and with chroma subsampling that is 4:4:4, 4:2:2 or 4:2:0.

Other things that are in the original JPEG spec but are not considered part of the 'de facto' standard are outside the scope of lossless JPEG recompression in JPEG XL, for the simple reason that they are many orders of magnitude more rare, and it would have been a significant complication to extend the bitstream reconstruction procedure to also accomodate for that. This includes arithmetic coding, lossless, hierarchical, strange subsampling factors, and CMYK (JXL does support CMYK, but not lossless recompression of CMYK JPEGs).

---

a verbose error message (lossless | arithmetic | hdr not supported)

I agree that cjxl should output better error messages. (#2580)

[gitoss]

Right, I didn't see #1172 - that doesn't mention 12-bit jpeg though :-)

I'm leaving the ticket open until a master "better error messages" ticket references it, or it's resolved with an at least slightly less cryptic error message in the code.

[wwinniww]

Mentioning HDR JPEG,
are there plans to support lossless conversation of files in Ultra HDR Image format from Google to JXL?

https://developer.android.com/guide/topics/media/platform/hdr-image-format