How to use osxphotos to recreate my library and preserve as much as possible?

[bernstbj]

My Photos library seems to have something wrong with it which neither the Photos.app itself nor the commercial PowerPhotos seems to be able to resolve. In general, it never finishes detecting faces after months of being left alone and even the photos I added a few weeks back still don't have face circles around them. Looking at the console I think things get stuck or daemons crash, but it might be things as stupid as the photoanalysisd trips on an AVI codec from 23 years ago that isn't recognized by the Mac.

So that has led me to doing a rebuild of my Photos library: export everything, take ancient videos and freshen them with HandBrakeCLI, convert some BMPs which are in there. I've exported the whole lot with osxphotos sorting the output with year/month/albumname and enabled --exiftools. Great, everything is out and I ran a script of mine that did the video upgrades and preserves the EXIF metadata, timestamps, etc.

So now that I have it all cleaned up, I'm looking to import into a newly created Photos.app database.

My questions:

1. Is there a way to import into a specified Photos library like there was during the export and the --db option? Doesn't seem like it.
2. Is there a way to recreate the albums and other folder organizations with the import function? Or is that something I'd have to script on my own to achieve.
3. Will the import function along with the --exiftool argument take all the metadata that was exported from the original run and put it back into this recreated library?
4. Is there a better way I should have exported the library with the goal of reimporting to rebuild and lose litte-to-no data?

If things like getting items into the right albums need to be scripted by me (e.g. find directory names that are not '_'), that's doable. However, if anyone else has used this software to do a minimal-loss rebuild, I'd be happy to hear!
Thanks

[RhetTbull]

Is there a way to import into a specified Photos library like there was during the export and the --db option? Doesn't seem like it.

The osxphotos import command doesn't currently support specifying the library to import to -- it uses the last opened library. So in this case you'd create a new library (quit Photos then open it while holding down Option) and run the import command. See the docs for import here.

Is there a way to recreate the albums and other folder organizations with the import function? Or is that something I'd have to script on my own to achieve.

Yes. Type osxphotos help import to see the full help for import. For example (from the help):

If your photos are organized in a set of folders but you want to exclude one or more parent folders from the
list of folders and album, you can use the --relative-to option to specify the parent path that all subsequent
paths should be relative to. For example, if your photos are organized into photos as follows:

 /                                                                                                            
 └── Volumes                                                                                                  
     └── Photos                                                                                               
         ├── 2021                                                                                             
         │   ├── Family                                                                                       
         │   └── Travel                                                                                       
         └── 2022                                                                                             
             ├── Family                                                                                       
             └── Travel                                                                                       

and you want to exclude /Volumes/Photos from the folder/album path, you can do this:

osxphotos import /Volumes/Photos/* --walk --album "{filepath.parent}" --relative-to "/Volumes/Photos"
--split-folder "/"

This will produce folders/albums 2021/Family, 2021/Travel, and so on.

Will the import function along with the --exiftool argument take all the metadata that was exported from the original run and put it back into this recreated library?

Yes, with exception of persons/faces.

Is there a better way I should have exported the library with the goal of reimporting to rebuild and lose little-to-no data?

Sounds like you did it right. The only option I might have done differently is to use --person-keyword to encode person names as keywords as person's cannot be currently imported. You'll have to re-tag all faces in either case but using the person name as keyword allows you use smart folders or search to find persons until they've been re-tagged. However, you can do this on import using the options: --keyword "{person}" --merge-keywords with your import command.

I think that with the options above, you should be able to recreate the album. Note however that this isn't really the intended use case for osxphotos import but I think it should work. The following command should be a good starting point (replace with your own paths):

osxphotos import /Volumes/Photos/* --walk --album "{filepath.parent}" --relative-to "/Volumes/Photos" --split-folder "/" --exiftool --keyword "{person}" --merge-keywords

I am working on some new code that will enable me to implement an osxphotos copy command (#938) and also an osxphotos transform (#909) that would allow you to re-code the videos in-place and update the Photos library with the new version (osxphotos transform) or copy assets with all metadata from one library to another (optionally creating a new library) (osxphotos copy). The latter may be helpful for cases where the Photos library is "corrupt" and Photos can't fix it but osxphotos can read it (because osxphotos doesn't rely on Photos' code to read the library) to create a new library. These are several months out but I'm making steady progress in between other projects.

[bernstbj]

This is useful information - thank you! I'm going to try the workflow again bit with the person keyword. Will see how this does on a scratch drive.

FWIW, I like how you're looking to bake in transcoding in a future release. I have a script I wrote a few years back that leverages HandBrakeCLI to do this, but re-adding to the photo library is a manual step. I was actually thinking of raising this as an enhancement ticket! That being said, a key thing I'd point out is that while older files tend to get a space savings by moving to something newer, it isn't always the case. The default behavior of HandBrake is to transcode to x264, and that usually will not do a better job than the HEVC / x265 codec that newer iPhones spit out (it WILL do better than my previous 6S or 4S). I haven't looked hard enough yet to figure out the magic combination of EXIF tags to determine if it isn't worth transcoding (Compressor ID / Name isn't definitive to the output), but in general it is a bit of a tradeoff of speed VS compatibility at the moment. I can go a bit more into this if you're interested.

[RhetTbull]

The default behavior of HandBrake is to transcode to x264, and that usually will not do a better job than the HEVC / x265 codec that newer iPhones spit out

It might be possible to code the transcoder directly as an osxphotos pllugin that calls the native encoder from AVFoundation....something to look at when I finish the current round of projects.

[oPromessa]

Hey osxphotos user community!

Recreating Library 100K referenced files

Piggy/backing on this thread I'm now considering recreating the 100K pics Library (coming from the iPhoto times and referenced photos/videos) to avoid/improve some current issues

• not all People analyzed
• the infamous 'Find Original...' message

BIG question: should I go import or sync say?

• Option A: export/import will place all files nicely into folder (my current folder structure I use for import is organised by date of import.. of course future imports once I recreate the Library will give me some work if I want to keep it!
• Option B: sync: would it be much faster than import?
  • I guess I still need to run osxphotos import prior to osxphotos sync
  • It will get all details from the library that I'd otherwise get via XMP.
  • Does it also get People and labels from current Library?

Option A: export/import option:

Some questions:

1. So will filter //live pics for now as import does not cater for them. To figure out later.
2. Exporting with --exiftool and --sidecar xmp and GPS and Keywords even on Movies seem to load/up nicely ;).
3. Importing with --sidecar xmp instead of --exiftoolasI'd export it to be faster to read XMP files than running exiftool on each file.
4. Question: What about Hidden pics, any way to export and import them hidden?
5. On the Edited pics front I'm going with --skip_original_if_edited and get cropped/rotated pics and loose Originals.
6. I think I saw some reference on a post (which I can't find now) on a --directory export dynamic template to achieve the following structure on export to then use on the import later. Is this possible?

2000-2002
      2000
          2000-02-03 Album Name 
          2000-07-07 Album Name 
          ...
      2001
          2001-02-03 Album Name 
          ...
      2002
          2003-09-03 Album Name 
          ...
2003-2005
      2003
          2003-03-15 Album Name 
          2003-07-07 Album Name 
          ...
      2004
          2004-12-03 Album Name 
          ...  

7. As to speed on SSD i7 iMac late 2015 (!) on Monterey (yes, can't upgrade :(. 200 pics/videos load in about 2 minutes. Very small test batch for now, I know !

Option B: sync: would it be much faster than import?

• Still not tested... will go at it now!

[RhetTbull]

@oPromessa Great! Thank you for taking time to test.

Quick question, do we still need to include --walk when specifying something like osxphotos import photos.hard/*

Yes, if you want osxphotos to also import files in subdirectories, you need to specify --walk. Without --walk, just specifying the directory will cause osxphotos to import all files in the top level of the specified directory but not those in the subdirectories. Rationale: User may want to only import a subset of photos without recursing through the whole tree. With the new change, osxphotos import photos.hard/ is equivalent to ``osxphotos import photos.hard/*`

Also, one other change I didn't mention is that osxphotos will now filter any files that are not image or video files. Previously it would try to import any file you specified which would cause Photos to generate an error if it wasn't a valid media file.

There is one other change I want to include before releasing this and that is to add the option to read from an osxphotos export database to reconstruct metadata such as albums. I think I've found a really elegant solution that won't require too much code change. I created a class that can reconstitute an osxphotos PhotoInfo object from the data stored in the database which allows me to just plug this in to the existing code.

[RhetTbull]

@oPromessa when you have time please take a look at the latest importapalooza branch. I believe this is now ready for testing an import of an exported library. A couple things to note:

For the export, you should use --export-aae if you want to preserve adjustments.

For import, try the following:

osxphotos import /path/to/export --walk --exportdb /path/to/export_or_exportdb --verbose

This will cause all metadata, including albums to be read from the export database. You can also use --sidecar if you used --sidecar xmp or --sidecar json on export. In this case, the data in the sidecar takes precedence over the export db (rationale: you might have edited the file/sidecar after export) but the sidecar does not store album info so you must still use --exportdb if you want to restore albums. Edits made to files in external editors will not be preserved -- only non-destructive edits made in Apple Photos are preserved in the AAE files. RAW+JPEG, Live, Bursts, should all be imported correctly.

If you use a different suffix for exporting the edited images, you'll also need to specify this with --edited-suffix. Edited images exported by osxphotos with the suffix will be automatically renamed on import. For example: IMG_1234.jpg and IMG_1234_edited.jpg will be renamed to IMG_1234.jpg and IMG_E1234.jpg to match the format expected by Photos for edited images. Anything after IMG_1234 will be preserved. If name is not in this format, it will be renamed to match the format with an incrementing counter, e.g. IMG_0001_original_name.jpg. This is because Photos requires this format for edited images. See comments on #1113

You can use --auto-live if you have live photos to import from Android or other platforms that aren't natively supported by Photos.

[oPromessa]

This is amazing. Will try to test it in the coming days.

[RhetTbull]

One note: to use the --exportdb option, the export must have been created with the version of osxphotos in this branch or you'll need to use python3 -m osxphotos exportdb --upgrade /path/to/export from the branch to update the exportdb with the needed changes.

[RhetTbull]

FYI, I just used this to export an old iPhoto library from 2014 (1104 photos) that I could no longer open then re-import into a new Photos library using osxphotos -- it worked great and reconstructed all metadata, albums, etc.

[oPromessa]

Doing some tests.

1. Truth be told I picked up a previous exportdbfile and ran --upgrade on it so there may be some garbage. Had some issues with "Could not load metadata from export database for"
   • due to some mismatch on _relative_filepath while using export-has-hardlink and my folder to get pics from being a symbolic link to another location. But can't reproduce on a clean exported.
2. Suggestion: Maybe provide some verbose in the initial functions collect_files_to_import and group_files_to_import.. as with ~64K files on the exported folder (not all pics as there are XMPs also)... it takes some time without user feedback.. one gets anxious ;)
3. These two code sequences shouldn't be similar as one has suppressvs the other?

osxphotos/osxphotos/cli/import_cli.py

Line 1366 in b258ad7

if photoinfo := export_db_get_photoinfo_for_filepath(

osxphotos/osxphotos/cli/import_cli.py

Line 1554 in b258ad7

with suppress(ValueError):

4. Tested with ~180 pics and looks fantastic!
5. At one point I mistakenly indicated on import the --exportdb with --exportdb "$(pwd)"/recreate/photos.hard/.osxphotos_export.dbx but still it worked even though notice the ".dbx" extension.
6. I guess because export_db_get_photoinfo_for_filepath(finds it anyway?

    last_export_dir = export_db_get_last_export_dir(exportdb_path)
    if not pathlib.Path(exportdb_path).is_file():
        exportdb_path = find_export_db_for_filepath(exportdb_path)```

osxphotos/osxphotos/export_db_utils.py

Line 619 in b258ad7

if not pathlib.Path(exportdb_path).is_file():

Will continue testing tomorrow ;)

[RhetTbull]

@oPromessa

.HEIC file is the original Key Photo,not the edited one.

The original of a photo never changes. It is immutable once imported. What happens when you change the key photo is that Photos marks the photo as edited and generates an edited version of the key photo and a new thumbnail preview image for the new key photo. OSXPhotos exports these and the most recent version of import should correctly import these. Do a git pull then try to import one of these that you've edited the key photo on. I think you'll find it's imported correctly and will show the new key photo.

[oPromessa]

Test results after git pull

Export

Exports tuple HEIC/AAE/MOV/XMP

$ osxphotos export photos.hard/ --load-config recreate.toml --library "/Users/Shared/Pictures/iPhoto Shared Library.photoslibrary/database/Photos.sqlite" --name IMG_YYYYMMDD_140937
2024-06-02 18:39:39.572261 -- Loaded options from file recreate.toml
2024-06-02 18:39:39.572789 -- osxphotos version: 0.67.9
2024-06-02 18:39:39.573068 -- Python version: 3.11.5 (main, Aug 24 2023, 15:23:30) [Clang 14.0.0 (clang-1400.0.29.202)]
2024-06-02 18:39:39.594129 -- Platform: macOS-12.7.5-x86_64-i386-64bit, 12.7.5
(...)
2024-06-02 18:40:06.229389 -- Done processing details from Photos library.
2024-06-02 18:40:08.972754 -- Exporting 3 photos to /Users/XXX/Documents/GitHub/Export/recreate/photos.hard...
(...)
2024-06-02 18:40:09.605369 -- Edited file for IMG_YYYYMMDD_140937.HEIC is missing, exporting original
2024-06-02 18:40:09.610697 -- Exporting IMG_YYYYMMDD_140937.HEIC (IMG_YYYYMMDD_140937.HEIC) (3/3)
2024-06-02 18:40:09.628930 -- Exported adjustments of IMG_YYYYMMDD_140937.HEIC to /Users/XXX/Documents/GitHub/Export/recreate/photos.hard/YYYY/YYYY-MM/XXX/IMGYYYYMMDD_140937.AAE
2024-06-02 18:40:09.748859 -- Writing XMP sidecar /Users/XXX/Documents/GitHub/Export/recreate/photos.hard/YYYY/YYYY-MM/XXX/IMGYYYYMMDD_140937.HEIC.xmp
2024-06-02 18:40:09.749722 -- Exported new file /Users/XXX/Documents/GitHub/Export/recreate/photos.hard/YYYY/YYYY-MM/XXX/IMGYYYYMMDD_140937.HEIC
2024-06-02 18:40:09.749994 -- Exported new file /Users/XXX/Documents/GitHub/Export/recreate/photos.hard/YYYY/YYYY-MM/XXX/IMGYYYYMMDD_140937.mov
2024-06-02 18:40:09.750238 -- Touched date on file /Users/XXX/Documents/GitHub/Export/recreate/photos.hard/YYYY/YYYY-MM/XXX/IMGYYYYMMDD_140937.HEIC.xmp
2024-06-02 18:40:09.750603 -- Processed: 3 photos, exported: 5, updated: 0, skipped: 0, updated EXIF data: 0, missing: 0, error: 0, touched date: 3
2024-06-02 18:40:09.751065 -- Elapsed time: 0:00:00
2024-06-02 18:40:09.752990 -- Cleaning up /Users/XXX/Documents/GitHub/Export/recreate/photos.hard
2024-06-02 18:40:09.754100 -- Deleted: 0 files, 0 directories
2024-06-02 18:40:09.754806 -- Writing export database changes back to /Users/XXX/Documents/GitHub/Export/recreate/photos.hard/.osxphotos_export.db
2024-06-02 18:40:09.757974 -- Cleaning up lock files

Import

Import processes HEIC with AAE/MOV/XMP

$  osxphotos import "$(pwd)"/photos.hard/ --library "/Users/Shared/Pictures/Export/recreate/MacPhotosDB/Recreate.Hard.Test.photoslibrary/database/Photos.sqlite" --exportdb "$(pwd)"/photos.hard/.osxphotos_export.db --walk  --stop-on-error 5 --sidecar --verbose --timestamp  --dup-check --skip-dups 
Collecting files to import... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━   
Filtering import list for image & video files... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
Grouping files by parent directory... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
Grouping files into import groups... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
2024-06-02 18:40:33.434403 -- Processing live photo pair with .AAE file: IMG_YYYYMMDD_140937.HEIC, IMG_YYYYMMDD_140937.mov, IMG_YYYYMMDD_140937.AAE
2024-06-02 18:40:33.435523 -- Importing /Users/XXX/Documents/GitHub/osxphotos/working/recreate/photos.hard/YYYY/YYYY-MM/XXX/IMGYYYYMMDD_140937.HEIC, /Users/XXX/Documents/GitHub/osxphotos/working/recreate/photos.hard/YYYY/YYYY-MM/XXX/IMGYYYYMMDD_140937.mov, /Users/XXX/Documents/GitHub/osxphotos/working/recreate/photos.hard/YYYY/YYYY-MM/XXX/IMGYYYYMMDD_140937.AAE
2024-06-02 18:40:44.412294 -- Imported IMG_YYYYMMDD_140937.HEIC with UUID D3A9ACF6-7C63-4141-81BF-2D1D1E4974F5
2024-06-02 18:40:44.420686 -- Setting metadata and location from export database for IMG_YYYYMMDD_140937.HEIC
2024-06-02 18:40:44.422167 -- No metadata to set for IMG_YYYYMMDD_140937.HEIC
2024-06-02 18:40:44.473913 -- Set location for IMG_YYYYMMDD_140937.HEIC: XX, YY
2024-06-02 18:40:44.475541 -- Setting metadata and location from sidecar IMG_YYYYMMDD_140937.HEIC.xmp for IMG_YYYYMMDD_140937.HEIC
2024-06-02 18:40:44.600601 -- No metadata to set for IMG_YYYYMMDD_140937.HEIC
2024-06-02 18:40:44.639274 -- Set location for IMG_YYYYMMDD_140937.HEIC: XX, YY
2024-06-02 18:40:44.640631 -- Set date for IMG_YYYYMMDD_140937.HEIC: 2023-06-20T13:09:37
2024-06-02 18:40:44.768798 -- Setting albums from export database for IMG_YYYYMMDD_140937.HEIC
2024-06-02 18:40:44.770217 -- Adding photo IMG_YYYYMMDD_140937.HEIC to 1 album
2024-06-02 18:40:44.771009 -- Adding photo IMG_YYYYMMDD_140937.HEIC to album iPhoto Events/2023/YYYY-MM-DD AlbumName
2024-06-02 18:40:45.554456 -- Added IMG_YYYYMMDD_140937.HEIC (D3A9ACF6-7C63-4141-81BF-2D1D1E4974F5) to album YYYY-MM-DD AlbumName
(...)
Importing 6 files in 3 groups ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
2024-06-02 18:40:50.188046 -- Done: imported 3 file groups, 0 errors, 0 skipped

Result

Querying Photos the two pics ("one live photo with edit" and "one live photo without edit _1") do seem to show all the info

$  osxphotos query --name IMG_YYYYMMDD_140937 | mlr --c2j cut -f filename,live_photo,path_live_photo then cat
Using last opened Photos library: /Users/Shared/Pictures/Export/recreate/MacPhotosDB/Recreate.Hard.Test.photoslibrary
(...)
Done processing details from Photos library.
[
(...)
{
  "filename": "IMG_YYYYMMDD_140937_1.HEIC",
  "live_photo": "True",
  "path_live_photo": "/Volumes/Macintosh HD/Users/XXX/Documents/GitHub/Export/recreate/photos.hard/YYY/YYYY/MM/XXX/IMG_YYYYMMDD_140937_1.mov"
},
{
  "filename": "IMG_YYYYMMDD_140937.HEIC",
  "live_photo": "True",
  "path_live_photo": "/Volumes/Macintosh HD/Users/XXX/Documents/GitHub/Export/recreate/photos.hard/YYY/YYYY/MM/XXX/IMG_YYYYMMDD_140937.mov"
}
]

Comment

• The Marked KeyPhoto gets imported, marked as Edited by Photos but not recognised as LivePhoto and showing the Original KeyPhoto only!
• If I select in Photos "Revert To Original" it recognises it as LivePhoto and showing the Original KeyPhoto.
• If it works on your test than something is wrong with my setup: please note I'm still at macOS Monterey with Photos Version 7.0 (460.0.120)
• Will try to test on a second Mac with the latest versions.

[RhetTbull]

The Marked KeyPhoto gets imported, marked as Edited by Photos but not recognised as LivePhoto and showing the Original KeyPhoto only!

What's your full TOML config? I suspect from export output you're not exporting both the original and edited version. If that's the case, then that's probably the issue and not sure this is a configuration I want to add code to work around. The code exports both an original and edited version of the photo to be present with the AAE OR just the original + AAE. There is no handling of edited + AAE.

[oPromessa]

That's it. I have skip-original-if-edited.

No need to change the code.

I'll change that in my TOML.

[RhetTbull]

@oPromessa the current branch adds --exportdir to specify the export directory if it's been moved since export.

[RhetTbull]

The new import functionality is now included in release v0.68.0. With the exception of persons/faces it is now possible to accurately re-create a Photos library from an OSXPhotos export while preserving edits, live images, burst images etc.

[oPromessa]

Case 1: Original + AAE

image.jpeg
image.aae

• Original was referenced
• Edits applied

• So I'm going with this option. Testing with 0.68.3 plus PR Fix keyword join for macOS 14.6 (#1628) #1632 found on GitHub.
• Photos knows the pic is edited but does not reflect edits on the pics. Will do some more test.

With Copy to Library Option Enabled

• Pic gets imported into proper folder/album with proper metadata.
• Photos indicates pic to be edited
• Edited is NoiseReduction and Cropping => But image is not shown cropped in Photos
• I have other examples with rotation not applied also.

Logs

• import command line

caffeinate osxphotos import "$(pwd)"/photos.hard --library "/Users/xxx/Documents/XXX/XXX_Test.photoslibrary/database/Photos.sqlite" --exportdb "$(pwd)"/photos.hard/.osxphotos_export.db --exportdir $(pwd)/photos.hard --walk --stop-on-error 5 --sidecar --verbose --timestamp  --dup-check --skip-dups --glob "YYYY*"

* import stdout

2024-08-05 12:14:56.475812 -- Processing import group with .AAE file: YYYY-06-20-005.jpg, YYYY-06-20-005.AAE
2024-08-05 12:14:56.476648 -- Importing /Users/XXX/Documents/XXX/photos.hard/YYYY/YYYY-06/11-20/Digital/YYYY-06-20-005.jpg, /Users/XXX/Documents/XXX/photos.hard/YYYY/YYYY-06/11-20/Digital/YYYY-06-20-005.AAE
2024-08-05 12:14:57.128021 -- Imported YYYY-06-20-005.jpg with UUID 74D38C53-62CF-40C9-BCC6-0B32C7418AA0
2024-08-05 12:14:57.139473 -- Setting metadata and location from export database for YYYY-06-20-005.jpg
2024-08-05 12:14:57.560677 -- Set metadata for YYYY-06-20-005.jpg:
2024-08-05 12:14:57.561331 -- title='', description='', favorite=False, keywords=['SomeKeyword']
2024-08-05 12:14:57.561892 -- No location to set for YYYY-06-20-005.jpg
2024-08-05 12:14:57.562493 -- Setting metadata and location from sidecar YYYY-06-20-005.jpg.json for YYYY-06-20-005.jpg
2024-08-05 12:14:57.969554 -- Set metadata for YYYY-06-20-005.jpg:
2024-08-05 12:14:57.970121 -- title='', description='', favorite=False, keywords=['SomeKeyword']
2024-08-05 12:14:57.970527 -- No location to set for YYYY-06-20-005.jpg
2024-08-05 12:14:57.970906 -- Set date for YYYY-06-20-005.jpg: YYYY-06-20T14:24:00
2024-08-05 12:14:58.036878 -- Setting albums from export database for YYYY-06-20-005.jpg
2024-08-05 12:14:58.037491 -- Adding photo YYYY-06-20-005.jpg to 1 album
2024-08-05 12:14:58.037969 -- Adding photo YYYY-06-20-005.jpg to album iPhoto Events/YYYY-YYYY/YYYY-01-05 YYYY-72 SomeName (Album 2)
2024-08-05 12:14:58.356089 -- Creating folder 'YYYY-YYYY'
2024-08-05 12:14:58.791426 -- Creating album 'YYYY-01-05 YYYY-72 SomeName (Album 2)'
2024-08-05 12:14:59.021567 -- Added YYYY-06-20-005.jpg (74D38C53-62CF-40C9-BCC6-0B32C7418AA0) to album YYYY-01-05 YYYY-72 SomeName (Album 2)

* Original AAE

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>adjustmentBaseVersion</key>
	<integer>0</integer>
	<key>adjustmentData</key>
	<data>
	tVJda9wwEPwvejbGdnpH6rfSNiQEcsUHyUPIw560ttXqw0jrpMdx/z2SfA536REotHqS
	R+Pd2ZndMY0EAghYvWMaPKG7Rtn1xOplucgO0IMU1LO6vFgUGbNOoiEgaU2A9hlrrdNA
	9+j8BGXsebrfmNbGuptRKnE36g06VrOqvC6rqmIZg2F4+4t9WhZ5kZdVER4871FDg89y
	egxdBwUUGwWmBr5as9AYxM/Rkw5qPKsfd2eEoIGNQpEqeCSSpvNREYxkEyjNMNItbhOa
	Pr6LDr8FU6QKFfLFgdKAkKOP84a+UoSWspVpnOb2zkqPDYqRR09WA7rJnNmZm2M6tzoP
	cyvMh94GEfvsQ93lqe4tvCTZIYNOGlBfnR0S8HuVkGlQDY7S7eU4t+1MuSiWgUQOYs5o
	vphOYaK/udIfrwC3JpENzZtRHIOH3YgRSeLx9t6hJPI/mPFBiFeglG3b8JovLz+fnDnR
	dQ9uMOh9JF2WxcmZSXEZ1hySP3lVnQn/h7OpEv7j4N8t7J8jhh1FTiiugGNc/6d5LnL2
	14Sckdsg2ZH3f6v1af8K
	</data>
	<key>adjustmentEditorBundleID</key>
	<string>com.apple.Photos</string>
	<key>adjustmentFormatIdentifier</key>
	<string>com.apple.photo</string>
	<key>adjustmentFormatVersion</key>
	<string>1.4</string>
	<key>adjustmentTimestamp</key>
	<date>2024-07-24T18:59:54Z</date>
</dict>
</plist>

* AAE decode adjustment dada

{
  "metadata": {
    "masterHeight": 615,
    "masterWidth": 1350,
    "orientation": 1
  },
  "formatVersion": 1,
  "versionInfo": {
    "buildNumber": "21H1222",
    "appVersion": "460.0.120",
    "schemaRevision": 0,
    "platform": "macOS"
  },
  "adjustments": [
    {
      "formatVersion": 1,
      "enabled": 0,
      "settings": {
        "auto": 0,
        "inputKeys": {
          "inputEdgeDetail": 1.5,
          "inputRadius": 1
        }
      },
      "identifier": "RKNoiseReductionOperation",
      "formatIdentifier": "com.apple.photo"
    },
    {
      "formatVersion": 1,
      "enabled": 1,
      "settings": {
        "yaw": 0,
        "originalCrop": 0,
        "xOrigin": 0,
        "smart": 0,
        "width": 1350,
        "yOrigin": 306,
        "straightenAngle": 0,
        "auto": 0,
        "height": 615,
        "constraintHeight": 0,
        "constraintWidth": 0,
        "pitch": 0
      },
      "identifier": "Crop",
      "formatIdentifier": "com.apple.photo"
    },
    {
      "formatVersion": 1,
      "enabled": 1,
      "settings": {
        "auto": 0,
        "inputKeys": {
          "inputFalloff": 0.69,
          "inputSharpness": 0.81,
          "inputEdgeScale": 0.22
        }
      },
      "identifier": "RKProSharpenOperation",
      "formatIdentifier": "com.apple.photo"
    },
    {
      "formatVersion": 1,
      "enabled": 0,
      "settings": {
        "inputKeys": {
          "inputDetectedFaces": [],
          "inputStrokes": []
        }
      },
      "identifier": "RKRetouchOperation",
      "formatIdentifier": "com.apple.photo"
    }
  ]
}

• debug-dump file: 74D38C53-62CF-40C9-BCC6-0B32C7418AA0.log

With Copy to Library Option Disabled

• Same result.

[RhetTbull]

Photos knows the pic is edited but does not reflect edits on the pics. Will do some more test.

If you don't import the edited version of the jpeg, Photos will not generate the edited preview until you "open" the photo in Photos. This is a limitation of Photos. I might be able to force this by spotlighting the photo (causing it to be shown full screen) in Photos via AppleScript. Will do some testing when I get a chance.

If you do import with the "_edited" image then it imports to the library even if you are using referenced library. This is a limitation of Photos I've not been able to work around. (As usual, I strongly advise against referenced libraries...)

[oPromessa]

If you don't import the edited version of the jpeg, Photos will not generate the edited preview until you "open" the photo in Photos. This is a limitation of Photos

Yes, that's what I saw happening on Monterey some time back.

Something in Sonoma must've changed as I do "open" the pic but it does not reflect the edits. Going into edit also does not show the edits.

If I manually drag the .AAE and .JPG into photos it has the same result: loaded. Marks pic as edited. It does not apply the edits.

If I do Photos export (osxphotos import or manual import) to JPg it gets exported without the edits.

So Photos seems to mark them as edited but does not recognize the dits themselves.

[RhetTbull]

In that case I'm not sure there's anything osxphotos can do. It's probably better to import the edited image along with the AAE.

[oPromessa]

In that case I'm not sure there's anything osxphotos can do.

Yes.

Meanwhile, just got off the phone with Apple Support and showed them the difference in behavior from Monterey to Sonoma. Tried to convince them of the issue and to fix it, but no luck!

Thinking of recreating the Library still on Monterey and then move the library+files (with Time Machine) to a new computer with Sonoma or Sequoia by next year.