Support for iOS Live Photos

[Tveloso]

As discussed in this post:

        https://www.photools.com/community/index.php?topic=11894.msg84810#msg84810

...this is a request to add support for iOS Live Photos "natively" in IMatch.

So that IMatch will automatically recognize the component files if a Live Photo, keep them associated with each other (stack them?), and Play them in the QuickView Panel and/or the File Window, as discussed in an earlier post, in that same topic.

[Asgard]

+1
Nice feature. I guess rather many Windows users also have iphones and would appreciate this in IMatch. I am one of them

[Mario]

So that IMatch will automatically recognize the component files if a Live Photo

What does this mean? I'm not sure what you mean here.

With the trick I showed you, ExifTool digs deeper into the file to possibly find more metadata. Most of it noise, except maybe the tag name only included when the file is a Live Photo. And then repeated 50 or 100 times per file.

This does does not change how IMatch detects and treats the .MOV and .HEIF file (which I really hate, due to the literally hundreds of software patents attached to HEIC/HEIF).
IMatch will not touch split the HEIC/HEIF into its components.

Versioning works just fine if you use a consistent naming convention or you find a metadata tag that links these files.
If Apple would be less interested in locking their customers into the Apple ecosystem, the standard XMP Document and XMP Instance Ids would be perfect for that. Because, this is what they have been designed to do. Tracking versions of a file, related files, derivative files and so on. Independent of the name or format. And it would be viewable and usable in IMatch, including auto-stacking etc.
But, hey, Apple... 

[vsammy]

I find this a very useful idea for iPhone users.

Just an idea how it could be implemented without messing with the EXIF data:

In imatch an option could be selectable if you want to display heic and mov with the same filename as one image (only the heic is displayed, the mov becomes invisible). Maybe with a symbol/marker that it is a live picture. With a single click the photo is displayed, with a click with an appropriate key combination the invisible mov file is played.....
I think that would be a sensible solution, also because of the clarity.

Vsa

[Tveloso]

So that IMatch will automatically recognize the component files if a Live Photo

What does this mean? I'm not sure what you mean here.

With the trick I showed you, ExifTool digs deeper into the file to possibly find more metadata. Most of it noise, except maybe the tag name only included when the file is a Live Photo. And then repeated 50 or 100 times per file.

That is essentially what I meant...as you described in the other Topic, IMatch would need to use the Extract Embedded option, just to determine that a given .MOV File is part of a Live Photo (and probably then discard all of the other data delivered by that option, maybe even including the values inside the "Live Photo Info" Tag itself - just needing to see that the Tag is present?)

So now IMatch knows that the Video is part of a Live Photo...but there's also the Still Image component...

IMatch will not touch split the HEIC/HEIF into its components.

I thought I saw sometime ago, that you explained that HEIC/HEIF is a container format, that's meant to house different types of Media (i.e. that a given HEIC File, could contain both a Still Image and a Video?).  I'm guessing that maybe within the Apple ecosystem, it is stored that way?...

But when a Live Photo is sent to the PC, there are actually two files sent, the Video (in a .MOV File), and the Still (in either a .JPG or a .HEIC File)...so Apple has already broken up the Live Photo into its components?

I used to wonder if the HEIC File actually "might" still also contain the Video, and in the Windows environment we could only see the Still - but I think that's wrong.  Especially when I saw that Apple's Tool for playing a Live Photo (that you mentioned in the other topic), needs to be explicitly given the names of both files:

Code Select Expand

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <script src="https://cdn.apple-livephotoskit.com/lpk/1/livephotoskit.js"></script>
    </head>
    <body>
        <div
            data-live-photo
            data-photo-src="https://..."
            data-video-src="https://..."
            style="width: 320px; height: 320px">           
        </div>
    </body>
</html>

...so IMatch would need to keep track of the two files, and keep them associated as the components of a Live Photo.

But as you said:

Versioning works just fine if you use a consistent naming convention or you find a metadata tag that links these files.

And this is what I'm doing...although I'm having to re-evaluate some of this due to changes in the Tag Names for the UUID that links the files.  In the Still, there seem to be just two tags where that UUID will be stored (which seems to be due to a name change for that Tag):

     {File.MD.Apple::Main\17\ContentIdentifier\0}
     {File.MD.Apple::Main\17\MediaGroupUUID\0}

...and I'm pretty sure that if I were to re-scan all my files, the second tag would now be where the UUID lives.

But for the Video, there are a number of tags where that UUID Lives (in only one of those tags in a given file, but varying across files):

        QuickTime::ItemList\content.identifier\ContentIdentifier\0
        QuickTime::ItemList\1.1\ContentIdentifier\0
        QuickTime::ItemList\1.2\ContentIdentifier\0
        QuickTime::ItemList\1.3\ContentIdentifier\0
        QuickTime::ItemList\1.5\ContentIdentifier\0
        QuickTime::ItemList\1.6\ContentIdentifier\0
        QuickTime::ItemList\1.7\ContentIdentifier\0
        QuickTime::ItemList\1.10\ContentIdentifier\0

...and here I'm not sure whether newly indexed files will consistently deliver that UUID in the same tag (I still need to investigate that for my versioning scheme).

If Apple would be less interested in locking their customers into the Apple ecosystem, the standard XMP Document and XMP Instance Ids would be perfect for that. Because, this is what they have been designed to do. Tracking versions of a file, related files, derivative files and so on. Independent of the name or format. And it would be viewable and usable in IMatch, including auto-stacking etc.
But, hey, Apple... 

Yes indeed.

As I was writing this post, I began wondering whether this FR might just be too specialized, and this is maybe something that IMatch should not offer - especially since it looks like this stuff is still changing (more breaking changes for Mario to have to deal with).

And IMatch gives us so many tools already, maybe "internalizing" this functionality is not needed?...on the other hand, it would be nice for IMatch to take care of it too...(I'm obviously still waffling about this)...

[Mario]

I won't touch HEIC/HEIF files. This is probably the image/video format most infected by software patents ever.
The MPEG and all the dozens of patent holders are breathing down the neck of everyone just looking in the direction of a HEIC/HEIF file.
A image format based on software patents. Really?

It's fine for free software like ExifTool or FFMpeg. But IMatch is considered commercial and I don't want to pay annual royalties to Apple, Nokia, Samsung and whoever holds one or more patents on the algorithms used to produce HEIC/HEIF files. I cannot afford the law firm which could sort out all the contracts needed with the MPEG and other interested parties. These lawyers charge several hundred US$ per hour!

Apple switched to HEIC/HEIF it to lock their customers tighter into the Apple ecosystem and to get away with smaller (aka cheaper) internal memory in their phones. That's how I see it.
I'm no fan of patent-infested file formats, for obvious reasons. HEIC/HEIF is not cleared for long-term archival for libraries and other bodies requiring long-term format safety. Which is telling.

The fact that Apple seems to be the only company using this format tells you a lot. And that they seem to force their users to use that format (?)...

Also, I find it interesting that the HEIC/HEIF WIC coced is the only codec in Windows you have to manually download.
Because Microsoft must pay royalties to Apple / others for each installation. Hence it's cheaper for them to let users who want it download it, instead of including it in Windows.

I'm also reluctant to add the Apple Live Photo JavaScript library to IMatch (to "play" Live Photos), because who knows which data it collects about you and your computer and sends home to the Apple mothership...²
I think it's not needed anyway. The only way to get a Live Photo "out" of the Apple walled garden, apparently, is to let Apple break it up into an image and a video. And there are tools to view images and play videos in Windows already.

² which is also the reason the Map Panel goes a long way to only load the Google JavaScript libraries when a user really uses Google Maps. It would be much easier for me to just drop in all the libraries the Map Panel may need.