You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
UUID works as long as you stay on a single Mac but as you noted, if you try to compare to a library from another Mac (or in some cases, if you have to use the Photos library repair tool), macOS changes the UUID. If you are using iCloud, there is a Cloud GUID globally unique identifier. There's also a fingerprint (a hash of some sort) that is unique to a given asset (though videos do not contain a fingerprint). Sometimes the GUID and the fingerprint are the same. For a sample image in my library, these have the value: AcoaTOYrVq2IUcpsJ0MyUoKkcZcB -- as you can see it's a random-looking string of characters. This could be encoded in the exported image -- perhaps in the caption or as the DocumentID/ImageUniqueID...though this expects a UUID and the GUID doesn't match the expected format. You could then have an OSXPhotos script that finds the matching photo in Photos and opens it. OSXPhotos already provides access to these via {photo.cloud_guid} and {photo.fingerprint} templates.
For example, there's a osxphotos show UUID command that given a UUID, finds the matching photo in Photos and opens it. It would be possible to make this command also look for a GUID and a fingerprint and open the photo...this would be fairly easy. As I type this, I realize this is actually a good idea and I'll open a new issue for this.
If you never modify the exported image, the show command could compute the fingerprint and find the matching photo (osxphotos import already does this to avoid importing duplicates). But if you modify the image, you'd need to somehow encode the fingerprint or GUID. One option would be to use extended attributes (for example, in the Finder comments -- which OSXPhotos can write to with --xattr-template findercomment) or in a unique OSXPhotos extended attribute. This would only work if the file was exported to a filesystem that supported extended attributes.
UUID works as long as you stay on a single Mac but as you noted, if you try to compare to a library from another Mac (or in some cases, if you have to use the Photos library repair tool), macOS changes the UUID. If you are using iCloud, there is a
Cloud GUID
globally unique identifier. There's also a fingerprint (a hash of some sort) that is unique to a given asset (though videos do not contain a fingerprint). Sometimes the GUID and the fingerprint are the same. For a sample image in my library, these have the value:AcoaTOYrVq2IUcpsJ0MyUoKkcZcB
-- as you can see it's a random-looking string of characters. This could be encoded in the exported image -- perhaps in the caption or as the DocumentID/ImageUniqueID...though this expects a UUID and the GUID doesn't match the expected format. You could then have an OSXPhotos script that finds the matching photo in Photos and opens it. OSXPhotos already provides access to these via{photo.cloud_guid}
and{photo.fingerprint}
templates.For example, there's a
osxphotos show UUID
command that given a UUID, finds the matching photo in Photos and opens it. It would be possible to make this command also look for a GUID and a fingerprint and open the photo...this would be fairly easy. As I type this, I realize this is actually a good idea and I'll open a new issue for this.If you never modify the exported image, the show command could compute the fingerprint and find the matching photo (
osxphotos import
already does this to avoid importing duplicates). But if you modify the image, you'd need to somehow encode the fingerprint or GUID. One option would be to use extended attributes (for example, in the Finder comments -- which OSXPhotos can write to with--xattr-template findercomment
) or in a unique OSXPhotos extended attribute. This would only work if the file was exported to a filesystem that supported extended attributes.Originally posted by @RhetTbull in #1516 (comment)
The text was updated successfully, but these errors were encountered: