Bug 490021

Summary: Support for Apple Sidecar data files (.AAE files)
Product: [Applications] digikam Reporter: Thomas Damgaard <thomasdn>
Component: Metadata-SidecarAssignee: Digikam Developers <digikam-bugs-null>
Status: REPORTED ---    
Severity: wishlist CC: caulier.gilles, metzpinguin, thomasdn
Priority: NOR    
Version: 8.3.0   
Target Milestone: ---   
Platform: macOS (DMG)   
OS: macOS   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Thomas Damgaard 2024-07-10 14:30:04 UTC 
SUMMARY

Please support Apple Sidecar data files (AAE) [1]

Apple devices such as iPhones are easily one of the most commonly used types digital cameras in the world at this point. 
When importing images from Apple devices, you typically get two types of files: the image file (e.g. IMG_9415.JPG or IMG_9255.HEIC) as well as one or more Apple Sidecar data files (e.g. IMG_9415.AAE or IMG_9255.AAE, and so on.).

These side car files contain metadata about the image such as lossless image manipulation such as cropping, etc. 

This being Apple, the file format is likely proprietary, and I would not expect Digikam to be able to actually read and apply the modifications in these files. However, I would expect Digikam to notice that these files are linked to the appropriate image. Such that when I move, say, IMG_9415.HEIC from album1 to album2, then I would expect Digikam to either move IMG_9415.AAE as well (if it exists) or at least prompt me if I want to move this as well. 

It would also be hugely useful if Digikam would have the option to display the .AAE files in the album view. As it is now, the user may move all files from an album to some other album. Open the original album and see it as empty. Then decide to delete the "empty" album. Thus, deleting the .AAE files in the process - files which might have been useful in the future if Apple opens up the format or usable from another app.





[1]: https://file.org/extension/aae ; https://discussions.apple.com/thread/6570393?sortBy=best


STEPS TO REPRODUCE
1. 
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 caulier.gilles 2024-07-10 14:52:29 UTC 
AAE is already supported by ExifTool as PList format :

https://exiftool.org/TagNames/PLIST.html

Switch digiKAm to ExifTool metadata backend in configuration dialog :

https://docs.digikam.org/en/setup_application/metadata_settings.html#behavior-settings

and add AAE to supported sidecar format :

https://docs.digikam.org/en/setup_application/metadata_settings.html#sidecars-settings

Gilles Caulier
Comment 2 Maik Qualmann 2024-07-11 07:48:27 UTC 
Everything that is requested in this bug report can already be done by digiKam. Either as Gilles has already written, add it as a sidecar extension so that the AAE files can be copied, moved or renamed together with the images like XMP sidecars.

https://docs.digikam.org/en/setup_application/metadata_settings.html#sidecars-settings

OR: add the AAE extension as an image MIME type so that digiKam displays it. Of course, only a generic icon will then be displayed, but ExifTool may display metadata.

https://docs.digikam.org/en/setup_application/views_settings.html#mime-types-settings

Maik
Comment 3 Thomas Damgaard 2024-07-12 15:58:52 UTC 
Maik and Giles, Thank you both for your quick and thorough response!
I see that this is indeed already supported. 

I tried adding the aae extension as a sidecard file. This works! That is, moving, renaming images performs the same operation on the aae file.

I wanted to try adding aae as mime-type also. So I went into Settings and typed in "aae" in the mimetypes for images input. Then I clicked OK. 
After this, DK freezes with mouse being hourglass (DK 8.3.0 on Windows where I tested this) and digikam.exe seems to be idle at between 0.00% and 0.01%  CPU (according to Process Explorer)

After like an hour or so, I killed digikam.exe and started DK again.

When I started DK, it still works with renaming an image with corresponding .aae file and the aae file is also renamed. However, the .aae file does not show up in album view. Neither as a thumbnail or as a file without thumbnail.

I am aware that the mimetype config dialog says that DK will rescan the db in the background after changing this setting. However, no active processes were shown while this happened. When I restarted DK and went into setting, "aae" was still present in "additional image file extensions"... So appearently, this does not work.


Some thoughts: Given that .aae files are very common due to Apple devices being very common, would it perhaps make sense to either add .aae files as sidecar files by default - or have a handy checkbox to enable this behavior for this specific file type?
Comment 4 caulier.gilles 2024-09-17 12:35:13 UTC 
>Given that .aae files are very common due to Apple devices being very common, would it perhaps make sense to either add .aae files as sidecar files by default - or have a handy checkbox to enable this behavior for this specific file type?

AAE is a too specific use case. I'm not in favor to add this kind of option. We need to limit complexity.

AAE must work like other sidecar files Maik, it's must be the case no ?

Gilles