Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

osxphotos import does not correctly handle case of image_edited.jpeg + aae with no original. #1579

Open
RhetTbull opened this issue Jun 15, 2024 · 0 comments

Comments

@RhetTbull
Copy link
Owner

Thanks @oPromessa for the data you sent. I did some additional testing. Here's my results and some analysis.

Case 1: Original + AAE

image.jpeg
image.aae
  • Original was referenced
  • Edits applied

Case 2: Original + AAE + edited

image.jpeg
image.aae
image_edited.jpeg
  • Original imported as IMG_0001_image.jpeg
  • Original was copied to the library, not imported as referenced.
  • Edits applied

Case 3: Edited + AAE

image.aae
image_edited.jpeg
  • image_edited.jpeg renamed to IMG_E0001_image.jpeg
  • OSXPhotos states that it's importing the AAE file: Imported IMG_0001_image.AAE with UUID 494BCB82-2460-4B3D-BA56-40E23A909431. This is because the code creates groups of original+edited+AAE and sorts them so original is first then uses that as the image name. The file gets imported correctly but the actual file name in Photos is IMG_E0001_image.jpeg because that's what the edited version was renamed to and that's the only image file.
  • Image does not get imported as an edited image (Photos thinks it's an original so no edits applied). This is because of the naming scheme -- the photo was renamed to match what Photos expects the edited image to be named but there was no corresponding original.
  • The original is copied to the Photos library, image is not imported as referenced.

Case 4: edited image in form image_edited.jpeg

 image_edited.jpeg
  • Image is imported as an original that is referenced
  • It is not renamed

If you want to import and maintain a referenced library, the only case that does that is Case 1 (original +AAE). However this has a major drawback: The preview image is not created at time of import. That means the version of the photo you see in the Library / all photos view is the original, not the edited. If you open the photo in Photos (double-click it), the preview is generated at this time and will be saved in the library. It would probably be possible to create an OSXPhotos script that cycled through every photo and opened it in the "show photo mode" (PhotoScript, which is used under the hood by OSXPhotos does have the ability to show a photo and I tested that this does indeed cause the preview image to be updated):

>>> import photoscript
>>> photo = photoscript.Photo("E36DF062-CE58-4DE9-9FB8-A70F4A55AB4E")
>>> photo.spotlight()

In Case 2, the image is renamed to IMG_0001_image.jpeg because in order for Photos to associate the rendered edited preview with the original, the files must be named in form original=AAA_NNNN* and edited=AAA_ENNNN* where AAA is any three letters and NNNN is any four numbers. Thus, OSXPhotos will rename any file not already in this form to the correct form for Photos to do the association. For example, if original = IMG_1234.jpeg and edited = IMG_1234_edited, the original will not be renamed (it's already in the correct form) and the edited will be renamed IMG_E1234.jpeg to be in the correct form. This is the only way to make Photos correctly associate the two images and to get the rendered preview "pre-loaded" in Photos as opposed to Case 1.

Case 3 (edited +AAE) is one I did not consider when implementing the import feature. This is a case you'd get if you use --export-aae --skip-original-if-edited. The photo is correctly imported but it's imported as an original that has been renamed to the edited form. I guess this could be considered a bug. The code currently renames any file that has an associated AAE because this must be done to get Photos to recognize the edits. However in this case, the image is renamed with the edited form IMG_E0001_image.jpeg but it's not really an "edited" image. The AAE file is meaningless because the AAE describes changes to the original image but the original image was not exported. Thus if this AAE was imported correctly with the edited image, you would get "double application" of the edits. I have no idea what this would do but it likely won't be what you want. So I guess the correct behavior for OSXPhotos is that if there is an _edited image and no original, do not rename the file and ignore the AAE. I need to think about where this should be a supported use case as it really doesn't make sense to have an AAE file + edited and no original. The AAE file is meaningless in this case.

If I fix this it will take some time as the handling of the _edited images is somewhat complex (because _edited is not hard coded --it's a template that the user can specify). I'm very busy at the moment and may not have time to fix this for some weeks unless I can find a very simple fix.

So in summary, I think if your goal is to import files as referenced files and preserve edits, you should use Case 1 (original + aae, no edited file). I think most users should use Case 2 (original + AAE + edited) to fully reconstruct the library if they don't need referenced files.

As an aside, I strongly advise to not use a referenced file. If you ever change Macs or change the drive the files are on (even if path is the same), then Photos will fail to find the originals. This is because Photos uses security-scoped bookmarks that are sand-boxed to the original volume ID and path to find the originals. I have a project to fix this (RepairPhotosBookmarks) that I intend to eventually incorporate in OSXPhotos but rewriting the database takes significant care and I don't have time at the moment to work on this. The repair code is thus "use as is / best effort". It may or may not work with your version of macOS. Use referenced libraries with caution!

Originally posted by @RhetTbull in #1267 (reply in thread)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant