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

[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.

[anderstn]

Added a response just now for the tags I would like to see. Suggested a similar feature to what you are asking for in the comment section of my own response as I consider it a prerequisite that something like this is implemented if they ever add support fro writing EXIF tags. Otherwise existing users would be left with a bunch of data in a database or sidecar files for older images while the newer once would be automatically updated. I guess you could go through each file and just trigger the application to store tags again, but that would probably take a lot of time :(

PS: What are you and other users using currently to support tagging? Feel free to reply with a direct message if that's possible here on Github.

[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

[anderstn]

I feel like the only issue here is your backup size (including the amount of data moved per backup by rsync or whatever backup tool you use). And even then it's really only a big problem for incremental backups. And if you rely on running them for any length of time you need to reevaluate your backup strategy. There is a reason big companies at a minimum do a full backup monthly and ideally more often that that. Sifting through the history with long incremental backups is painful. It does ironically not help a lot if the images and tags are separated as you may need to look at two different backups to get the correct version of the image and the corresponding tag file.

[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.

[anderstn]

Hi

I'm coming at this from perhaps a different perspective than an avid/professional photographer. I'm looking to organize my personal and family photos. I have a mixed bag of image sources here ranging from scanned negatives, old digital compact camera files with limited EXIF tagging and pictures taken by various phones. I have at various points in time started to organize things in folders so I expect to have a few duplicates in there, but assuming they are few and far between I have 20 000+ images to organize and tag properly.

While I don't expect more advanced meta data to be store locally on each file storing some basic information like:

• Title
• Description
• Date taken (Very useful to set for negatives where it's occasionally burned into the film or found through clues in the image itself. if there is a specific tag for year taken that may be even better seeing as these dates are often a best guess)
• Location (either fixed with GPS or just a name like "Loch Ness" or something similar)
• People in the photograph (I'm not sure if there is a good EXIF tag available for writing who is in the picture, but if not I would like to throw it in there somewhere. Maybe we could append it to the description? I would be fine with details like where in the picture a given person is located not being written to the file due to tag limitations. I just want the information to be there if I ever share the file with someone not using this software or having access to a piece of software that can read sidecar files)

Any tagging beyond this I don't really expect to survive a change from photoprism to something else as we are then entering the realm of tags centered around album compositions more so than pure image tags in my mind. These will always be personal and I don't think it makes much sense if they are present when the images are shared or seen in a different context.

[anderstn]

Slightly off topic, but if I do end up using photoprism and you implement this at a later point it would be nice to have a button to just update all applicable image tags with information stored in the database or sidecar files.

I would offer two modes to write tags. A destructive mode were conflicts are resolved by writing the tag information from photoprism over any tag already present in the file or a non-destructive mode where files with conflicts are left alone and logged. Then people can check if the tag data in the file has any value, update phototropism accordingly and run the destructive write operation again.

[THF-Mediapics]

Unfortunately, the issue is not quite so simple. A simple script to write back changed metadata fails to write changed metadata from the MariaDB database, which is used by PhotoPrism, back to the original image files. A Python script was to be used to retrieve the metadata and write it to the files using ExifTool.

Main reason for failure:

When trying to run the Python script, the following error message occurs:

Error connecting to database: 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'

This error message indicates that the collation utf8mb4_0900_ai_ci is not supported by the current MariaDB version. Collations determine how characters are compared and sorted in the database. The collation utf8mb4_0900_ai_ci is typically available in MySQL 8, but not in older MariaDB versions.

[lastzero]

Is there a reason why your script (or the library you use) does not choose the database defaults or alternatively the same charset (utf8mb4) and collation (utf8mb4_unicode_ci) as PhotoPrism (unless you have changed it there too)?

photoprism/internal/config/config_db.go

Line 75 in 8204150

"%s:%s@%s/%s?charset=utf8mb4,utf8&collation=utf8mb4_unicode_ci&parseTime=true&timeout=%ds",

[JiCiT]

No, no good reason. The script is something I hacked together very quickly for my own use. That is to say, I didn't even consider delving into the details to that depth once it'd served it's purposes well enough for me.

I doubt I'll have the time to make these changes to correct this oversight within the foreseeable future. However, I'd graciously accept a PR to do so from anyone willing to submit one.

[Tirallala]

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

1. Date and Time the picture was taken
2. GPS/Location

Do you know whether the tool, you want to open the files with, does read this exif tags as well?
I'm "just" changing from PhotoPrism without MariaDB to PhotoPrism with MariaDB and cannot get the provided restore backup/migrating instructions to work. So both source and target is PhotoPrism

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

[THF-Mediapics]

Changed metadata is currently not written back to the original file. I change/complete the metadata for my photos. After saving, I download the image and view the metadata in a separate program (e.g. Adobe Brigde / Photomechanics). Unfortunately, Photprism does not write the metadata back to the JPG file. When can we expect this to be implemented?

[graciousgrey]

Unfortunately, we can't tell you when we'll get to it yet. The next topics our team will be working on are AI enhancements, multi-library support and batch editing.

[rolandwilden]

First of all, thank you for your work on this great piece of software :-)

I would really appreciate the feature discussed here.

Which exif tags (that exiftool can write) are important to you?
Date/Time + Keywords + Title + Description + Event + Face Regions / PersonInImage + Geo Tags + Categories

Maybe it would be an idea to use an XML/JSON/YAML configuration file with this table structure (e.g. like https://daminion.net/files/daminion-metadata-mapping-rules.pdf) incl. an 'ignore on read' & 'ignore on write option'. This way admins should also be able to add new fields themselves if the EXIF tool supports them.

Do you know if the tool you want to open the files with can read these Exif tags?
Yes, we use Lightroom, ACDSee and XNView MP for tagging and a Nextcloud to store the data. Both are connected via WebDav.

Should existing information be overwritten or should PhotoPrism only write if the field is empty?
Should be configured via options and/or in the GUI (overwrite true/false), alternatively a warning should be issued (specifying the specific field).

Writing back either to the original file or to an XMP sidecar should also be an option (I prefer the original file). The information should be written immediately or perhaps with a short delay to allow for various changes in a single file.

I can offer some support here from the perspective of manual testing (I am not a programmer, but an IT administrator)

[THF-Mediapics]

For me it would be important that the changed metadata that I add/change/delete via Photoprism is written back and is immediately available. The data should therefore be available directly in the original file, so that a user who downloads the JPG file can already read this information, e.g. via Photomechnics or similar.

The fields date/time + keywords + title + description + event + facial regions / person in the image + geo-tags + categories, caption are important for this.

Photoprism should write regardless of whether the field is empty or not.

[pseudocoder]

Writing EXIF to the original file should definitely be an option, it's the only way to guarantee that metadata is portable and can't be lost. But this would have implications for backing up these large files (particularly when the long awaited batch update option appears :-) ), and could risk losing existing metadata. So I'd suggest:

• it is configurable whether this happens or not
• can also be done via a batch command on request / schedule (e.g. I would do it before a full backup, to avoid blowing up incremental backups which anyway pick up the sidecars)
• overwritten metadata is written to a sidecar with the datetime in the filename