Write metadata back to originals

[graciousgrey]

PhotoPrism does not (yet) write metadata back to original files.

We guess that doing so (optionally) would provide benefits for many users, because they want the information they added in PhotoPrism to be available in other tools as well.

In a first step we could use exiftool (https://exiftool.org/) to write back metadata to original files.

A few questions open for discussion:

• What exif tags (that exiftool is capable of writing) are important to you?
• Do you know whether the tool, you want to open the files with, does read this exif tags as well?
• Should existing information be overwritten or should PhotoPrism only write if the field is empty?

[kvalev]

For me the most important information are date and time when the photo/video was taken and the location.

I have a bunch of photos that are missing GPS data, so from my point of view it would be amazing if there was a convenient way to edit this type of information. Convenient in my case means that there is a map that I can zoom in/out and that I can search. For example, if I know that a photo was taken in Yosemite National Park in the US, I should be able to search for Yosemite, jump in there and then fine-tune the exact location. A more extreme use case would be to also provide street-view for the map (dont know if mapbox has something similar) to be able to really pin-point the photo location.

Another very helpful feature when adding location data would be to suggest the location based on photos/videos taken at similar time. For example I have taken a picture of the same thing both with my phone and with my camera, but the camera picture does not have location data. In this case it would be nice, if the location is suggested based on the closest (time-wise) available data.

[graciousgrey]

@kvalev for this we already have a related ticket #465.
This discussion is more about how to write metadata set in PhotoPrism back to the files exif data :)

[streiman]

For me it is

Keywords (iptc:keywords in exiftool)
Description &
Title

It would be great to have the information synchronized, so when it is changed outside of Photoprism like adding a keyword, it is added to Photoprism as well.

[fratzzz]

And vice versa: If changes are made in Photoprism, this should be saved directly to the file - so that the metadata is available when the file is shared, for example.

Try to answer your questions:

• I mainly work on Windows and have been using "photools IMatch" for years now. As for the metadata, IMatch also uses exiftool.
• I had a quick look: When the metadata is updated, Date/Time of the file is not changed, only the tag name: "Modify Date".
• For now I am using the follwoing tag names: Title, Description, Keywords, Person In Image. Every now and then I have to adjust GPS coordinates as well. And occasionally also "Date/Time Original"
• Quite important – but rather for the future – seems the "Region" tag names (like Region Area, Region Type, Region Name, ... etc) used for face detection, recognition and annotation.
• Existing information should be overwritten, if changed if changed manually in Photoprism. Photoprism could write automatically generated information (such as title, keywords) to empty fields.

[bnounours]

Hi,

I use Shotwell for years now and several tags are used, here is an example :

+ [XMP directory, 3576 bytes]
  | XMPToolkit = XMP Core 4.4.0-Exiv2
  | Warning = [minor] Fixed incorrect URI for xmlns:MicrosoftPhoto
  | Label = Saint Petersbourg
  | Subject = District de L'amiraut..
  | Subject = Europe
  | Subject = Lieux
  | Subject = Mus..e de l'Ermitage
  | Subject = Russie
  | Subject = Saint Petersbourg
  | TagsList = Lieux
  | TagsList = Lieux/Europe
  | TagsList = Lieux/Europe/Russie
  | TagsList = Lieux/Europe/Russie/Saint Petersbourg
  | TagsList = Lieux/Europe/Russie/Saint Petersbourg/District de L'amiraut..
  | TagsList = Lieux/Europe/Russie/Saint Petersbourg/District de L'amiraut../Mus..e de [snip]
  | LastKeywordXMP = Lieux
  | LastKeywordXMP = Lieux/Europe
  | LastKeywordXMP = Lieux/Europe/Russie
  | LastKeywordXMP = Lieux/Europe/Russie/Saint Petersbourg
  | LastKeywordXMP = Lieux/Europe/Russie/Saint Petersbourg/District de L'amiraut..
  | LastKeywordXMP = Lieux/Europe/Russie/Saint Petersbourg/District de L'amiraut../Mus.[snip]

JPEG APP13 (158 bytes):
  + [Photoshop directory, 144 bytes]
  | IPTCData (SubDirectory) -->
  | + [IPTC directory, 131 bytes]
  | | CurrentIPTCDigest = ..5c.3.e}.l.... 
  | | -- IPTCApplication record --
  | | OriginatingProgram = Shotwell
  | | ProgramVersion = 0.26.4
  | | Keywords = District de L'amiraut....
  | | Keywords = Europe
  | | Keywords = Lieux
  | | Keywords = Mus....e de l'Ermitage
  | | Keywords = Russie
  | | Keywords = Saint Petersbourg

[tootbrute]

• What exif tags (that exiftool is capable of writing) are important to you?

Importance for me: 1st date/time, 2nd GPS/location (even a fuzzy approx location is OK), 3rd tags

• Do you know whether the tool, you want to open the files with, does read this exif tags as well?

Don't use any other photo tools at the moment.

• Should existing information be overwritten or should PhotoPrism only write if the field is empty?

Should warn us if it is overwriting data.

[TimoJohn]

Well said from every one.
In my opinion wrtiting metadata back to the files is an essential very helpful function in the current days.
You start tagging your photos at the PC unsing DigiKam in my case an finish the las ones on the sofa using photoprism. Would be amazing.

• You are safe for future tool
• you have information available if you share copys

Pls think big in this approach, there are so many great ideas that can come up.
Saving "Hears" / Linkes of specifc user in the tags ... Future Ratings engine and so on.
Woul be really helpful to have it written into the Files themselves.

For me Kewords stores in IPTC would be the best.
Manual written Keyword and also the AI computed.

Best Timo

[fratzzz]

What are the chances that this will be included in one of the upcoming releases? I'm ready to contribute as a sponsor, is there an issue for this?

[graciousgrey]

We have some other big topics with higher priority to do first (face recognition, batch edit, user management). So it will take a while until we come to this feature. Writing back to metadata requires very good planning. That's why we created this discussion first to collect input from the community. Once we have time to think about this topic in more detail and find a good concept to start with together we will create an issue for it.

[DustyTools]

I just discovered PhotoPrism, very excited to try this out. I wrote a library called Fotofly way back and use it today to manage my photos. As a result, I am quite particular about ensuring the truth is in the file. But now I have two kids I want to use an app that advances!

In terms of write back, a small step would be to write a side car Json file with changes. It would be very easy to then write a simple app to merge the changes back in. For me these are the most critical:

• keywords
• GPS location shown and location created
• Address for shown and created
• People

[dominikholler]

No doubts that this would be a useful feature. One thing I really appreciate about photoprism is that for many things you do not have to wait until photoprism implements it, because the REST API of the photoprism backend is quite helpful. For this reason, this missing feature might not prevent you from using photoprism, if you are able extract the related information from the REST API and write it back to the files using your own software.

[DustyTools]

Oh, well that works for me! I have installed on my Synology and am looking forward to trying it out :)

[dominikholler]

In case it might speed up learning how the API is used, you can get some inspiration from https://github.com/dominikholler/photoprism-python-sdk . I also recommend the network monitor of in the developer tools of the internet browser, which shows how the photoprism frontend is using the API.

[sufehmi]

I was about to create my own photo album software, because I need to be able to have photo's description to be stored in exif metadata so it'll continue to exist wherever I moved the photo (I'm planning to have my family photos to be still digitally available decades later) - than I found Photoprism AND this discussion.

1. What exif tags (that exiftool is capable of writing) are important to you? timestamp, description, keywords, GPS, people's name (probably as keyword?)

2. Do you know whether the tool, you want to open the files with, does read this exif tags as well? They should, it's exif metadata

3. Should existing information be overwritten or should PhotoPrism only write if the field is empty? Please overwrite, am planning to make Photoprism as my main photo management software.

Thank you for this discussion.

[shaun-blake]

This is the number one feature I'd like to see. For me, the best would be to keep it simple. Anything you can do to a photo through Photoprism should be mapped back to the photo tags using the most widely supported tags. I don't want to have the mental overhead of remembering which things I do in Photoprism will go with me if I move to a different manager and which won't.

I think the main purpose of the discussion is probably trying to figure out which of the corresponding tags are the most standard or widely supported.

I don't know the specific tags are, but I'd like to be able to see title/description/tags I add through Photoprism in Microsoft products (their photo manager and file explorer) as well as Digikam.

[rishid]

Just to add a few points to the discussion:

• I agree focus on the common tags that are universal in most apps
• Write back to original file or XMP sidecar should be an option
• I built a personal photo organization tool and I use XMP-xmpDM:Album and XMP-iptcExt:Event for things like "John and Jane's wedding" and then for sub events, I would optionally set the Headline tag, e.g. "Wedding" or "Reception".
• I use these tags to auto organize my files into YYYY\MM - {Event}\{Headline}. This allows for me to be completely agnostic of any photo browsing program. As I fully expect directories and files will stick exist 50 years from now.
• This has been great for now but I just can't keep up with organizing my files and would love for Photoprism to assist with auto-organization and write some tags back
• Digital family photos last for decades, we can't expect Photoprism to be around 50 years from now (it would be great if it was!) so writing the data directly to the image is super critical to me.

[rubenalamina]

I'm a bit late to the discussion but just started looking into photoprism as my management tool. Besides what others have said on this thread, it's critical to have portability and the way to ensure that is to write metadata to the files if one chooses to. If a files changes outside, it should be reflected next time photoprism scans them. This ensures that the metadata is always on the file and reflected both inside and outside of photoprism. I don't have any different use case so I just uses the standard tags: keywords, title, subject, gps fields, date/time taken/modified/scanned.

One important thing I'd like to mention for when the feature to write metadata is implement, that I think this is very important besides offering the option to write or not in the settings is: never default to writing photoprism's automatically generated data. Leave it to the user to manage how to handle this.

One example I can think of and that is very clear and simple. OneDrive automatically adds keyword tags for all files it scans but never never writes it unless you manually edit the keywords on a particular file or set of files and input the ones you want. So say one photo has 3 tags suggested like #sunset, #outdoors and #beach. You can go and edit the tags and the three will be shown. You delete #outdoors and type manually and hit save. Outdoors will be written to the file and shown in a different shade of color in the tags field, indicating that is being read or was written to the file.

This would be ideal to handle photoprism generated tags.

[hjed]

Bit late as well but starting to evaluate photoprism as a long term alternative to Google Photos (since the later is increasingly moving away from what I want in photo management software).
I've moved software a few times (picasa -> Microsoft Live Photos -> Digikam -> Google Photos) and really don't want to go through the tagging/face recognition step again.

So key tags for me would be:

• Tags as IPCT Keywords and Exif | Windows Keywords
• Date & Time
• GPS Location Data in Exif
• XMP Facetags compatible with what digikam uses (https://bugs.kde.org/show_bug.cgi?id=277429)
• Caption

[hjed]

I'd challenge that its anymore complex then writing to a db in terms of concurency, etc. So long as the db and the file are in sync I think that would work. Google doesn't do it because Google doesn't want photos to be portable. I'm a dev so when I have some free time I might look into this (I have been working on reading XMP from photos but ran into some issues with your testing framework). I'm wary of trying to contribute such a big change without the philosophy being resolved first though. I've also considered upgrading my sponsorship to sponsor this feature but I haven't convinced myself to fully switch to photoprism yet and its already costing me much more than google photos (when you add in doing cloud backups, etc)

For me sidecars are painful, most people aren't familiar with them so its hard to share the files and not all applications support them (whereas they all support non sidecar versions of the files). I think this is something you'd need to be turn on/off. That's what digikam does, they had similar discussions on metadata being written back a few years ago IIRC.

[sufehmi]

1/ Only admin can write into metadata / Exif

2/ Others can not write into metadata - but they can write comments (then admin may edit metadata based on those comments)

[Webreaper]

While it seems easy and straight forward to overwrite metadata in fully standards compliant JPEGs on a local desktop computer (which is what operating systems and consumer photo apps may support), it gets a lot more complex and error prone on distributed, multi user apps where users (like a family) might share the same originals to save storage, when it comes to subtly broken/invalid files, and/or formats other than JPEG and Exif (check how many title and description fields XMP supports).

I think if PhotoPrism subcontracts the EXIF writing out to a known tool, then the mechanics of writing the metadata should become pretty simple from an implementation perspective. For Damselfly, I just use ExifTool to do all of the writing of the tags (there's no way I was going to try and implement the myriad of standards myself, and/or risk a bad implementation trashing somebody's photos).

As you say, the harder part is to manage the workflow part - i.e., what do you do if two users apply tags to the same photo at the same time? I went for the super-simple approach, which is that for keywords I just merge added keywords to the photo's existing set, so there's minimum scope for data loss. For other fields such as caption/description etc., it's reasonable to just pick "last modifier wins"; whilst you might very occasionally get an instance of two users updating a caption at the same time, and one losing their changes, in reality I don't think this is very likely and it will be entirely obvious as to what's happened (assuming your users are in the same family, and so talk to each other...).

The biggest challenge is to support the myriad of tag standards (e.g., even something as simple as image width/height can be stored across 4 different EXIF directories, dependent on the photo's source OEM). But that's less of an issue for writing than reading - just pick the most common and write there. Face-detection tags are also tricky because there's no real certified standard for writing them. In the end, I elected to go for whatever tags Photoshop and Digikam write, which probably covers the majority of broad use-cases. For other more niche systems that pull the tags from elsewhere, people can use ExifTool scripts to manually copy the data from one set of EXIF fields to another.

The reason Google doesn't support it is not cause they can't do it, but because they don't want to do it. They don't want to make it easy for people to leave their system.

This is spot-on. The fact that even after, what, 10+ years of Google Photos they still don't support searching by EXIF/IPTC keywords indicates that Google aren't interested in textual search/indexing of photos. I've never understood why, but they obviously don't use their product to actually find photos that often!!

[rhatguy]

Mark this is an excellent well thought out reply. While I agree there aren't real certified standards for a lot of the metadata, there does seem to be a "coalition" forming around certain types. As you mentioned Digikam, Photoshop, and exiftool are big ones which seem to be fairly universally supported by most tools in the open source and mostly commercial community which support reading metadata. The ones that don't support those standards you usually find some other motive like locking people into their toolset.

I'm also a firm believer in leveraging the other giants in the industry for things you aren't good at yet. Photoprisms core strength is not to change metadata inside photos and as soon as you open the can of worms around modifying photos you have an entirely different set of problems to work out. Good news though, there is an entire project (exiftool) dedicated to just that. I feel it would be very hard to argue if someone chose to just support the metadata formats that exiftool supports. Sure there will always be someone who wants to use windows live photo gallery's metadata format, but I suspect that for a large percentage of people exiftool supports more than they will need.

My encouragement would be that the only way to eat an elephant is one bite at a time. Pick something simple like reading and then ADDING (not removing) keywords from photos. Work out the workflow for that. Then move onto harder things like face tagging, where a super beneficial first step would be reading existing tags (like those produced by digikam). Once you start writing and overwriting metadata, if you absolutely want to handle multi user updates you could implement some locking inside the DB so only one person can edit at a time, but I think Mark's approach of last update wins is a VERY valid way for a project like this to handle those cases.

[Webreaper]

The other thing I do in Damselfly to manage the potential for conflicting or concurrent updates is that I don't write the data synchronously. So when a user adds/removes or updates a keyword, comment or rating in Damselfly, that change is put into a queue in the DB - effectively a trans-log. Then after a short delay, the updates are processed to conflate them into a distinct set of changes to apply them to the image with a single exiftool execution. This has several benefits:

• If a user adds several keywords one-by-one, they still only get written in a single update
• If a user removes a keyword and replaces it (e.g., to fix a typo) they get written in a single update
• If a user adds keywords, a rating and a caption, those are conflated to a single update
• If two users are concurrently keyword-tagging images, and both tag the same image at the same time, the delta is calculated and only the actual single change is applied.

This means that many of the file-locking and concurrency issues are resolved, because it's Damselfly that determines when ExifTool will write the changes to the image file, not the user's actions. It also reduces the overall number of writes to the image file, on the basis that there is an inherent risk of corruption every time the image file is written, so we want to do that as infrequently as possible (I certainly don't want to re-write the image file 10 times if a user adds 10 keywords). And lastly, the trans-log in the DB means that it's easy to check which user made which changes, which can be useful occasionally ("John, why did you tag that photo 'cat' when it's a 'dog'?" 😁).

I'd be happy for PhotoPrism to copy/borrow this translog workflow/concept/implementation when @lastzero and the team implement exif updates, as we're not really competitors. Anything that brings more options and flexibility to the photo management self-hosting world is a good think IMO. 😁

[N20Visuals]

probably very late to the party, but since i'm registered now i thought i'd share my two cents:

My personal No. 1 priority would be writing back GPS Coordinates to the files since sometimes they don't get any tags when the phones gps is just not good enough. Everything else would be just an added bonus for me.

[Bugsbane]

I use Digikam for local photo management and Nextcloud so my family can access our photos. I'd like to add Photoprism to the mix, so our photos can be automatically tagged. Preferred main tags to use are very similar to @hjed above:

1. Tags (most importantly specific people's and places names) as IPTC and Exif keywords
2. Date modified (don't change date taken)
3. GPS location
4. Digikam compatible XMP facetags

Currently Nextcloud doesn't read IPTC or Exif tags, but there's a patch submitted in review to make it do so. Another alternative would be a simple Nextcloud app that turns IMPTC / Exif keywords to Nextcloud tags on import / sync.

[swawif]

As someone that has been spoilt by Google photos, I've came up to expect these information to be available with my photo

• Photo taken date
• location (coordinate)
• location (searchable, human readable description (eg: City, POI, etc (Tokyo, Eiffel tower, Kuta Beach, etc))
• Names of people in the photo

I think these would be enough for most people. But as I don't know the technicalities, I don't know if all of these data would be possible to include on EXIF

Cheers 😀

[scrapix]

• Artist
• Creator
• Comment
• Subject
• Tags
• DateTimeCreated
• CreateDate
• DateCreated
• TimeCreated
• FileName
• Make
• Model
• GPSPosition
• GPSAltitude
• GPSLongitudeRef
• GPSLatitudeRef
• GPSAltitudeRef

[dinoschachten]

I am very excited to see this is being discussed. Are there any news regarding this feature?

I am currently using DigiKam, but would like to switch to a more flexible solution, especially one that does not depend as much on setting preferences on each client - thus a browser-based solution like PhotoPrism sounds great to me.

I would argue that objectively the metadata that is most crucial to write to the original file is creator/copyright and usage information.

I would be very happy to write title, description and geo data to my files as well, but info about the source is by far the most important when files are shared with others. All other metadata are of archival interest and thus okay to "only" keep in the archive, while creator info is a legal obligation (at least in professional environments) that should be attached as closely as possible to the file itself.

[graciousgrey]

Are there any news regarding this feature?

No news. Once we find time to work on this we will discuss a final concept here. Until then we collect input in this discussion :)

Our roadmap shows what's currently in progress: https://github.com/photoprism/photoprism/projects/5

Here's described why we can't give deadlines for features: https://docs.photoprism.app/user-guide/faq/#general

[dinoschachten]

Let me just say that all the work you do is greatly appreciated. You guys are absurdly busy and active! Thanks for getting back :)

[nautatva]

Another important but neglected flag is ratings. Windows sorts 4 or above (5) stars as a favorite.

[jmalm]

This is exactly what I was going to add. I'm looking for a more flexible way of culling my photos, one that doesn't require me to be at one and the same computer to do it. (For a description of my current workflow, and some desired changes, see https://gist.github.com/jmalm/4ed9458783e19801af1198f261e8290a.)

My primary photo management software is Capture One Pro, which is able to read/write ratings (and probably other metadata) from/to XMP sidecar files named .xmp.

I did some work on Librephotos so that it writes "favorites"/"likes" to XMP sidecar files as a rating (user configured, defaults to 3) last summer. It also reads rating from the image or XMP sidecar. (I didn't know then that Windows had a default of 4.)

Photoprism feels like a very competent and well-built software. I may be able to find some time to do a concept implementation of this.

[graciousgrey]

We don't read ratings from xmp or other sources as we don't have them implemented yet: #713. For many people ratings have a different meaning than favorite. Is there another field in xmp we could use for the favorite status or are most apps using ratings for this? If not I guess we would need another config option for this.

[graciousgrey]

@jmalm I move this to the discussion so that the issue can be used for final acceptance criteria once we have concept.

I can think of the following complexities:

• Mapping each Photoprism-internal metadata field to one (or more?) fields when writing metadata to file (image or XMP sidecar). (By this I don't mean that every Photoprism-internal metadata field necessarily has to be written each time a field is written to file.)
• Mapping metadata to populate specific Photoprism-internal metadata fields when reading image or XMP sidecar. (Could be several candidate fields in the image or XMP sidecar for one Photoprism-internal metadata field.)
• Making sure not to loose or mess up existing metadata in image or XMP sidecar when updating image or XMP sidecar
• Possibly: synchronization issues / conflicts
  Are there other things that make this a complex matter?

I don't really see synchronization conflicts as being a Photoprism concern, but I may not have enough respect for the complexity of synchronization. In my mind, whenever a file is read by Photoprism, it would overwrite any corresponding internal metadata with metadata found in the file being read, and conversely, whenever Photoprism-internal metadata is written to a file, it would replace any mapped field in the destination file. The question of when to read and write might be another complexity here, but could perhaps be completely separated?

(By the way, is the Photoprism-internal metadata all found in the Photo struct, with sub types (i.e. Details, Camera, etc.)?)

PhotoPrism is already reading a lot metadata, you can find the mapping here: https://docs.photoprism.app/user-guide/advanced/metadata/#supported-exiftool-xmp-tags

[jmalm]

Yes, I found it after writing this. Super!

[Yannovitch]

Hello,
I second this idea/feature/issue very strongly, that's the only thing keeping me from using photoprism.
Can I maybe sponsor this specific feature somehow ?

[graciousgrey]

Can I maybe sponsor this specific feature somehow ?

Completing the work on multi-user support and merging existing pull requests is our top priority at the moment. Unfortunately, we do not have additional capacity to work on other tasks. In order for us to change this and grow our team, getting sustained support is very important.

Generally speaking, a donation large enough to pay a freelance developer could help. However, you have to keep in mind that this will not cover ongoing maintenance and testing in the months and years ahead. In addition, even a good developer will need some of our time to get started, then regular feedback on implementation details, and finally help with testing.

That being said: If you are willing and able to help with a large enough donation, we would be happy to get back to you as soon as we are in a position to get things started.

[Yannovitch]

Any news about this feature 😃?

[lastzero]

Who are you asking? We just pushed more than 10,000 lines of code and merged 4 pull requests. It doesn't get any faster than that.

[fdelucchijr]

Who are you asking? We just pushed more than 10,000 lines of code and merged 4 pull requests. It doesn't get any faster than that.

I don’t know if @Yannovitch is trying to push timelines or only wanting an update of when will be the time for this feature to be implemented.

@lastzero , by me take your time, you already pushed more than 1 Million lines of code since 04/2019. I think lines isn’t a measure, but as a fellow programmer I feel impressed of your advance and how the project keeps growing. Keep up the good work!

[Yannovitch]

I wasn't implying things don't go fast enough or anything, i was just asking genuinely if you had any news about this feature. I feel impressed too by this project which "feel" very professional. All the best to you folks =)

[gitconsumer]

This feature is definitely a must have. I was quite shocked that changing metadata does not write it to the actual image file. I can't edit anything because the blueprint should always be the actual folder and file structure of the originals and not photprism's database. Definitely looking forward to tag's update.

[lastzero]

Note that data is also automatically exported to human-readable YAML sidecar files:

https://docs.photoprism.app/user-guide/backups/export/

[schnidrig]

not quite sure how that helps me. I could not find any software that know what to do with those yaml files.

[Bessie]

I'm also a DigiKam user and battle-hardened with the whole picasa -> Microsoft Live Photos mare. I hate investing a whole bunch of time getting the photographs to look nice only for my hard work to disappear when the tool reaches end of life. The YAML file is great, but is not the most widely interoperable and that's what I actually care about most -> the metadata that the tool of the future will most likely be able to read.

I also might like to move back and forth between applications since some are better at doing certain jobs than others. For instance, PhotoPrism is great at displaying pictures, but DigiKam is much more powerful for curation and adding missing information.

The information that I'd most like to collect and keep about the pictures is:

• Created date (usually, I don't want to mess with this, but if I have scans of old photos they won't display nicely if a timeline function is using this for the ordering)
• modified date (I like to know whether the picture has been changed after it was taken)
• GPS (so the software can pin it on the map for me)
• human-readable location information (because sometimes this is just a much more sensible way of grouping pictures - I could look at all the pictures I've taken in London or Paris for instance, or England in general, or sometimes a particular suburb)
• Info about what's in the picture (So they can be grouped and/or found by what's in them)
  - Names of the people in the picture (I also quite like the feature that allows me to hover over an individual and have their name come up)
  - Categories that describe the pictures (like Architecture:Skytower or Landscape or Animal:Bird:Duck)

Fundamentally, I don't actually care how the information is stored, I care about how easy it is for other programs to read the metadata I've invested all that time curating.

Since ExifTool is so flexible and powerful I could use that myself to get the info I care about from one file to the next so if it's just too hard to implement functionality to do this then what I need to do it myself is crystal clear documentation about what needs to be written where so that PhotoPrism can read it.
For instance, my questions would be:

• Where/ how should face information be written so that PhotoPrisim can read it?
• Where/ how could I write information that would update PhotoPrism labels? (which are more important to me in PhotoPrism than keywords since they are what actually support the ability to browse for groups of the same thing)

[artincube]

it is about exitfool tags... so one most obvious
-orientation tag

[lastzero]

PhotoPrism already writes the orientation tag.

[artincube]

Does it? I was not aware originals were modified. I thought all input in Photoprism was in the yml file. What other metadata or other things are allowed to be written at present?

…

On Jul 10, 2023, at 1:00 AM, Michael Mayer ***@***.***> wrote: PhotoPrism already writes the orientation tag. — Reply to this email directly, view it on GitHub <#1092 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQLN2RUUSJ4TWB7ASRV4CK3XPOZAZANCNFSM4YCUK3PA>. You are receiving this because you commented.

[lastzero]

Just the orientation for now as there is no need to preserve the existing orientation if it was wrong. That's different for most other metadata.

[graciousgrey]

See also: https://docs.photoprism.app/getting-started/faq/#in-which-cases-could-files-in-the-originals-folder-get-modified :)

[artincube]

So it does it at the moment one click on an orientation button on the files section of a stack?Mirror could added to the 4 possible orientations.On Jul 10, 2023, at 9:03 AM, Michael Mayer ***@***.***> wrote: Just the orientation for now as there is no need to preserve the existing orientation if it was wrong. That's different for most other metadata. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[lastzero]

There's a dropdown for this in the files tab. And yes, it does what it is supposed to do.

[Wordsmith9091]

I poke my head in here once in a while, because this is really the only feature omission that keeps me from using photoprism.

A few suggestions I'd have for implementation:
By default, write metadata changes only to the database and json sidecars, as happens now. Have a flag in the database and indication in the UI for photos that have data modified in Photoprism. Allow the user to update the exif as a batch, with warnings first that they're writing to the original files and this can't be undone. Potentially hide this away in an advanced section.

Also, during any export/download, give the user the option or writing updated metadata to the files (yet still not the originals in the storage being referenced by photoprism), on by default but possible to turn off.

That way, any updates made in PP would be reflected when the images are later used elsewhere (say, providing one to a third party or opening it in Photoshop) without affecting the originals except in cases where the user really understands what they're doing.

[subroutineox]

Same for me - cant use this nice tool because of this -only- missing feature :(

[lastzero]

Any help with implementing this is most welcome!

Kindly note, though, that we are currently working on additional authentication options such as 2FA, OAuth and OIDC, because many users are also waiting for these. Once that is done, we can work on other issues.

This year so far:

• we developed a free, high-resolution vector world map that is now available to all users
• released major improvements to user and session management
• took care of a long list of pull requests that were waiting to get merged, e.g. the Places cluster view that many users had been waiting for
• provided installation packages for Linux as an alternative to our Docker images
• continued to improve our documentation for you
• and fixed virtually all other issues that users reported to us

[poggenpower]

I know two tools writing metadata back to the image. Digikam running this in a background job, but as it is a Desktop app such jobs are far better to control as within a wbe app. Picapport is also a web app, this app is blocking interactions while writing the metadata which cloud be really annoying especially if you tag hundreds of photos at once. And it will run for each change separately.
If I do metadata edits e.g. for photos from a vacation this would be an itterative process. Some tags are written to all fotos some per day some per event and some on specific fotos. So over time one Foto receives several tags. If for each Tag the is a sync triggered, this cause a lot of overhead and makes picapport almost unusable for this approach, digikam seems to start a sync job with the first change made. As such tasks take time it is intelligent enought to sync all metadata changes made since the start when it works on an item from the queue. This seems to work good. As photo prism is a server app it may be sufficient to simply run this at night when a desktop app like digikam is not running anymore as it is closed. On the other hand I know some users shutting down their NAS at night to save energy costs and if photo prism runs there it may miss the time slot for sync every time.
Not sure if this descriptions are helpful but you may be you check those both apps and how they have implemented this

[Webreaper]

I know two tools writing metadata back to the image

You know 3 now - see my comments elsewhere in this thread, and my repo. Worth noting that there's nothing stopping you running Damselfly and Photoprism alongside each other on the same library, and using Damselfly for tagging.

On the subject of backup, I'm not sure it's really an issue. We tend to import the images into On1, tag them there (they're written to a sidecar) and then copy across to the NAS where Damselfly indexes them and if there are any tags in the On1 sidecar, that aren't in the exif data, it writes them. So generally the tags are there by the time my weekly B2 backup runs. And if I retag some pics and they get backed up again, then yes, an extra version will be backed up (I use Rclone and B2 with 3 versions) but when you're talking about a few hundred or even thousand pictures backed up with multiple versions it pales into insignificance against the 4.5TB of the entire backup (we have around 650k photos). It's probably a few pence per month.

[patrontheo]

Hey,
Thanks for the work guys.
This would be a really important feature for me too.

For me, the tags of interest would be timestamps and gps coordinates.
I don't know if possible, but a tag giving the album(s) the photo/video belongs to would also be of interest for me :)
Thanks

[Tilmann-Glaeser]

Hi!
Writing metadata back to the originall file will impact the backup system and therefore should be optional. Reason: Any change in the metadata would change the size and the fingerprint and maybe the timestamp of the file as well. This will tell the backup system to store a new file on the backup system (e.g. if rsync is used). If you keep only one backup then it wouldn't be a big issue, but if you keep multiple generations then it matters. If the metadata change is in the sidecar only, then the backup size is much smaller and you are reducing the backup time and costs as well!

I have to admit that it is not so easy as I thougt and please have a look at my comment in issue 713

[Wordsmith9091]

I definitely agree it should be optional. And I think it should come with warnings that it affects the original file, will be seen as a new file by backups, etc.

But I'd also like to see an option that when downloading/exporting out of the library, updated metadata reflecting what's in the database is written to the copy being provided in the export, even if the version in the underlying system is untouched.

[poggenpower]

I agree that the write back should be something that need to be activated once (opt in). But once it is enabled I don't see a reason why there should be a warning when a user is changing the data.
IMHO backup should restore the most recent state of the file. I don't want to have files without metadata after restore. I really like the concept that the photo carries all its information independently for any program. Over the years I have seen the death of many photo managers and I was happy, that I can simply use the next one simply by pointing to may photo folder.
Btw. As meta data is written in a extra segment of a file rsync is able to transfer the changed part only, not the whole picture.

A later implemented feature could be, witing metadata into a sidecar for users who want to keep their files untouched for other reasons. As sidecar files are a common standard supported by many programs.

The add metadat at export would be a nice to have, but should not be a requirement for the initial implementation too.
Just my 2 ct

[JiCiT]

FWIW, I created a perl script using the exiftool module to push data from PhotoPrism's YAML sidecar files into the EXIF of the image file. It's a bit rudimentary and addresses these EXIF:YAML combos only only: DateTimeOriginal:Year/Month/Day , GPSLatitude:Lat, GPSLongitude:Lng, and GPSAltitude:Alt.

[djjudas21]

FWIW, I created a perl script using the exiftool module to push data from PhotoPrism's YAML sidecar files into the EXIF of the image file.

Thanks @JiCiT. Think you've got an extra l at the end of your URL but I've got the script now. Just having a play

[JiCiT]

Thanks. Fixed the URL. Hope you find it useful.