JXL/codestream support

[clanmills]

There is thorough discussion of the emerging JXL standard in #1503.

JXL can have two different file structures.

1. JXL/bmff The file is bmff formatted. Adding support for this format in tvisitor.cpp (the code in my book) required less than 30 lines of code. The effort in Exiv2 will be similar. The jxlc box contains the codestream. The metadata is stored in the boxes Exif and xml. The specification of brotli compressed metadata boxes is still in discussion.

   It's likely that Exiv2 will be able to support JXL/bmff in 2021 as the effort required is modest. Support for the brotli compressed metadata will follow when the standard is defined.

2. JXL/codestream This is a JPEG style stream which begins with the marker 0xff0a. It does not contain Exif of XML metadata. It can contain an ICC profile. Implicit metadata such as the image and orientation are in the code stream.

   The effort to recover the ICC profile from the codestream is the substance of this issue report. It's unlikely that the engineering resources will be available in 2021 to tackle this issue. I have assigned this issue to Milestone v0.28 to make it visible during the v0.28 project life. However, it will probably be deferred.

[clanmills]

There is a brief discussion about the patent situation concerning BMFF/JPEG-XL here: #1679

[antermin]

The following is an example of how to decode the image dimensions of a JXL/codestream file:

https://github.com/Fraetor/pyjxl/blob/7fa61cfb268de422c41727267c02dec1f199dc94/src/pyjxl/decode_jxl.py#L19-L72

[antermin]

It's a PoC because I am a total beginner in programming:

• Not sure whether the correct data / variable types are used.
• Copied getUint64_t from asfvideo.cpp. I don't know how to reuse that function properly.
• No autotests.
• The Visual Studio project files are not touched. (Only tried it on Linux)
• Coding style issues

I referred to the following for the code:

• https://github.com/thebombzen/jxlatte (MIT license)
• https://github.com/Fraetor/pyjxl (MIT license)

Please feel free to adopt and improve the patch / write a better one.

---

Edit: Please see below for latest updates.

[antermin]

Update: I have updated my fork so that it parses the jxlp and jxlc boxes in JXL/bmff files to get the dimensions. In other words, if a JXL/bmff file does not have Exif dimensions metadata (or when exiv2 cannot read the Exif metdata, such as no Brotli support), my fork can probably display it now during exiv2 pr.

If a JXL/bmff file has Exif dimensions metadata, exiv2 prioritizes it, so sometimes it may be inconsistent if:

• Exif dimensions are not the same as actual image dimensions (e.g. the image has been downscaled, but the Exif tags are not updated)
• The image has been rotated (e.g. Exif says 1920x1080 but the actual may be 1080x1920)

I have also tried to backport the Brotli patch to 0.27:

• Brotli-compressed Exif seems to work
• Brotli-compressed XML/XMP doesn't - it looks like the first few bytes (the beginning of XMP packet) are incorrect / corrupted when I added the debug code to dump the bytes.

Any kind of help would be greatly appreciated.

Note: I used 0.27 as the base, since I am not sure whether the main branch has changed the API (and requires code changes in other applications / libraries).

[kmilos]

Thanks for working on this!

Note: I used 0.27 as the base, since I am not sure whether the main branch has changed the API (and requires code changes in other applications / libraries).

IMHO I don't think we really want to introduce new features to 0.27 branch, only security and bug fixes, but I could be wrong... @nehaljwani

[antermin]

I have rebased my PoC code on top of the main branch.