Open nekohayo opened 1 year ago
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.
This is so retarded.
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?
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.
@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.
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
Also note there have been some more bugfixes for BMFF (incl. JXL) parsing on exiv2 0.27-maintenance and main branches...
@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.
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.
BS
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.
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.
@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!
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 https://github.com/Exiv2/exiv2/issues/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):
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):
So I ran a lossy conversion, with this Python batch conversion script which basically just runs
cjxl
on each file behind the scenes:Attached is the sample file resulting from this conversion.
The
jxlinfo
tool says the information is present in the resulting file: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:
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