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
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):
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!
Thanks @oPromessa for the data you sent. I did some additional testing. Here's my results and some analysis.
Case 1: Original + AAE
Case 2: Original + AAE + edited
IMG_0001_image.jpeg
Case 3: Edited + AAE
image_edited.jpeg
renamed toIMG_E0001_image.jpeg
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 isIMG_E0001_image.jpeg
because that's what the edited version was renamed to and that's the only image file.Case 4: edited image in form image_edited.jpeg
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):
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*
whereAAA
is any three letters andNNNN
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 renamedIMG_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 formIMG_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)
The text was updated successfully, but these errors were encountered: