Live Photos and motion photos in a Takeout export

iPhone Live PhotoHEIC or JPG plus a same-stem MP4, one JSON

Pixel motion photoPXL_…MP.jpg, video inside the JPEG

The video getsOnly what it lacks, from the still's JSON

iPhone Live Photos: the MP4 has no JSON of its own

Files	The one JSON they share	Reported in
`IMG_1976.HEIC` and `IMG_1976.MP4`	`IMG_1976.HEIC.supplemental-metadata.json`	GPTH_Neo issue #123
`IMG_1976(1).HEIC` and `IMG_1976(1).MP4`	`IMG_1976.HEIC.supplemental-metadata(1).json`	GPTH_Neo issue #123
`IMG_4288.JPG` and `IMG_4288.MP4`	`IMG_4288.JPG.supplemental-metadata.json`	GPTH_Neo issue #123
`IMG_2552.HEIC` and `IMG_2552.MP4`, next to `IMG_2552.JPG` and `IMG_2552(1).MP4`	Cannot be told apart by name	GPTH_Neo issue #119

The last row is the ambiguous case. Two different Live Photos named IMG_2552, one HEIC and one JPG, each with a video, landed in the same folder. Takeout numbered one of the videos, but nothing in the export records which still IMG_2552(1).MP4 belongs to. The GPTH_Neo maintainer's conclusion in that thread: "it is impossible to reliably map them".

The tools handle the ordinary case in different ways. immich-go pairs the video with the still's JSON through its edited-name prefix rule and uploads the two as separate assets. GPTH_Neo does cross-extension matching (.mp4, .mov and others against a .HEIC, then a .JPG) only in its tryhard mode, and marks the result as not the video's own, so it takes no date or GPS from it; its README says Apple pairs "pass through as separate files".

Examples from GPTH_Neo #123 and GPTH_Neo #119.

Pixel motion photos and MVIMG files

A Pixel phone stores the short video inside the JPEG and marks the name: PXL_20231118_035751175.MP.jpg, with the JSON PXL_20231118_035751175.MP.jpg.json. A retake is PXL_…MP~2.jpg with PXL_…MP~2.jpg.json; both forms are in the immich-go tests, the second from issue #405. Older Pixels used the prefix MVIMG_, as in MVIMG_20191230_232926.jpg. Some exports also contain a separate PXL_…MP file (or .MP~2, .MV, .cover) holding the video part on its own, with no JSON; GPTH_Neo added the .cover and .mp~2 forms after issue #138.

immich-go drops the separate .MP files as useless. GPTH_Neo maps a .MP file to the JSON of its .MP.jpg and its README describes its own option to transform Pixel motion photos as "pretty broken".

FixMyTakeout's rule for the video half

A video with the extension .mp4, .mov, .m4v or .3gp that has no JSON under any of the ordinary rules is checked against the stills in the same folder. If a JSON exists for the same stem with a .HEIC, .heic, .JPG, .jpg, .JPEG, .jpeg, .HEIF or .heif extension, and with the same duplicate number, the video borrows that JSON. A .MP or .MV file (with or without ~2) borrows the JSON of the matching .MP.jpg.

Borrowed is the important word. The JSON belongs to the still, so the video only takes what it lacks:

If the video carries its own creation date in its header (the QuickTime CreateDate or Apple's Keys:CreationDate), that date is kept unchanged, and the zip entry's file date is set from it. Only a video with no date of its own is given the still's photoTakenTime.
A location is written only when the video has none. Google's coordinates never replace a position the video already has, even with the "Always use Google's" option turned on, because that option applies to a file's own JSON.
The caption is written when the video has none.

In the ambiguous #119 layout, IMG_2552.MP4 borrows the HEIC's JSON, since the HEIC is checked first, and IMG_2552(1).MP4 matches nothing, so it keeps its own embedded date rather than being guessed onto the wrong still. The report labels borrowed rows Live Photo video (uses the still's sidecar) or motion photo video part in matched_by, and own date kept (sidecar belongs to the still) in date_source when the video's date won.

The JPEG half of a Pixel motion photo is treated as an ordinary photo. Its tags are rewritten with ExifTool, and the video data appended at the end of the JPEG survives the rewrite; we tested this with a JPEG carrying an MP4 appended the same way, and the video bytes came out identical. The separate .MP part is a format nothing is written into, so it only gets its file date set. See what is written per file type.

Check a Live Photo after the fix

Find a .HEIC and .MP4 with the same name in a Photos from folder of the output.
In fixmytakeout-report.csv the MP4's row should show the HEIC's JSON in sidecar and a borrowed rule in matched_by.
Import both into your photo app and confirm the still and the video sit on the same day. Apple does not document whether Photos rejoins an imported pair into a single Live Photo, so treat them as a photo and a short video that share a date. The Apple Photos guide has the import steps.