Keywords in originals get propagated in export

[finestream]

*** Neat piece of software - thank you for developing and sharing it ***

If an original in macOS photo app has keywords (set before importing by some other program) and these keywords were later removed within photos, they still appear in the exported files.

used command line:
osxphotos export --update --touch-file --exiftool --ignore-date-modified --album-keyword --cleanup --filename {created.date}_{created.hour}.{created.min}.{created.sec} --directory {created.year}/{created.mm} .

Possible reason:

• Export obtains the original stored in the App Library
• macOS photos does not change the original (in fact if you export the original using Photos you get the original keywords)
• exiftool appends the keywords
• keywords appear in multiple places "Subject", "Tags List", "Hierarchical Subject" and "Keywords"

Possible solution:

• Remove pre-existing keywords in the file (ExifTool can do this with proper options)
• even better add a flag to control if pre-existing keywords should be removed or not

[RhetTbull]

I'll look into this. --exiftool writes keywords to the following fields:

• IPTC:Keywords
• XMP:TagsList
• XMP:Subject

The documentation should be explicit about what it will do and a flag to control this would be useful. I'm in favor of never deleting metadata unless explicitly told to do so. Thus maybe a --overwrite-exif flag to overwrite existing EXIF data and a documented default of appending it.

[RhetTbull]

In my testing, when run with --exiftool keywords in the original file's metadata do get overwritten. Thus duplicates are coming from somewhere else (maybe album name, person name, etc). When setting keywords via the --exiftool or --keyword-template options, it's the equivalent of doing this:

exiftool -ITPC:Keywords=keyword1 -IPTC:Keywords=keyword2... which does overwrite the keywords already in the file.

That said, you can merge them already using the exiftool template:

osxphotos export ~/Desktop/export -V --exiftool --keyword-template "{keyword}" --keyword-template "{exiftool:IPTC:Keywords}" --keyword-template "{exiftool:XMP:TagsList}"

This uses the template system to create exif keywords from the Photos keywords and the existing keywords in the file.

[RhetTbull]

Given the behavior is already to overwrite the existing metadata, maybe an option for --merge-exifdata that would cause osxphotos to read all exifdata on the original file then merge it before writing it back to the file.

[finestream]

This is interesting. I checked and yes, the keywords are generally overwritten also for me. I have pinpointed one of the files that have the issue and probably it is an issue with the original metadata.

If I try to export a json sidecar for the json file it shows the expected metadata and the jpg file shows the metadata of the original file. This is good.

If I try to apply the metadata with exiftool -json=picture.jpg.json picture.jpg then I get an error
Error: [minor] MakerNotes offsets may be incorrect (fix or ignore?) - <IMAGE_FILENAME>
0 image files updated
1 files weren't updated due to errors

Adding either the exiftool flag -m (ignore minor error) or -F (fix) helps here.

Here a new hypothesis on the problem: exiftool triggers an error that is somehow silently ignored in spite of error handling code in the exiftool wrapper and does not update the metadata for the file.

If this is the issue then the solution would probably be one or more of:

• understand why the error is silently ignored and report it
• allowing to set additional exiftool flags on the command line of osxphotos (e.g., the -m or -F), since fixing the original file in photos might be hard

[RhetTbull]

Are you able to share the image and the associated json file? If so, you can email to rturnbull+git@gmail.com I'd like to see if it's a problem with the jpeg image or the output of osxphotos.

I'll play around with -m and -F to see if it makes sense to add those as standard options. That makes me a little nervous as it could potentially cover a bug in osxphotos but I see the point that it would be best to make sure the --exiftool works even if there's a problem in the original photo.

[finestream]

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:

1. 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
2. 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
3. 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.

[RhetTbull]

I opened new issues for #1, #3 and the exiftool warnings/errors. The code for the latter is almost done.

After reading the exiftool documentation I do not want to add -m or -F as defaults but these could be added via a new --exiftool-flags option. I've also not been able to test -m since I couldn't replicate a file that caused minor warnings.

I'm very leery of implementing #2 as I'd have to have a guaranteed way of detecting this and then figuring out the correct extension. file can detect this but a system call for every exported image would slow things down terribly. Interestingly Photos does not detect this --it correctly shows the image but the database shows that a PNG image with .JPEG extension has UTI of "public.jpeg" so I can't rely on what Photos says the image is.

imghdr in the standard library does this but only for a subset of files. When accounting for RAW types, there are many dozens or more of file types that would need to be accounted for.

I could add a flag that does this only if set, e.g. --fix-filetypes but would need to think about how to safely implement this as getting the extension for a given filetype isn't easy given the plethora of image filetypes. Currently, I use a Mac system call to get the file extension given the UTI in the database but again, in your case, that's wrong. This also complicates the --update process as I need to keep track of multiple filenames (original and fixed). I'll have to think on this one some more.

[finestream]

Thank you! On point 2, fully agree with what you wrote, thought the same.

One possible idea is to do so only when using -exiftool and rely on the error of -exiftool. This would cost 1 extra call to exiftool for the files that are impacted.

A more advanced version of this idea might rise a warning when osxphotos changes an extension and include a flag to opt-out (or to opt-in) the automatic extension correction.

Just my two cents here - I see this as a workaround for incorrect behaviour of Apple Photos.

[RhetTbull]

This might help as it detects more types than imghdr:
https://github.com/h2non/filetype.py

Also, exiftool can do this:
exiftool '-filename<$filename.$filetype'

But adding this to the code would take some work due to where exiftool gets called in the flow.

Will keep thinking about this.

[RhetTbull]

Also, it would be possible to use my photoscript library along with osxphotos to write a script that finds all the incorrect file extensions in Photos and re-imports those photos with correct extension while re-applying all metadata in Photos. You'd lose edit history though.

[finestream]

Thank you, I have already cleaned up the library!

[RhetTbull]

@finestream release v0.38.7 will now report all exiftool errors and will report exiftool warnings when run with --verbose. Additionally, if you use the --report option, the resulting CSV file will have two new columns: exiftool_warnings and exiftool_errors with the text of the warning or error for each file exported.

[RhetTbull]

@finestream New feature 1: add an option to pass additional parameters to exiftools: added in v0.38.9

[RhetTbull]

New feature 3: offer an option to retain tags in the originals

Implemented in v0.38.18 with --exiftool-merge-keywords and --exiftool-merge-persons