Author Topic: Filtering .MOV Files that are the Video component of iOS Live Photos  (Read 141 times)

Tveloso

  • Sr. Member
  • **
  • Posts: 269
When Photos from an Apple iOS Device, that have been taken using the Live Photo feature, are moved to a PC, they are "broken up" into their consitiuent parts: the Still image (in a .JPG or .HEIC File), and the Video (in a .MOV File).

I have tried several approaches in the past to distinguish between a "real" Video, and the Video component of a Live Photo (what I call a Live Photo Clip).

This describes the method I have arrived at for doing that, which hopefully can help someone.  It essentially involves configuring several Data-driven Categories, which can then be used in the Filter Panel (via a Category Filter), to filter for .MOV Files in a given Folder, that either are, or are not Live Photo Clips.

The Files of a Live Photo (the Still and the Video) have a "content identifier" UUID in common in their Metadata. The Tag where that UUID is stored varies across those files, and over time, has also varied within each File.  In particular, the tag where that UUID is stored in .MOV Files, has had eight slightly different names in my IMatch Database (presumably due to changes in ExifTool over time).  So the first step is to isolate all .MOV that have a value in one of those eight Tags.

In order to do that, I created a Category called LivePhoto Clips, and within that, separate Child Categories, each set up as a Data-driven Category based on one of the eight Tags I'm interested in:

       

For example, the QT-CID_1.01 Category is set up based on Tag QuickTime::ItemList\1.1\ContentIdentifier\0:

       

...and to not use the "Other" Category (so the child categories will not include files which do not have that Tag):

       

...and to replace all the unique UUIDs, with a single String of Text (please see the Help on Regular Expressions, and the Advanced Data-driven Category Features and Options for more details on what that Replace Mask is doing):

       

So those 8 DD Categories are based on these Tags:

        Name
        Assigned
        To Category  Based-on Tag
        QT-CID       QuickTime::ItemList\content.identifier\ContentIdentifier\0
        QT-CID_1.01  QuickTime::ItemList\1.1\ContentIdentifier\0
        QT-CID_1.02  QuickTime::ItemList\1.2\ContentIdentifier\0
        QT-CID_1.03  QuickTime::ItemList\1.3\ContentIdentifier\0
        QT-CID_1.05  QuickTime::ItemList\1.5\ContentIdentifier\0
        QT-CID_1.06  QuickTime::ItemList\1.6\ContentIdentifier\0
        QT-CID_1.07  QuickTime::ItemList\1.7\ContentIdentifier\0
        QT-CID_1.10  QuickTime::ItemList\1.10\ContentIdentifier\0

...but your Database may contain other variations of that Tag Name, so when using the Tag Selector to set up a given DD Category for one of those Tags, you should check the Show only tags with data CheckBox...this will determine how many of those ContentIdentifier Tags you actually have in your Database.

Now that we have the LivePhoto Clips gathered into a single parent Category, we can use that Category (recursively) in the Filter Panel, to filter any scope (i.e. any FileWindow) for the files that are in that Category.  We can set the Filter Panel to return Video Files:

        <Screenshot excluded due to limitation on attachment count>

...that are in one of the child categories of the LivePhoto Clips Categry:

        <Screenshot excluded due to limitation on attachment count>

That combination of Filters can then be saved under a Name, and re-used at a later time (as described in the Saving Filters section of the The Filter Panel Help Topic). 

For example, I can apply that saved Filter to check a Folder where I intend to store only "real" Videos, to ensure that it does not contain any Live Photo Clips:

        <Screenshot excluded due to limitation on attachment count>

...or with the Filter Panel's Invert option, I can use that same filter to check a Folder where I intend to store only Live Photo Clips, to ensure that it does not contain any "real" Videos:

       
« Last Edit: October 12, 2021, 05:05:05 AM by Tveloso »
--Tony

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Re: Filtering .MOV Files that are the Video component of iOS Live Photos
« Reply #1 on: October 12, 2021, 09:37:25 AM »
Thanks for sharing  :)

Looks like Apple is making this quite difficult. They could just produce a standard XMP record + a custom Apple namespace where they could store proprietary data in clear text, like "video type": "Live Photo".
Or just use a file naming convention which makes it easy to tell what's what...

The tags you have to use have names which indicate that they depend on a specific version (firmware) of QuickTime (the numbers) and that the tags may be different for later phones or updated firmware.
As you said, a user who has to rely on these tags must keep that in mind and check new files for the existence of these tags.

I could ease the pain by adding another Metadata Tag ShortCodes which hides this problem by being based on several tags.
But I don't use Apple products and I have no deeper insight in their proprietary QuickTime tags. And if I make this a short code tag for IMatch, I would have to always keep up-to-date with whatever change Apple introduces affecting these proprietary tags. And since I'm neither an Apple user or an Apple developer, this would not work.

Phil lists 4 "live" photo tags on the QuickTime page: https://exiftool.org/TagNames/QuickTime.html
Two of them are also mentioned in the QuickTime developer documentation on the Apple web site. Maybe just checking for the existence of these tags?
I have no sample live photos in my test library (send some to @@support please) but I know that Apple offers a JavaScript tool for displaying live photos in a web browser (https://developer.apple.com/documentation/livephotoskitjs), which means IMatch could play them if there is sufficient interest
« Last Edit: October 12, 2021, 10:09:59 AM by Mario »

Tveloso

  • Sr. Member
  • **
  • Posts: 269
Re: Filtering .MOV Files that are the Video component of iOS Live Photos
« Reply #2 on: October 13, 2021, 12:12:59 AM »
Thank you Mario.  I have sent in some sample LivePhoto Files.

Looks like Apple is making this quite difficult. They could just produce a standard XMP record + a custom Apple namespace where they could store proprietary data in clear text, like "video type": "Live Photo".
Or just use a file naming convention which makes it easy to tell what's what...
Yes indeed...I didn't see anything obvious when trying to identify this. 

Apple does usually name the component Files the same (IMG_nnnn.HEIC and IMG_nnnn.MOV), but I found that I could not really rely on that.  Sometimes "name collisions" happened, either as I was manipulating the files in windows (resulting in name changes for one of the pair, so that IMG_nnnn (1).HEIC now does not match IMG_nnnn.MOV), or Photos from others (whose phone is at a different number series) might match an existing "real" video, but they are not actually Live Photo pairs.

Phil lists 4 "live" photo tags on the QuickTime page: https://exiftool.org/TagNames/QuickTime.html
Two of them are also mentioned in the QuickTime developer documentation on the Apple web site. Maybe just checking for the existence of these tags?
When I started trying to definitively identify whether a given Video was actually a component of a Live Photo, I did try initially looking for some reference to "Live" using the ECP, but didn't find anything.  The four tags mentioned on the ExifTool QuickTime page do not appear to be present in my files.  Perhaps there's something more "under the hood" that you'll be able to see in the sample files I sent.

...but I know that Apple offers a JavaScript tool for displaying live photos in a web browser (https://developer.apple.com/documentation/livephotoskitjs), which means IMatch could play them if there is sufficient interest
That would be very cool if you could add the ability to play the Live Photos! 

I understand though, that you cannot devote time to something that not many users would need.  The professionals using IMatch probably don't care much for Mobile Phone Photos...on the other hand, maybe a sizable number of newer IMatch users might also be Apple users...
--Tony

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Re: Filtering .MOV Files that are the Video component of iOS Live Photos
« Reply #3 on: October 13, 2021, 09:34:47 AM »
I have downloaded the sample images, thanks.

When you run ExifTool with the -ee option (extract embedded, search for -ee on https://exiftool.org/exiftool_pod.html) it outputs a ton of extra info for the file, tags in groups named [Doc1], [Doc2], ... [Doc59], each tag named "Sample Time", "Sample Duration", "Live Photo Info" and either a duration in seconds or a list of numbers of sorts.
You can see it in the ExifTool Command Processor using a preset like:

-G1
-all
-a
-ee
-charset
filename=UTF8
{Files}


IMatch does not use the -ee tag, because it produces dozens or even hundreds of additional tag elements, which need to be processed and then ignored. I did so far not see a sense in that, because the info is usually not useful for people. The only use I see is to let ExifTool extract them and then search the output for a tag named "Live Photo Info" to determine if the video file is in fact a live photo. I'm not sure if this is worth the effort to always pull out this data, process it and then produce synthetic photools.com tag from it.

Maybe add a feature request so we can see how many users would be interested in something like that.

Tveloso

  • Sr. Member
  • **
  • Posts: 269
Re: Filtering .MOV Files that are the Video component of iOS Live Photos
« Reply #4 on: October 14, 2021, 04:35:21 AM »
Mario, thank you so much for taking the time to review the sample files, and for the instruction on obtaining the additional embedded data.

It does seem to be quite a bit of work for a feature that would only benefit IMatch users who are also Apple users…probably a small portion of the user base (but maybe a growing one?)

I’ll go ahead and post the FR, just in case others might be interested.
--Tony