Without modularity, BMFF support cannot be enabled and CR3/JXL EXIF metadata cannot be read in some Linux distributions

[nekohayo]

I am trying things out to see why applications such as gthumb or GIMP are unable to show metadata for JPEG XL files, and as I suspect they use exiv2, I set out to try this directly with exiv2 on the command line. From my testing so far, it does not seem to work, so I'm providing a sample image (a photo I took myself, re-downloaded from my public gallery, that you can use for testing if it remains useful afterwards), with information of what I have tried and observed.

Forgive me if I am misunderstanding the state of things; from what I could infer from looking at #1503 it seems basic EXIF (and XMP?) support for JPEG XL was implemented in exiv2, and released as part of its 0.27.4 release earlier this year, so I'm presuming it's "supposed" to work, unless there is a bug somewhere, hence this report.

In Fedora 35 (and 37), I have version 0.27.5 installed (from the main Fedora repositories):

$ exiv2 --version
exiv2 0.27.5

Alongside this versions of the JXL encoder, which reportedly is able to retain and encode correctly EXIF information from JPEG images (the feature was broken only in the 0.7 version):

$ cjxl --version
cjxl v0.6.1 [SSE4,SSSE3,Scalar]

So I ran a lossy conversion, with this Python batch conversion script which basically just runs cjxl on each file behind the scenes:

$ ./migrate.py 
Root: /tmp/foo
    Found /tmp/foo/20160820173139-787b9c23-la.jpg
        Converting JPG to JXL
Before conversion: 226.56 KB
After conversion: 129.69 KB
Reduction: 42.75 %
Exiting. Press ENTER to continue. Thank you.

Attached is the sample file resulting from this conversion.

The jxlinfo tool says the information is present in the resulting file:

$ jxlinfo -v 20160820173139-787b9c23-la.jxl 
box: type: "JXL " size: 12
JPEG XL file format container (ISO/IEC 18181-2)
box: type: "ftyp" size: 20
box: type: "Exif" size: 13314
Uncompressed Exif metadata: 13314 bytes
box: type: "jxlc" size: 119464
JPEG XL image, 1008x672, lossy, 8-bit RGB
num_color_channels: 3
num_extra_channels: 0
have_preview: 0
have_animation: 0
Intrinsic dimensions: 1008x672
Orientation: 1 (Normal)

However, as you can see below, exiv2 is able to read the EXIF information etc. from the traditional JPEG file, but not from the jxl file:

$ exiv2 /tmp/foo/*
/tmp/foo/20160820173139-787b9c23-la.jpg File name       : /tmp/foo/20160820173139-787b9c23-la.jpg
/tmp/foo/20160820173139-787b9c23-la.jpg File size       : 232001 Bytes
/tmp/foo/20160820173139-787b9c23-la.jpg MIME type       : image/jpeg
/tmp/foo/20160820173139-787b9c23-la.jpg Image size      : 1008 x 672
/tmp/foo/20160820173139-787b9c23-la.jpg Thumbnail       : image/jpeg, 4693 Bytes
/tmp/foo/20160820173139-787b9c23-la.jpg Camera make     : Canon
/tmp/foo/20160820173139-787b9c23-la.jpg Camera model    : Canon PowerShot S95
/tmp/foo/20160820173139-787b9c23-la.jpg Image timestamp : 2016:08:15 12:24:05
/tmp/foo/20160820173139-787b9c23-la.jpg File number     : 100-0024
/tmp/foo/20160820173139-787b9c23-la.jpg Exposure time   : 1/500 s
/tmp/foo/20160820173139-787b9c23-la.jpg Aperture        : F4
/tmp/foo/20160820173139-787b9c23-la.jpg Exposure bias   : 0 EV
/tmp/foo/20160820173139-787b9c23-la.jpg Flash           : No, compulsory
/tmp/foo/20160820173139-787b9c23-la.jpg Flash bias      : 0 EV
/tmp/foo/20160820173139-787b9c23-la.jpg Focal length    : 6.0 mm
/tmp/foo/20160820173139-787b9c23-la.jpg Subject distance: 65.53 m
/tmp/foo/20160820173139-787b9c23-la.jpg ISO speed       : 80
/tmp/foo/20160820173139-787b9c23-la.jpg Exposure mode   : Program (P)
/tmp/foo/20160820173139-787b9c23-la.jpg Metering mode   : Multi-segment
/tmp/foo/20160820173139-787b9c23-la.jpg Macro mode      : Off
/tmp/foo/20160820173139-787b9c23-la.jpg Image quality   : Fine
/tmp/foo/20160820173139-787b9c23-la.jpg White balance   : Auto
/tmp/foo/20160820173139-787b9c23-la.jpg Copyright       : 
/tmp/foo/20160820173139-787b9c23-la.jpg Exif comment    : 


Exiv2 exception in print action for file /tmp/foo/20160820173139-787b9c23-la.jxl:
/tmp/foo/20160820173139-787b9c23-la.jxl: The file contains data of an unknown image type

Did I do something wrong, or might there be a bug remaining somewhere in the current version of exif2 that prevents this from working?

Here's my sample photo: https://fortintam.com/public/exiv2-sample-jpegxl-file-20160820173139-787b9c23-la.jxl

[antermin]

This is a downstream issue - Fedora does not enable BMFF support as described here, see also their build script.
On Arch Linux (which builds exiv2 with -DEXIV2_ENABLE_BMFF=ON), exiv2 can print the EXIF metadata in the sample file successfully.

[1div0]

This is so retarded.

[postscript-dev]

I see that the Exiv2 0.27.5 manpage is missing information about BMFF. I will backport this from the main branch, as it includes an explanation on how to check if BMFF is enabled in your build. Hopefully this will help make the situation clearer for users in the future.

I wasn't involved in the discussions, but I understand that joining the OIN (#1447) was a way of removing any potential issues with BMFF patents. Does anyone know if this is still progressing?

[antermin]

Perhaps the docs can also include JXL in the list, e.g.
(manpage)

Support for BMFF types such as AVIF, CR3, HEIF, HEIC and JXL is a build option

(readme)

Support for bmff files (CR3, HEIF, HEIC, AVIF and JXL)

Hopefully users will be able to notice that JXL containing Exif, IPTC or XMP metadata uses BMFF and requires that build config.

[postscript-dev]

@antermin

Perhaps the docs can also include JXL in the list, e.g.
(manpage)

Thanks for letting me know, I will add this to the PR.

[nekohayo]

Oh I see now, I would never have suspected this. For those interested, this is the downstream ticket I found, it's interesting to see the conundrum they are put in by the presence of that notice: https://bugzilla.redhat.com/show_bug.cgi?id=1979565

[kmilos]

Also note there have been some more bugfixes for BMFF (incl. JXL) parsing on exiv2 0.27-maintenance and main branches...

[postscript-dev]

@antermin

Perhaps the docs can also include JXL in the list, e.g.
(manpage)

As I am already working on the main branch manpage, I will make that update in a future PR.

[nekohayo]

Unless exiv2 could be made modular, and/or joins the OIN (or via KDE?) this is causing endless headaches for legally-cautious Linux distros; from what I can see in this comment in Fedora's issue there is no clear path forward to resolution for those operating systems, unless something changes on the exiv2 front, it seems.

[1div0]

BS

[novomesk]

Regarding the GIMP: the reason why older GIMP was unable to show metadata in JPEG XL files is that it was not implemented in GIMP.

In GIMP 2.99.14 it works, it doesn't matter on EXIV2_ENABLE_BMFF config in exiv2, because JXL container is parsed by libjxl itself first and then the extracted buffers with EXIF and XMP data are passed to exiv2 via wrapper library gexiv2.

[Fraetor]

If the only reason ISOBMFF is not enabled is patent concerns, I think it should be enabled by default.

No patents have been asserted against it, and there is no one claiming that they might have any either, despite its extremely widespread use as the container for .mp4 video. It is questionable if it is even patentable as is basically just [box length][4 char box name][data...].

Even if it was it has reached the point where any patents that theoretically could have existed would have expired. ISOBMFF has existed as a published ISO standard since February 2004, however the format is very similar to the MP4 version 1 format published in 2001, which itself is based on the QuickTime File Format created in 1991. I think patent concerns about a 19 to 32 year box format are generally a waste of everyone's time.

Also as was brought up by @jonsneyers in the JPEG XL discord that the warning currently in the README is meaningless, given absolutely everything might by subject to patents.

[1div0]

@Fraetor could you check https://bugzilla.redhat.com/show_bug.cgi?id=1979565 ?

Software patents are bad idea to begin with.

Thank you for a nice try.

HNY++ Cheers!