Metadata Photo separates pairing, deduplication, metadata attachment, cross-folder comparison and final organisation into clear stages. The examples below show what each stage changes in a real Finder-style library.
Each stage has one job. Pair first, deduplicate within each branch, attach metadata, compare Source against Data Inject, finalise links, then consolidate the library.
Connects the still image and companion video that belong to the same Apple Live Photo, so later duplicate processing treats the pair as one relationship rather than two unrelated files.
Handles Android Motion Photo media separately from Apple content, including recognised motion-video forms, and keeps the confirmed image/video relationship together.
Connects a RAW original such as DNG with its JPEG/HEIC cover so they remain a meaningful pair throughout duplicate detection and later organisation.
After same-branch duplicate work is settled, Apple, Android and RAW masters can receive the matching metadata relationship needed for the later cross-folder stages.
Stage B runs separate duplicate workflows so Apple Live, Android Motion, RAW and ordinary Work files do not get mixed together accidentally. Each branch finds candidate groups, confirms duplicates and keeps the best master.
Compares Apple Live content inside the Apple branch. A confirmed duplicate pair is grouped around one keeper while the Live Photo relationship remains intact.
Does the same branch-safe duplicate work for Android Motion media. Apple-specific files are not used to decide Android relationships.
Compares paired RAW material without separating the RAW original from its cover. The result is a keeper RAW set plus any duplicate sets.
Processes the broader Work branch for standalone photos and videos. Similar files form candidate clusters, duplicates are resolved, and unique items remain standalone.
This is the cross-folder comparison stage. It does not simply deduplicate one folder by itself; it compares the Source library against the Data Inject side so matching media can be resolved across the two streams.
Metadata Photo includes a Finder-style output experience so the consumer can understand the resulting folder hierarchy and see thumbnails rather than interpreting raw logs.
After the main A–F pipeline, these modules repair or enrich metadata and place files into useful structures.
Reads Google Photos sidecar JSON and injects available capture date and GPS metadata into the matching media.
Uses nearby timestamp donor media to fill GPS when an appropriate donor exists within the configured close-time window.
Recognises date/time patterns in filenames and writes them into standard media date fields when needed.
Checks camera EXIF and isolates media without camera information so those files can be reviewed separately.
Categorises files by metadata condition, including media with GPS, media with missing EXIF, and GPS-error cases.
Places Source files according to the corresponding Data Inject relative folder structure using persistent identity matching.
Places remaining unmatched Source files into coordinate-based folders when usable location data is available.
Cleans trailing numeric copy markers such as “(1)” and “(2)” after the structural work is complete.