There's a bug in Photos that can [1] make it impossible to work with "bursts" in a Photos Library converted from Aperture. Apple Support confirms it's a bug but there's no fix (too old).
I think my only hope is to remove the burst-id section of the EXIF header of images in Aperture. This may require removing the MakerNotes. Then Photos won't have any bursts to deal with. I would run this against all images in my Aperture Library (50-100K depending on how one counts them).
Before I go down this road is this something that seems possible to do? I'd operate on the files stored within the Aperture package then retry Photos import. Ideally I'd only remove the Burst ID, alternatively I'd like to only remove MakerNotes where the Burst ID exists.
Thank you. Much appreciate any help, this has been a terrible bug to run into.
[1] I think especially happens when one renames files that were part of an iPhone burst. Possible because Aperture doesn't recognize "bursts"
Run the command in FAQ #3 (https://exiftool.org/faq.html#Q3) and try to figure out what tag contains this "burst-id". You could then run exiftool to clear that tag
exiftool -TAG= /path/to/files/
Note that MakerNotes tags cannot be removed, only cleared.
Thank you. I have reviewed FAQ 3 and will be digging in deeper.
To bypass the Apple Photos.app Burst bug I believe I need to change the MakerNote key 11 (Burst UUID) for about 200 JPG files that are stored in a directory tree (along with 55,000 other images).
I believe I can use the ExifTool -r attribute to operate across the tree. The target files will have a unique string in the filename; if ExifTool supports wildcard filename criteria I should be able to limit changes to the 200 files.
I don't yet know if I need to remove key 11 or set it to '0' or set it to NULL. I'll be able to tell by inspecting a non-burst iPhone JPG exif header. (From your example I think I just need to "clear" it.)
Does this plan seem reasonable? Assuming that ExifTool allows wildcard filters in the filenames would a filename substring suffix like "_AppleBurst" suffice for a filter?
If I can make this work there's definitely an ExifTool donation coming (fwiw).
Quote from: jfaughnan on September 13, 2023, 12:14:19 PMI believe I can use the ExifTool -r attribute to operate across the tree. The target files will have a unique string in the filename; if ExifTool supports wildcard filename criteria I should be able to limit changes to the 200 files.
Wildcards won't work as part of the filename when recursing. See the
-r (
-recurse) option (https://exiftool.org/exiftool_pod.html#r-.--recurse) and Common Mistake #2 (https://exiftool.org/mistakes.html#M2).
You could use the
-if option (https://exiftool.org/exiftool_pod.html#if-NUM-EXPR) either to search for specific
BurstUUID values or for substrings in the filename.
-if '$BurstUUID eq "VALUE" 'or
-if '$Filename=~/_AppleBurst/'Alternatively, if you know how to use the command line's
find command, you could use that to filter for the filenames and pipe the resulting list directly into exiftool (see this post (//BurstUUID)) (I don't know
find options, so I can't help with that)
find <options to list "_AppleBurst"> | exiftool -@ - -BurstUUID=QuoteI don't yet know if I need to remove key 11 or set it to '0' or set it to NULL. I'll be able to tell by inspecting a non-burst iPhone JPG exif header. (From your example I think I just need to "clear" it.)
My example above shows how to clear it. If you see a different value in your non-burst files, just set it equal to that value.
Thanks, I'll test those options on my test file. That's a big time saver. I'll report back on this thread how it goes.
By comparing burst to non-burst iPhone JPG I found that BurstUUID should be absent in non-burst JPG.
So to workaround the Apple Photos burst bug I need to remove BurstUUID
I tried exiftool -BurstUUID= ./was_burst.jpg
I thought that would remove the BurstUUID tag per documentation " delete the tag if no VALUE is given (eg. -comment=).' but when I inspect the header after running this I see:
[MakerNotes] Burst UUID :
is still present (but it has a null value now).
UPDATE: https://superuser.com/questions/1730738/delete-one-specific-tag-in-metadata-completely
was helpful. Tags in the MakerNotes group cannot be individually removed. The group must be removed. I'll try that.
Quote from: jfaughnan on September 14, 2023, 01:03:37 PMI thought that would remove the BurstUUID tag per documentation " delete the tag if no VALUE is given (eg. -comment=).' but when I inspect the header after running this I see:
As I said above
Quote from: StarGeek on September 13, 2023, 11:00:07 AMNote that MakerNotes tags cannot be removed, only cleared.
This is also listed in FAQ #23 (https://exiftool.org/faq.html#Q23).
So this seems to be working in testing so far ...
exiftool -r -overwrite_original -progress -MakerNotes= -if '$BurstUUID ne "" ' ./Masters
Masters is the Aperture folder I'm working with. The command removes the MakerNotes group if the BurstUIID Tag is present. I have some further testing to do but I feel this is going to work.
The overwrite_original option causes the system file modified date to change. I think the -P flag will help, so next I'll try:
exiftool -r -overwrite_original -P -progress -MakerNotes= -if '$BurstUUID ne "" ' ./Masters
Thanks for the help on this!
It WORKED. There are complexities one could not imagine but ExifTool did it's part.
The full horror can be read here and is still being updated.
https://tech.kateva.org/2022/01/converting-from-aperture-to-apple.html
One modification -- I ran the tool against the Aperture package because the header is cached in the previews as well.
Donation made. Thank you!
I got the donation, thanks!
- Phil