XMP: Add support for reading fstop:favorite flag

[akirk]

I use the app F-Stop on Android to tag photos as favorite (with a heart symbol). Additionally, F-Stop can be configured to create XMP side-car files for this added metadata. It stores the favorite data in a custom fstop:favorite attribute.

This adds support for parsing this attribute and automatically marking a photo as favorite upon import.

This is my first contribution, I tried to get everything right but happy to follow up to get it merged.

[CLAassistant]

All committers have signed the CLA.

[lastzero]

@akirk My apologies for the long delay! Without conflicts and with your suggestions it looks like it can be merged ❤️

[graciousgrey]

It should be noted that information from xmp files is always preferred over data from PhotoPrism. This means that if the favorite flag is set in the xmp file, it will also be set in PhotoPrism.

If you remove the favorite status in PhotoPrism, you must also remove the favorite flag from the xmp file, otherwise the photo will be marked as favorite again at the next complete rescan.

[akirk]

@lastzero Thanks for the update. I've rebased the PR and added the suggestions.

@graciousgrey I agree but also I don't think that we can always be sure we're able to modify XMP files to sync this. I don't know the codebase well enough but is it possible to find out if an image was just added to the database and only then apply the favorite flag? In case of a full rescan the image would just be found and not added and thus the favorite flag could be ignored in order to avoid the re-favoriting that you described.

[graciousgrey]

Long term we plan to support writing metadata changes from PhotoPrism back to Exif and XMP (optionally). Once this is implemented, the favorite flag would be removed from the xmp when the photo is marked as non-favorite in PhotoPrism. However, this feature will most likely not be available very soon.

In case of a full rescan the image would just be found and not added and thus the favorite flag could be ignored in order to avoid the re-favoriting that you described.

Some users intentionally edit xmp files, for example with other tools, of photos that have already been added to PhotoPrism and want that data to be read in during the next full rescan. Therefore, it would be problematic to ignore changes in xmp files if the photo has already been indexed before.
For individual XMP fields this might make sense, but even there it is probably very dependent on the individual workflow.

[akirk]

Some users intentionally edit xmp files, for example with other tools, of photos that have already been added to PhotoPrism and want that data to be read in during the next full rescan. Therefore, it would be problematic to ignore changes in xmp files if the photo has already been indexed before.

Oh, this is not what I was trying to say. This was specifically about the favorite flag and setting from non-favorite in PhotoPrism to favorite. So the following behavior:

• New file, favorite in XMP → Added to PhotoPrism as favorite
• New file, not favorite in XMP → Added to PhotoPrism non-favorite
• Existing file, favorite in XMP, favorite in PhotoPrism → favorite in PhotoPrism (= no change)
• Existing file, non-favorite in XMP, favorite in PhotoPrism → non-favorite in PhotoPrism (= unfavorite)
• Existing file, non-favorite in XMP, non-favorite in PhotoPrism → non-favorite in PhotoPrism (= no change)
• Existing file, favorite in XMP, non-favorite in PhotoPrism → non-favorite in PhotoPrism (= no change !!)

[graciousgrey]

That's what I meant by saying that it might make sense to have special logic for individual fields :)

However, it depends on the workflow, so there is no right or wrong way to do it.

In general I can see two use cases:

A) The user sets the favorite status in xmp with another tool. He adds the photo to PhotoPrism and then only uses PhotoPrism to manage the favorite status of the photos.

This refers to:

Existing file, favorite in XMP, non-favorite in PhotoPrism → non-favorite in PhotoPrism (= no change !!)

B) The user adds the photo to PhotoPrism. He then uses another tool to mark photos as favorites and wants this information to be displayed in PhotoPrism.

This refers to

Existing file, favorite in XMP, non-favorite in PhotoPrism → Favorit in PhotoPrism

instead of

Existing file, favorite in XMP, non-favorite in PhotoPrism → non-favorite in PhotoPrism (= no change !!)

Since this field seems to be an individual field created by the F-Stop app and is most likely not used by other apps, I assume that the use case in this case will only be A). Since the app probably can't access the files once they are in the Originals folder, right?

[akirk]

That's what I meant by saying that it might make sense to have special logic for individual fields :)

Ok, right :)

Since this field seems to be an individual field created by the F-Stop app and is most likely not used by other apps, I assume that the use case in this case will only be A). Since the app probably can't access the files once they are in the Originals folder, right?

I suppose it depends on how you sync your files. Something like Syncthing would sync updated XMP files from your phone.

A typical solution would be to introduce a setting but I could also see a possibility that if someone is capable of updating XMP files with a tool, maybe they could also set a second field that could indicate to PhotoPrism whether or not the changed setting in the XMP should overrule whatever is set in PhotoPrism.

Something like this:

<rdf:Description rdf:about=""
xmlns:photoprism="http://www.photoprism.app/xmp/"
photoprism:preferXmpMetadata="True"/>

vs the default:

<rdf:Description rdf:about=""
xmlns:photoprism="http://www.photoprism.app/xmp/"
photoprism:preferXmpMetadata="False"/>

This makes the flag per-file and allows "power users" to customize the behavior individually.

[graciousgrey]

I could also see a possibility that if someone is capable of updating XMP files with a tool, maybe they could also set a second field that could indicate to PhotoPrism whether or not the changed setting in the XMP should overrule whatever is set in PhotoPrism.

We appreciate your feedback!

If we add a setting, I think a setting in PhotoPrism that applies to all xmp files makes more sense. As far as I know, most people don't edit xmp files manually, but use tools (Digikam for example) that write to xmp. These tools don't write PhotoPrism-specific tags, and adding tags manually would make the workflow more complicated. Also, I assume that people's workflows in this regard are more or less the same for all their files.
What do you think?

We'll think some more about possible settings and get back to you after our vacation.

[lastzero]

@akirk I'm going to merge this PR and hope that it will make PhotoPrism more usable for you. We probably need to rework the implementation in a future release when we add full XMP support. Unfortunately, the current XML standard lib that comes with Go is not sophisticated enough for our needs, so we have to find an alternative first.