-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please add support for ISO/IEC 23008-12:2017 HEIF file format #318
Comments
Yes, I remember Apple announcing that a year or two ago. The team have quite a lot of work in progress and we hope to release v0.27 by the end of 2018. It's probably not very difficult to deal with this request, however the existing team members already havea lot on their plate. If you really want to see this added, we need to find a volunteer for this task. So, if you, or somebody you know, would like to volunteer, I will be happy to support and mentor your efforts. |
Here is a sample of HEIC file: https://www.dropbox.com/s/wh73l2tdszqkb31/IMG_3071.HEIC?dl=0 |
I've started https://github.com/1div0/exiv2/tree/HEIF already. |
@1div0 Thanks for starting! Please create a pull request sooner than later (mark it [WIP] if it isn't finished yet), so that we can comment early and/or help out. |
Any progress on this file ? HEIF support is just introduced in digiKam, for the moment with supporting decoding file only. Encoding will arrive later. https://imgur.com/JmEgGNS HEIF/HEIC is very well documented and support in native Exif and XMP chunks. Best Gilles Caulier |
Yes, it's work-in-progress: #978 I've given @1div0 encouragement. I'm happy to mentor, however I don't have the bandwidth to take this onto my back. I am the release engineer for quarterly v0.27 "dots" with security and bug fixes. I'm writing a book Image Metadata and Exiv2 Architecture and will run a workshop at LGM in Rennes 28-30 May 2020. #911 I believe Luis and Dan will attend. I've invited Phil (Harvey). It would be wonderful for you to join us and meet before I retire! I'll be 70 on 2021-01-18 and pursuing the goal that Exiv2 will power into the future in the safe hands of Team Exiv2. |
I take a look in devel branch dedicated to HEIF support. This is my remarks : 1/ this code use libheif to handle metadata. This is the expected way to support new format ? Exiv2 must not be free of external dependency for this kind of feature. If yes, i know well libheif now, so i can take a look to finalize this branch if you are agree. 2/ in the branch, HEIF is annotated as read only, even if writing code is present (but not finalized certainly) 3/ IPTC chunk is annotated as available, even if IPTC is not officially supported by HEIF spec from Nokia. https://nokiatech.github.io/heif/technical.html Only Exif, and XMP are supported but format is open store extra metadata chunk. I commented this point to libheif as improvement : strukturag/libheif#124 (comment) 4/ Exiv2 can play with preview image in file format. HEIF has a extra version of master image dedicated to store a "Cover" preview. libheif is not able to extract this image yet. I reported this point here: This preview image can be encoded as JPEG, HEVC, or AV1 codec. My HEIF resume note are below : Exif RW support : yes => can be extracted with libheif. Work perfectly in digiKam Best Gilles Caulier |
Bonjour++ Gilles! Merci. |
Hi, Point 1 has a pending response. Please take a look. If it's fine to use libheif, i can write patch to add a first version of HEIF support to Exiv2... Gilles |
Bonsoir++ I will try to finalize metadata read at first. If you have a time, please consider addition of the metadata write support as second part. I am available via Wire @peak so we can connect better way. |
Look my libheif based code from digiKam here: read: https://invent.kde.org/kde/digikam/blob/master/core/dplugins/dimg/heif/dimgheifloader_load.cpp write: https://invent.kde.org/kde/digikam/blob/master/core/dplugins/dimg/heif/dimgheifloader_save.cpp Both contains code to extract and push metadata byte-array for Exif, Xmp, ICC. Iptc is not supported for the moment. Read is very easy. just use code in place from DK and port to Exiv2 API. It's a game of few hours to code. Write is more complex as you need to get all chunks from original and push as well to the target without re-encoding. libheif must has the low level method for that, if not, you must ask to extend API in Github project. About Preview, it's more complex as it's in Thumbnail multipage chunk. libheif permit to decode image i'm sure but to take raw chunk, i'm not... Gilles |
Hi Peter, I created my HEIF branch in github, and my code is able to get Exif, Iptc, and Xmp. It's based originally on you branch. And yes, Iptc is now officially supported. libheif team introduce new code in "iptc" branch following my recommendations. Look the story : I use your code branch and add libheif code base from iptc branch in Exiv2. Two reason of this : 1/ iptc libheif branch is not yet merge in master and libheif is not yet released with this code. I do the same inside digiKam HEIF image loader plugin, as you can see here : https://invent.kde.org/kde/digikam/tree/master/core/dplugins/dimg/heif There is no incompatibility between GPL2 (digiKam) and GPL3 (libheif) licensing. libheif is not relevant of patents, only HEVC encoder (libx265) is problematic. Look like i also include libde265 in digiKam, as decoding is not a affected by patents. libde265, is also managed by libheif team, and has exactly the same deployment problem under non linux platforms. In all cases, look how i introduce libheif in Exiv2. It fully isolated, and can be dropped easily later when libheif deployment problems will be resolved. TODO : 1/ restore HEIF support as optional, as you do in your branch with a cmake option. Best Gilles Caulier |
Link to HEIF Image generated by digiKam from a JPEG image including Exif, Iptc, and Xmp : https://drive.google.com/open?id=1GPI7RGlrL6uIusEfyDbmxxJeOL-9YLRE Results with Exiv2 CLI tool : [gilles@localhost bin]$ ./exiv2 -pe LR.heic // ------------------------------------------------------------------------------------------------ [gilles@localhost bin]$ ./exiv2 -pi LR.heic // ------------------------------------------------------------------------------------------------- [gilles@localhost bin]$ ./exiv2 -px LR.heic Xmp.digiKam.ImageUniqueID XmpText 64 ca3886c96e6ee1b6edadb251abd21631e5844b4bf7206dff5dd4f51811f96335 Gilles Caulier |
Link to my branch : https://github.com/cgilles/exiv2 Gilles Caulier |
Thank you very much for your efforts. I will have a look l8r today. Merci. Post Scriptum: have a nice weekend! |
With this commit HEIF option at configuration time is back : I also print this option state in cmake configuration resume. Gilles Caulier |
What exact benefit you you think you will gain from writing your own format parser? |
No gain : more time to spare on this task, but left libheif source code. Again, as i said this point must be talk. If libheif is a problem to left in Exiv2, or to add as an external dependency, this is the way to go. Else, we can stay like this... Gilles Caulier |
Just because of the mess with dynamic linked libraries in some operating systems, it does not make any libheif is the best, as it is the only one in this space. Cheers. |
Sûre, but there is another point where I’m not sure : libheif will be able to modify metadata chunks without to re-encode image data ? |
@farindk What do you think about the latest comments above and below? Danke schön. |
If that's the case, then libheif should be fixed, IMHO. Though I really doubt it. I'd assume it only needs to remux the isomp4 container worst-case. |
I just open this file in libheif project, just to be sure... Wait and see : Gilles Caulier |
Voilà, this is what i suspected : strukturag/libheif#105 It's not yet possible to modify an existing HEIF file without to re-encode with libheif. But the problem still open. I also write test code to try to backport Exif/Ipc/xmp from a JPEG image to an existing HEIF file, and it's break the file structure. I will report and talk about this problem with libheif team... Gilles Caulier |
May I suggest a two-step approach and implement read access first with this issue, finish that and implement write access later? |
Well code to update metadata in HEIF with libheif is already on my computer. So I will write an unit test for libheif to test this kind of operations and wait than libheif team patch the library to make the changes. Depending of the Exiv2 plan to deploy next release, the current code to read all metadata is already fine to be used in production. I test well with digiKam, and no side effect is visible from client side. Let's me hear if you want a first PR from my Exiv2 branch with the read only version of HEIF support. Gilles Caulier |
A ISO/IEC 23008-12:2017 encoder/decoder will be required for Canon CR3 too. So the question is if it makes sense to pull in libheif. You probably have to implement a encoder/decoder anyway. |
The proposal #1066 to implement this was met with overwhelming opposition from the community. Until the legal challenges are resolved, we will not get involved with HEIF. |
Topic: Exiv2 and ISOBMFF Support Join Zoom Meeting Meeting ID: 821 3673 0279 |
Tried to join earlier, waited for the host to start the meeting for a while, but but looks like no-one was here? |
I think maybe you had the wrong time zone. The meeting started 2.5 hours before you posted this comment, and was only 40 minutes in length. |
I did join the meeting on time (well, 3 minutes late) and commented much later. Guess the host just didn't notice I was waiting to be let in. |
@AurelC2G I didn't see you in the wait list. About 30 minutes into the meeting, I realised that Paulio was waiting and he joined us for the last 10 minutes. I can't explain why you didn't appear in that list. We were joined by an Australian called Dave and he emailed his CV afterwards and has offered to be involved with implementation and testing. It was agreed at the meeting that the current priority for my time is to finish my book: "Image Metadata and Exiv2 Engineering". https://clanmills.com/exiv2/book/ It is too late to develope ISOBMFF support in Exiv2 v0.27.3 because it's at RC2 with no further changes intended before it ships on 2020-06-30. I have offered Team Exiv2 to do one final release of Exiv2 before I retire permanently. If they ask me to release 0.28, that's what I will do and it's up to the team to decide what to do about ISOBMFF. If my final release is Exiv2 v0.27.4, I will develop ISOBMFF support and get a legal opinion before releasing the code. I won't even include code in a pre-release without legal support. Team Exiv2 may or may not include my implementation in Exiv2 0.28. One of the matters we discussed was the underlying reluctance of Dan and Jens to support this project. Regrettably they didn't attend the meeting. Dan has said to be several times that he is concerned that, while Exiv2 is unlikely to be sued, we could be exposing our users to legal challenges. For that reason why I have offered to get legal assistance before publishing any code involving ISOBMFF. |
Yes, I fell asleep in the afternoon and missed the meeting, sorry about that. But it seems I did not get my point through in the discussion. I'm perfectly happy with you supporting all that. What I wanted to say is that some of the algorithms and whatnots regarding HEIF, AVIF, ISOBMFF are and or were patent encumbered and mostly are not free as in speech. Henceforth you should make them opt-out for the build for those who care or have to care about those kind of things. |
Yes, I'll make it a build option. Something like -DEXIV2_ENABLE_ISOBMFF={On|Off} I'm not planning to work on this any time soon, and possibly never! We'll see. I'm having a lot of fun writing my book. I totally conquered the TiffVisitor last week and expect to finally understand Dave Coffin's DCraw CRW (and other Canon format) parser this week. |
@phako - none of the patents in HEIF, AVIF and ISOBMFF for that matter (at least those that I've seen) thouch any exif-related data. AVIF is an open standard using open codecs to store info in HEIF-compatible way. As for ISOBMFF, according to standard, it's functionally identical to JPEG2000. Aaaand since nobody raised ANY issue ever about reading exif data from JPEG2k I have no idea why anybody would raise issue about ISOBMFF-based files. |
@johnny-bit that's just plain bikeshedding now. |
Please add support for ISO/IEC 23008-12:2017 HEIF file format.
libheif (GPL) already has code to handle exif that could be inspiration
https://github.com/strukturag/libheif
src/heif_context.{h,cc}
ImageMagick, too:
https://github.com/ImageMagick/ImageMagick/blob/master/coders/heic.c
Example files:
https://trac.ffmpeg.org/ticket/6521
The text was updated successfully, but these errors were encountered: