I've begun early experiments in converting from Aperture to Apple photos. I've not found any good user descriptions of the process. This post will be updated as I do experiments or use the results of experiments to refine my searches.
Before beginning Jason Snell's freely available book chapter on Aperture conversion is a quick read. I also suggest reviewing a fine photofocus post on moving to Lightroom which might be less of an ordeal than migrating to Photos. I chose Photos because of my distrust of Adobe and my knowledge that any commercial photo management solutions is a hard and eternal lock-in. [1]
Trial 1/9/2022
For my first trial I created a new project from a single JPG image and one version using Aperture under Mojave. I copied it to an Intel Air running Monterey 12.1 and opened it in Photos.
Photos said it could not open the Aperture library. It did not say why.
I then regenerated full sized previews per Apple's directions and I tried again. This time the import proceeded. I could see the Version of my original photo but not the original. I then chose Revert to Original and Photos displayed the original image. Then I tried "Undo Revert" but that did nothing. My Version was lost.
Opening the package I could see a file in the originals folder named with a GUID and a .jpeg extension. It had a size of 2.3MB which is the size of the Aperture original.
I tried to repeat the process but Photos declared that "the content of the Aperture library ... has already been migrated to Photos". The famous léonie of Apple forums explained - the conversion process changes the extension to "migratedphotolibrary", I renamed the extension to .photolibrary and I was able to repeat the import process.
On repeating I saw my Version image. I then tried to edit it and got this message:
"Cannot Start Editing Photos cannot edit this image because it uses an unsupported format"
I explored the new Photos library (Package Contents) and could not find any JPG other than my original. I am puzzled as to how Photos generated the version I could see.
There does not appear to be any way to see the original image other than by reverting to original -- which cannot be undone. There also doesn't seen to be any indication that an original exists! (This appears to be a global Photos problem however).
If one wanted to see both a Version and the Original one would need to export the latests version then open that in Preview, then in Photos revert to Original, and export that. Then compare in Preview.
Update 3/31/2023
I finally resolved the stacks Aperture created when I migrated from iPhotos (original image and iPhoto edited). The trick was to find all photos with keyword iPhoto Externally Edited (or similar) then save them to an album then in that album remove any that weren't stacked then unstack, delete externally edited, and re-edit originals (non-destructive).
Then I did "Reprocess Originals" for about 8000 RAW images; about 6,000 were reprocessed and about 2,000 didn't need it. That leads Aperture to slowly regenerate previous/thumbnails. It's been about 24h and that is mostly done, I find that I have to periodically pause the task then restart Aperture (or my laptop) and resume. If I really need to regenerate all full sized previews that processing may take a week or so.
Update Preview is also very slow, it in fact may the rate limiting step since I assume "Reprocess Originals" secondarily also updates previews.
Apple's Published Recommendation (for Mojave)
Choose Aperture > Preferences, click the Previews tab, then change the Photo Preview setting to Don't Limit. Close the preferences window.
From the list of projects in the Library inspector, select all of your projects. For example, click the first project listed, then press and hold the Shift key while clicking the last project.
Click the Browser layout button in the toolbar, so that all photos are shown as thumbnails.
Choose Edit > Select All to select all of your photos.
Press and hold the Option key, then choose Photos > Generate Previews.
Aperture now generates full-size previews for every photo in your library. To follow its progress, choose Window > Show Activity from the menu bar. Quit Aperture when processing is complete.
Open the Photos app, then choose your Aperture library when prompted, as pictured above. If you aren't prompted to choose a library, press and hold the Option key while opening Photos. If your Aperture library isn’t listed, click Other Library, then locate and choose your library.
In my testing "Generate Previews" goes very quickly through JPEG originals. DNG images take longer. RAW images may take longer but I think previews were done when "reprocess originals" was run.
I'm going to partition my images by types (including other) to better understand this step. I think unstacking all photos is also wise.
Update 4/8/2023
In testing I found Photos.app (Monterey) only needs Aperture previews for edited images. I've already created previews for all RAW images. Plan is:
- Remove previews for all images without adjustments including RAW.
- Regenerate high res images for all images that have had adjustments (I already did RAW so don't need to redo those). I think quick view requires previews so I may be able to use that feature to confirm which have previews and which don't.
Update 7/4/2023
What happens to metadata during conversion. Aperture claims it can write IPTC data to images that can handle it. There are many oddball IPTC metadata tags, I've listed only the ones I sometimes used below. Some of these conclusions are based on studying the Photos.app SQLite database.
Aperture Photos
Version Name There's no documentation on how
Photos is handling Version Name and
suspect it varies by macOS release.
In Monterey my test show the Version
Name is at least sometimes used as the
Photos.title rather than the
Aperture title or the filename.
Filename Copied to Photos
Title (IPTC) Copied to Photos
Caption Copied as Photos Description
Keywords Hierarchy (path) flattened,
and each string becomes a kw
Project Name Becomes an album (iPhoto Events)
Project Path Unknown at this time.
Flag Not converted
Date Seems to use Aperture date
Badges Not converted
Location This is saved but location name is lost
Named faces Saved
Star rating Become keywords (1 star, 2 star)
Headline (IPTC) Lost but can write to JPEG
Location (IPTC) Lost but can write to JPEG
City (IPTC) Lost but can write to JPEG
Creator (IPTC) Lost but can write to JPEG
Date Created Unknown at this time
Date (adjusted vs. file date) Image date is used
Last Modified Date Not converted
I was able to retrieve Apple's documentation from the wayback machine (https://web.archive.org/web/20190515155043/https://support.apple.com/en-us/HT204478) to see how conversion proceeds. Here's a plain text version:
Photos and movies migrate without changes. Photos migrate with the adjustments and filters that you applied in Aperture. You can't change the adjustments in Photos, but you can revert to the original image.
Projects and subfolders migrate to folders that are labeled "Aperture Projects" and "iPhoto Events" in the Albums view.
Photos preserves most Smart Albums. Smart Albums with selection criteria that Photos doesn't support usually migrate to Smart Albums with "(modified)" added to the Smart Album name. If Photos doesn't support any of the Smart Album criteria, it doesn't migrate the Smart Album.
Photo books migrate to Albums.
Photos preserves slideshows. If a slideshow theme isn't available in Photos, it uses the default Photos slideshow theme.
Photos preserves Faces data.
Keywords and other metadata:
Photos preserves keywords.
Photos preserves user-defined titles. Images without user-defined titles show as "untitled" in Photos.
Star ratings migrate as similar keywords in Photos, such as "1 Star," "2 Stars," and so on.
Flagged images migrate with the keyword "Flagged" and appear in the "Flagged" Smart Album in the Albums view.
Color labels migrate as keywords, such as "Green" and "Purple."
Photos preserves captions.
Most metadata is preserved in Photos. Some IPTC metadata, including Copyright, won't appear in Photos. This metadata is still associated with the image, and you'll still see it in other applications that show IPTC metadata, like iPhoto and Aperture.
Custom metadata fields don't migrate to Photos.
It's possible to use AppleScript to copy Version Name to Title. As of 7/2023 the following script was copied from Github
tell application "Aperture"
set selectedImages to (get selection)
if selectedImages is {} then
error "Please select an image."
else
repeat with i from 1 to count of selectedImages
tell library 1
tell item i of selectedImages
set versionName to (get value of other tag "VersionName") as string
log versionName
make new IPTC tag with properties {name:"ObjectName", value:versionName}
end tell
end tell
end repeat
end if
end tell
These were PhotoJoseph's 2014 directions for use of this AppleScript
Launch AppleScript Editor and create a new script (File > New).
Paste your clipboard contents into the new window, and click the Compile button to ensure it's all good. If not, just make sure you've copy and pasted all the content from the github page.
Save the AppleScript to the folder ~/Library/Scripts/Applications/Aperture (if any of those folders don't already exist, just create them). Name it something clever like “Copy Version Name to Title field”.
Open the AppleScript Editor preferences and ensure that “Show Script menu in menu bar” is enabled. Without that, you won't be able to access the script from within Aperture. [I think there's a Mojave bug such that this setting may not stick.]
On my not-too-fast Air it takes about 2.5 minutes to process 1000 images. I've set it to do 2000 at a time and check back after 5 minutes. I tried doing 8,000 at a time but that seems to cause Script Editor to hang so the maximum is between 2000 and 8000.
For best performance sort list view by Version name (since it doesn't change), show the Info panel, start at the bottom and select above (2000). The Info panel updates when the script reaches the last row selected.
Update 7/6/2023
From an Apple Discussion post I learned that Apple's conversion process will write the output to the same drive as the input. A tech article on moving the photo library is also helpful to review. Because of the way macOS hard links work (certainly in Monterey and later) the output takes up much less space than one would expect.
I'll be working with a 2TB USB-C/Thunderbolt drive so this is good news.
Fat Cat Software's PowerPhotos also does Aperture conversion. I own it (it mitigates the pain of losing Aperture) so I asked the author about metadata. Note PowerPhotos can browse the original Aperture Library and do conversion even on versions of macOS that don't support Aperture. Here's his response:
Most of that metadata will come through as expected using PowerPhotos. The things I would note:
Version name won't be retained
Aperture projects are stored in the database analogous to iPhoto events. The PowerPhotos conversion mimics Photos' previous migration process, and creates a folder named "iPhoto Events" in the album list, and creates an album for each event/project coming from the source library.
Dates should be retained, though in certain cases there can be oddities with time zones. When you add the Aperture library to PowerPhotos' library list though, you can use the View > Show Subtitle > Date menu item to show the photos' dates and browse through them to see if PowerPhotos is reading them as expected.
For locations, the latitude/longitude will always be retained, but if you had assigned any custom names to particular places in Aperture (e.g. "My House" or whatever), those won't come across.
Star ratings become keywords just like in Photos migration
You're correct that those other IPTC fields will be ignored
Photo stacks should appear as multiple individual photos in PowerPhotos, but again you can double check by browsing through the library first in PowerPhotos to see how they show up.
7/10/2023
iPhoto Externally Edited Cleanup
I have reviewed all the photos that were edited in early versions of iPhoto (previously I'd done a key subset of these); these were stored in Aperture as stacks with the edited version as the "stack pick". I unstacked and either deleted the non-pick or reedited the original and deleted the edited image. There were about a thousand of these so this took a lot of work.
I have learned that stacks will become separate photos in Photos app with the keyword "stack pick" assigned to the pick.
Version name assigned to title when title empty
It took about 30-40 repeat applications of the above referenced AppleScript but all empty titles now hold the version name. I could only do about 2,500 images at a time without crashing Aperture and I went through about 58,000 images.
7/18/2023
Consolidate referenced files
I created a smart album of all referenced files and then consolidated them into the database.
7/19/2023
Update or regenerate previews of all images that Aperture identifies as adjusted. This took a very long time to do for RAW, JPEG was fast. Several hundred were identified as needing updated previews. Images I have not adjusted I'm ok with Photos managing with a preview. Before you do the conversion step redo "update previews"; if previews are current it should go quickly. In my case however, after a database rebuild, some had to be redone. I don't know if that was user error or something weird.
Identify other file types: At one time iPhoto/Aperture could hold audio files and even PDFs. Standard Aperture search shows audio files, I exported those and delete date originals. Search does not support PDF file types but I searched on "PDF" and found 5 images. I removed these from Aperture, a few I converted to JPEG and restored to Aperture. In my testing JPEG2000 images were supported as well PSDs, but I converted the latter to JPEG anyway.
7/25/2023
Preparing for merger with existing Apple System Photo Library. I submitted my plan to Apple Discussions for review, basically I plan to make my converted Aperture Library the Apple System Photo Library which should merge with the smaller older iCloud Photo Library I have now.
Photos Preparation (Current System Photo Library)
- Download all images to my Apple System Photo Library. When you change the download setting in preferences Photos will start bringing down the image files. You can switch to Moments and scroll to bottom of screen to see a transfer progress dialog. A mere 2000 files takes an hour or more on an Intel machine. (Later I did this on an M2 where conversion of a 50,000 image library takes about 3h; that's then followed by Photos' processing that can take days. The conversion is probably 10 times faster on an M2 though.)
- Backup my current Photo Library
- Remove images from the Photo Library that have been exported previously to Aperture (I tagged them with keyword) then purge them from iCloud. Allow sync to happen
- Remove albums that are empty, in general cleanup of the Photo Library
7/26/2023
Repair Library Database: Cmd-Opt on launch gives the option to repair the Aperture Library Database. This is a good measure to make prior to conversion. You can also rebuild the database. In my testing rebuild seemed to work well and I did not have to regenerate Previews for RAW images. It may be wise to do a full database rebuild followed by a database Repair prior to conversion. Look for a Recovery Album to see if anything shows up.
7/29/2023 - Legacy Media
A comment by léonie (192K "points" on Apple Discussions, I wonder if it's a single person!) sent me to their article on
How to Weed out Legacy Media in Photos. Here I see that support for PDFs and audio files was removed, so my intuition to pull those was correct. The problematic items query is excellent. I'm copying his shared image here for posterity. Some of these queries can be done in Aperture but "unable to upload" is Photos.
In Aperture I used this query. I was surprised to find some PSDs and some jp2! However, in my testing Photos including iCloud sync handled both file types (added externally, not through an import).
7/29/2023 - 600 items missing?
UPDATE: I've left this in place but you can skip to the next update for now
I did a test conversion, only took 3h on the M2 Air. Sadly there are 600 fewer items in Photos than in Aperture. I'll document my investigations here using friggin' spaces and a fixed width font because tables aren't supported anywhere any more...
File Type Aperture Photos
RAW 7333 7,333
JPG/JPEG 48,576 48,031
After a full rebuild of the database the JPEG count remained 48,576 and total count was 57,854. After import to photos the result was again 48,031 -- so it's very consistent.
I'm starting my research by focusing on the missing JPG/JPEG.
Sadly, based on my Google Searches and ChatGPT questions there's no way to do this in Aperture. However you can use Aperture's metadata export to create a tab delimited list of some metadata for a list of Aperture images. (Most of the columns are null and I found rows where the title in the list didn't match the title in Aperture or in Photos but it was the best I could do.)
Once I used BBEdit to eliminate duplicates I used an online tool, https://comparetwolists.com, to show me what was in the Aperture list but not in the Photos list. I took that result of 127 rows and then looked for a sample in Photos. Most of the time I could find them, though in at least one instance Photos was using the Aperture Version Name or File Name rather than the Title. I wondered if there was a length limit enforced during conversion (Aperture and Photos have no documented Title length limits.) but I don't think that's the case. I'm continuing to investigate.
Update 8/25/2023: Image count discrepancy - Bursts and Live Images
At least part of the above image count discrepancy is because of the way iPhone "Live Photos" and "Bursts" work. In both cases an Apple proprietary metadata identifier is used to tie files together. In a "Live Photo" it's the
assetIdentifier, in a burst it's the burst's
BurstUUID. These metadata values are set by iPhone when the image files are created. Aperture doesn't know about these identifiers so in Aperture images that were part of burst and files that make up a Live Photo are all counted separately. On import to Photos they are recognized and the "burst" is counted as one image. If you know how to expand a burst in Photos (it's actually less obvious than I'd like) you'll see the images are still there.
After additional date partitioning to compare mismatches of a limited number of images over a problem date range I found no other causes of image mismatch. I decided the conversion process was not losing images.
Update 8/28/2023: Do all my images have previews?
After all the work done to get reapply legacy (ancient) iPhoto edits I want to be sure every image that needs a preview has one. The gear menu has for the Library has a menu item "Maintain previews for all projects". Despite my preview work it showed a dashed line rather than a check mark. When I chose it about 1600 images were identified as needing previews and those were generated. When I selected ALL 54,000 images and chose "update previews" 1387 were identified as needing a preview update. Even thought those seemed to update normally when I repeated "update previews" I got the same number.
So there's something wrong there. I wasn't able to find out what however. I checked all images "with adjustments" and preview update reported they were all current. I then did a database repair, which caused regeneration of thousands of previews and thumbnails. Despite preview update for all photos always identified 1387 items as needing a preview update. I decided to just live with this.
Update 8/30/2023: Conversion day
I moved the external SSD with my Aperture Library on it to my Monterey M2 Air and copied it to the Air's external SSD. Then I ran the conversion for the 56K images, it took about 2-3 hours. When completed I could see I had about 170 burst images; that fits the "missing" 600 photos. I'll be going through them and choosing images to save while removing the others.
I then turned off Photos iCloud sync on my legacy Mojave machine and, after confirming I had my copy on the new machine and backups, I deleted my Mojave Photos.app Library. I'll leave that machine on Monterey for now and Aperture will be untouched.
The next step will be to merge my converted Photos.Aperture Library into my existing Photos.System Library. I will wait until Photos is done processing the Photos.Aperture Library; that may take a day or so. There will be backups.
There's a bug in Photos Monterey and Photos Ventura with managing "Burst" media images generated from an iPhone and stored in Aperture. It may be related to changing either the file name or version name in Aperture. I suspect it's related to version name changes.
The Burst appears to open normally, but count of selected images may be anything from 1 to all and it may not change when an image is selected. Essentially Photos doesn't correctly match the user's selection (user interface) to its internal list of the selected image. I've seen all of the following:
- Nothing happens. You select images, click done and you don't get the usual save all vs save selected dialog.
- You get the save all or save selected dialog but whatever happens next is unpredictable. Some may be saved. In some cases, perhaps most often, all images in the stack simply disappear. The "recently removed" folder does not appear and the images are not in the system trash. If you rebuild the Photos database they may reappear.
I was able to demonstrate the bug to Apple Level II media support. They confirmed it as an "issue" but said there was no hope of a fix. I was able to show it happen in a Library converted by Monterey in Monterey and also when moving the same Library to a Ventura machine.
I have not found a workaround. I may work within Aperture to identify the bursts there and remove all but one image from each burst. I may try to use
ExifTools to remove the MakerNotes (or just Burst ID) from those that remain in Aperture.
Alternatively I may give up and try Lightroom.
Update 9/12/2023: Eliminating Bursts
From Photos Media Bursts folder I identified the date of oldest and latest burst. Then in Aperture I created a query for that date range restricted to .JPG and camera has iPhone. Then I set Aperture to auto-stack any images .09 seconds apart. I then had about 6,900 images to review. I put those that had a stack count > 0 into a "Probably Bursts" folder. This took about 20 minutes to do 1/3 of the work.
Once I've done a couple of scans this way I'll remove all but one image from each burst. Then I hope to use ExifTools to remove the Burst ID.
Update 9/13/2023: Thoughts on eliminating the burst problem
exiftool -tagsfromfile ./iphone_burst.jpeg -makernotes ./target_photos
exiftool -G ./target_photos/gopro_burst_1.JPG
exiftool -BurstUUID="$(uuidgen)" ./target_photos -overwrite_original_in_place
exiftool -BurstUUID ./target_photos
I need to look at the MakerNote for a non-Burst iPhone image to see if I need to remove key 11 or set it to some non-burst value (ex: 0, NULL, etc).
My tentative plan of attach:
- In Aperture eliminate all but one image for each burst (as above).
- Use keywords to tag these images.
- Revert to original and remove previews.
- Review version names and update filenames to match version names with a distinctive filename suffix like _iPhoneBurst.
- Export as test library
- In test library open package and view folders of masters and identify images.
- In test library run ExifTools to make changes as needed across these files using the -r option. I believe I will need to "clear" key 11 with something like [exiftool -TAG= /path/to/files/]. The -r option is not compatible with wildcard filenames but there's an if option: -if '$Filename=~/_AppleBurst/'.
- Move Aperture test library to Monterey machine and convert to Photos Library.
- Review behavior.
Update 9/15/2023 - ExifTools
Progress today:
- Created test library
- Installed ExifTools DMG, no Perl install required
- Found that iPhone non-burst images lack the BurstUUID Tag completely
- ExifTools can't remove individual tags in MakerNotes but it's possible to remove the entire MakerNotes: exiftool -MakerNotes= noMakerNotes.jpg
- Created a test library and tried converting that on Monterey Photos. I found the same bugs as before with burst photos but the image I removed the MakerNotes from shows as a regular image. Sadly the burst version wasn't imported, perhaps because Photos.app considered it to be a duplicate and excluded the entire burst. See a later comment on duplicate photos and bursts.
My current version of the ExifTool command is:
exiftool -r -overwrite_original -P -progress -MakerNotes= -if '$BurstUUID ne "" ' ./TestSuite.aplibrary
The -r flag means it will recurse over all subdirectories of the TestSuite Aperture Library, overwrite_orginal manes that the original image is removed, -P keeps the modification date of the original, -progress gives me a list of changed files, -MarkNotes= means the MakerNotes group of tags is removed, the -if statement tests for presence of the BurstUUID.
The -progress output can be copied out of terminal and with a bit of regex I was able to extract file names (not guaranteed unique!) for 1,564 images stored in Aperture that had a BurstUUID.
You want to remove the MakerNotes from both images and previews. You do want to create previews for every image despite my earlier experiments with not creating previews for non-edited images.
Despite removing the MakerNotes about 68 images still rendered as Bursts. On inspection with ExifTools they don't appear to have MakerNotes and thus no BurstUUID visible to ExifTool. I am mystified. My best guess (see
my stackoverflow comment) is that Aperture cached the EXIF data and Photos read it from that cache during the import process.
Update 9/15/2023 - Photos Conversion Duplicate Delete Bug
In a test library I had two versions of a single image in a test album. One had the MakerNotes removed. They also had different titles. After converting to Photos the image with MakerNotes removed was missing, but it's container album said two image were present. After rebuilding the Photos database the album reported one image present.
I don't know if this is "normal" (albeit buggy) Photos behavior or if it's an indirect result of the Burst Bug. I fear it is normal behavior for converting an Aperture Library; that metadata is ignored and perhaps edits and versions are also ignored.
On the other hand with non-Burst images in my testing Photos did retain multiple Aperture Versions from one Master image as long as the images differed.
Update 9/17/2023 PowerPhotos Migration of an Aperture Library
My sanity feels restored. I used PowerPhotos to convert my Aperture Library. This can work with post-Monterey macOS as well as Monterey. The results are reassuring.
PowerPhotos reported 97 images in my Aperture library and 97 images in the post-conversion Photos Library. When I opened Photos it showed 87 images and 10 videos. For the first time the counts agreed!
Most importantly - NO BURSTS. All the burst images are now independent. So there wasn't anything in the Burst images or the Previews; the (flawed) resurrection of the Bursts in the absence of the MakerNotes must have been related to copying some unknown data source (independent cache of EXIF data?) from Aperture. (I did not find BurstUUID in the Aperture.xml file stored in the Photos package by the Photos conversion process.)
I am further evaluating this process but my initial take is that PowerPhotos migration is vastly better than trying to use the native Photos conversion.
Update 9/17/2023: Puzzling test results, need remove BurstUUID and use PowerPhotos conversion
I created a single Aperture test library with a single known burst in it called MicroBurstTest. I also retested my larger BurstTestLibrary.
The results surprised me. To get a reliable translation I needed to use both the ExifTool step and I had to use PowerPhotos.
MicroBurstTest NoBurstUUIDRebuilt: FAIL with Photos Conversion
MicroBurstTest: PASS with PowerPhotos Conversion, 4 images in burst, can edit
MicroBurstTest NoBurstUUID: PASS with PowerPhotos Conversion 4 separate photos
BurstTestLibrary 2: FAIL with PowerPhotos Conversion, image selection bug.
Everything failed when I use Photos native conversion, even if I remove the burstUUID (MakerNotes) from all images and then fully rebuild the Aperture database. I thought that would deal with a hypothetical caching bug but it made no difference. (I didn't try creating an export Library then importing the Export Library into an empty Aperture Library -- mostly because I'm very tired of this and I may have a fix.)
PowerPhotos conversion seemed to work in my small library even if I left the BurstUUID intact, but when I tried a larger library the bursts I tested sometimes behaved properly and sometimes the selected image vanished.
I'm hoping I can move on, but for now I'm thinking there are two issues/bugs:
Burst image selection bug: This doesn't happen to every image. I wonder if it's something triggered by version renaming or title or file renaming in Aperture. The image you select can vanish and the count of selected images doesn't match one's selection. I have a few burst images that work properly following a PowerPhotos Conversion but many do not.
Burst reconstruction: a Burst is reconstructed even though the BurstUUID is gone, I think this is due to Aperture storing EXIF data from an image and not updating that even with a complete database rebuild.
I'm now proceeding to testing running ExifTools against the entire library, then regenerating Previews, then trying the bug library with PowerPhotos.
Update 9/17/2023 PowerTools import of entire library: 57,844 images
After using ExifTool to remove all BurstUUIDs and converting to Photos using PowerPhotos I had 57,844 images imported with one error in the log that I need to look at. Likely a corrupted or incompatible video. The process was slower than Photos native conversion. There were no Bursts in Photos after the import. This number lines up with what I expected.
Update 9/20/2023 Testing good so far, Aperture clean-up continues.
So far testing is good. I'm cleaning up Aperture for the final migration; I may test Photos in Sonoma to see if the Burst Bugs are any different.
There's a feature that lets you write the modified date into the exif header and maybe the file date; I realize I should carefully do that in Aperture for some of the photos I've re-dated to the time they were taken (vs. when I scanned them).
I posted this summary to the Facebook Aperture Group, when I'm done it will end up as part of an introduction to this post.
If you haven't migrated off Aperture yet and you hope to keep any of your titles, version names, dates etc time is running out. You should always be able to get your Originals out, but access to edits (Previews) and especially metadata (names, titles, descriptions, folder relationships, etc) is at increasing risk.
So far testing from my latest attempt to migrate to Photos.app is good. As per my prior notes I needed to use:
ExifTool to work around the Burst bugs.
PowerPhotos to do the migration (because of bugs with Photos native conversion)
An Apple Script to copy Version Names to titles. (Apple script itself is on the edge of extinction btw)
There was also a lot of review and cleanup including removing files not supported by Photos (esp iCloud) or most other media apps.
I don't know how migration to anything else would work. Life is way too short to test. I chose Photos seeking safety in numbers. I wish a competitor had a solid "exit" strategy.
If there's any chance you will need to use Photos you should buy PowerPhotos (https://www.fatcatsoftware.com/powerphotos/) *now* and let the dev know of your interest in the Aperture library conversion feature (works in Sonoma). For him the Aperture conversion was very much an afterthought (built atop some old iPhoto conversion). He's a much better dev than the poor intern who got suck with the Photos conversion. PowerPhotos also provides core functionality that should have always been a part of Photos.
I'd recommend saving a copy of my blog post on the process [1]. I'm not immortal, it could go at any time. I'm sure it's wrong and flawed but this kind of knowledge is dying fast. Some things I found in only one old, almost forgotten, web page. You should also assemble the tools I used just in case you end up on Photos somehow.
If you want to send a bill for your time to Tim Cook please do. I figure $20,000 would be about right for me [2]. Apple could have prepared a high quality Aperture export to a well documented public intermediate data model that Lightroom or others could read from with good results. Including documenting Apple's edit rules. They didn't because they didn't (and don't) give a sh*t. (sorry, expletive earned).
I'll clean up my blog post when I'm all done. For now it's relatively agreeable cleanup of existing content in Aperture prior to repeating my migration.
Backups? Oh, yeah, I got backups 😳.
[1] https://tech.kateva.org/2022/01/converting-from-aperture-to-apple.html
[2] Plus a pittance for PowerPhotos and a donation to ExifTool.
Historical posts related for shared misery
[1] Laughably I chose Aperture because I figured Apple's user base and resources were large enough that if Aperture died Apple would provide a good migration path. So my choice of Photos is very debatable. What we need is a media management solution that's open source and used by multiple commercial vendors. Ask me if you want the requirements and design spec for this :-).
