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
Took me a bit to answer as I was running a few more tests on the whole library. I have exported the entire library with json sidecar files and then with an own script called exiftool -json=picture.jpg.json picture.jpg for each file.
Have discovered the following:
I have a number of files with corrupted metadata that exif with standard options (i.e. no -m, no -F) can manage, it triggers a warning that is ignored by osxphotos -> suggestion capture warnings and report them in the summary at the end of the export
There were a handful of files (ca. 0.01% of the library) with corrupted metadata that triggered errors with exiftool: Error: [minor] MakerNotes pointer references previous MakerNotes directory Error: [minor] MakerNotes offsets may be incorrect (fix or ignore?) Error: [minor] Different 'rdf:about' attributes not handled
I all cases calling with -m allows proceeding. Calling -F fixes the files so that successive calls of exiftool do not need -m -> suggestion capture errors and report them at the end of the export, possibly also offer the option to pass -m and/or -F
The test also highlighted a number of originals with the wrong extension (e.g., jpg file with png extension) in the library. Photo.app works fine with these files and osxphotos exports them consistently with the wrong extension (*.png). However, exiftool triggers an error and does not update the file. Calling osxphotos export -exiftool . does not capture the error and reports success. In this case neither -m nor -F fix the problem, the only way to fix is to change the extension -> Same suggestion as point 2. It might also be worth thinking if osxphoto should fix the extension of the exported file in these cases.
Point 3 also offers a way to reproduce the issue that osxphotos does not report errors from exiftool
take any jpg,
[optional] add any tags with exiftool
change extension to png
import the picture.png in Mac Photos
[optional] change tags with Mac Photos
export with osxphotos export -exiftool .
Based on this analysis, it is probably 1 bug and 3 new features:
Bug: osxphotos does not report exiftool errors and warnings
New feature 1: add an option to pass additional parameters to exiftools
New feature 2: detect and correct originals with wrong extensions
New feature 3: offer an option to retain tags in the originals
Hope it helps
PS all the pictures of point 2 above have family members in them and I do not feel comfortable sharing. Nothing personal.
See #2 below. Not sure if I want to implement this or not (it's a Photos bug as far as I'm concerned)
Hi @RhetTbull,
Took me a bit to answer as I was running a few more tests on the whole library. I have exported the entire library with json sidecar files and then with an own script called
exiftool -json=picture.jpg.json picture.jpg
for each file.Have discovered the following:
Error: [minor] MakerNotes pointer references previous MakerNotes directory
Error: [minor] MakerNotes offsets may be incorrect (fix or ignore?)
Error: [minor] Different 'rdf:about' attributes not handled
I all cases calling with -m allows proceeding. Calling -F fixes the files so that successive calls of exiftool do not need -m -> suggestion capture errors and report them at the end of the export, possibly also offer the option to pass -m and/or -F
osxphotos export -exiftool .
does not capture the error and reports success. In this case neither -m nor -F fix the problem, the only way to fix is to change the extension -> Same suggestion as point 2. It might also be worth thinking if osxphoto should fix the extension of the exported file in these cases.Point 3 also offers a way to reproduce the issue that osxphotos does not report errors from exiftool
osxphotos export -exiftool .
Based on this analysis, it is probably 1 bug and 3 new features:
Hope it helps
PS all the pictures of point 2 above have family members in them and I do not feel comfortable sharing. Nothing personal.
Originally posted by @finestream in #292 (comment)
The text was updated successfully, but these errors were encountered: