{"action":"created","issue":{"url":"https://api.github.com/repos/guardian/grid/issues/1117","labels_url":"https://api.github.com/repos/guardian/grid/issues/1117/labels{/name}","comments_url":"https://api.github.com/repos/guardian/grid/issues/1117/comments","events_url":"https://api.github.com/repos/guardian/grid/issues/1117/events","html_url":"https://github.com/guardian/grid/issues/1117","id":102139203,"number":1117,"title":"Reuploading a contract photographer's photo messes up metadata","user":{"login":"paperboyo","id":6032869,"avatar_url":"https://avatars.githubusercontent.com/u/6032869?v=3","gravatar_id":"","url":"https://api.github.com/users/paperboyo","html_url":"https://github.com/paperboyo","followers_url":"https://api.github.com/users/paperboyo/followers","following_url":"https://api.github.com/users/paperboyo/following{/other_user}","gists_url":"https://api.github.com/users/paperboyo/gists{/gist_id}","starred_url":"https://api.github.com/users/paperboyo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/paperboyo/subscriptions","organizations_url":"https://api.github.com/users/paperboyo/orgs","repos_url":"https://api.github.com/users/paperboyo/repos","events_url":"https://api.github.com/users/paperboyo/events{/privacy}","received_events_url":"https://api.github.com/users/paperboyo/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":25,"created_at":"2015-08-20T13:30:40Z","updated_at":"2015-09-27T18:36:49Z","closed_at":"2015-09-24T13:12:10Z","body":"Hello,\r\n\r\nHappened with just one image, but I suspect it has something to do with the new usage rights categories (never happened to me before). If not, and if it's an outlier - apologies and, please, close.\r\n\r\nSteps:\r\n1. Download 4fb55b5c7d85075e91d3e6727024635b374bffbf for which meta reads \"By: Christopher Thomond, Credit: The Guardian\"\r\n2. Modify, so that the image is not recognised as existing (I've opened in PS, colour corrected, saved as JPG, with \"_modified\" added to the filename)\r\n3. Upload to Grid.\r\n\r\nHere is a screenshot of resulting image's metadata:\r\n![usage_rights-reupload](https://cloud.githubusercontent.com/assets/6032869/9384339/d32c768c-4747-11e5-8860-02e086ebd507.jpg)\r\n\r\nIdeally, all metadata should survive such a ride.\r\n\r\nRegards\r\nMateusz\r\n   "},"comment":{"url":"https://api.github.com/repos/guardian/grid/issues/comments/143583140","html_url":"https://github.com/guardian/grid/issues/1117#issuecomment-143583140","issue_url":"https://api.github.com/repos/guardian/grid/issues/1117","id":143583140,"user":{"login":"paperboyo","id":6032869,"avatar_url":"https://avatars.githubusercontent.com/u/6032869?v=3","gravatar_id":"","url":"https://api.github.com/users/paperboyo","html_url":"https://github.com/paperboyo","followers_url":"https://api.github.com/users/paperboyo/followers","following_url":"https://api.github.com/users/paperboyo/following{/other_user}","gists_url":"https://api.github.com/users/paperboyo/gists{/gist_id}","starred_url":"https://api.github.com/users/paperboyo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/paperboyo/subscriptions","organizations_url":"https://api.github.com/users/paperboyo/orgs","repos_url":"https://api.github.com/users/paperboyo/repos","events_url":"https://api.github.com/users/paperboyo/events{/privacy}","received_events_url":"https://api.github.com/users/paperboyo/received_events","type":"User","site_admin":false},"created_at":"2015-09-27T18:36:49Z","updated_at":"2015-09-27T18:36:49Z","body":"Hello,\r\n\r\nRelated: https://github.com/drewnoakes/metadata-extractor/issues/10; https://github.com/drewnoakes/metadata-extractor/issues/106#issuecomment-97402993\r\n\r\nMany (all)  image management apps seem to contain these maps of many>one (on read) and one>many (on write), see e.g. https://github.com/bhenne/FlickrCrawler/blob/master/Flickr05AnalyzeMetadata_new.py or http://daminion.net/files/daminion-metadata-mapping-rules.pdf or (cited earlier) http://www.controlledvocabulary.com/imagedatabases/iptc_core_mapped.pdf\r\n\r\nIPTC itself maintains such a map: https://www.iptc.org/std/photometadata/documentation/GenericGuidelines/index.htm#!Documents/fieldreferencetable.htm\r\n\r\nA simple test of creating a new image in Photoshop, filling Basic:Author field (which automatically fills IPTC:Creator) and saving it as JPG reveals the input to that one field gets saved into multiple fields in different parts of the file’s metadata (the one that we read being the least safe as it gets truncated), exiftool output:\r\n\r\n```\r\n---- EXIF ----\r\nArtist                          : Thirty two characters only Thęrty twó chąractęrś óńły\r\n---- IPTC ----\r\nBy-line                         : Thirty two characters only Thęr\r\n---- XMP ----\r\nCreator                         : Thirty two characters only Thęrty twó chąractęrś óńły\r\n```\r\n\r\nPNG and GIF save of the same image reveals that the data is being saved **only** into XMP `dc:creator` field (so we wouldn’t even see it).\r\n\r\nUnfortunately, this phenomenon is definitely not confined to Creator/Byline/Artist field in question here as above linked attempts at mappings indicate. The same information can reside in different parts of the metadata or just some of these parts depending on the file format and/or writing application. This data can be truncated if the writing application observed the (legacy) specs or it may not if it didn’t. The same data can reside in different parts of the metadata in different formats (e.g. date). Lastly, some of these places can contain **conflicting** metadata, which in some instances would be easier to fix (pick oldest for creation date), in some - much harder/impossible without appending all instances.\r\n\r\nA simplest (?) fix would be to read metadata in a specified order from different fields/parts of the metadata (starting with `dc:creator` in this instance) and store the first found value for only the fields we are interested in. A proper solution would be to create a canonical map of all known metadata with rules about field priority, format conversions for data in certain fields, different strategies on how to deal with conflicts for different types of data. I’m sure such a thing already exists somewhere (if only in the above linked attempts), maybe in the open, maybe only in Adobe towers...\r\n\r\nAnd reading is just half of the problem, then (when/if https://github.com/guardian/grid/issues/823), there is a problem of saving that data back.\r\n\r\nOh, and we could start by reopening the issue :wink: \r\n\r\nRegards\r\nMateusz"}}