GNOME Bugzilla – Bug 356387
Import People, Location, Headline from IPTC tags
Last modified: 2018-07-01 08:51:32 UTC
F-Spot do not look for the following tags in IPTC for the moment. Contact = Record.Application | 118, - People ContentLocationName = Record.Application | 27 - Location Headline = Record.Application | 105, I created a small patch (that also includes the fix for bug # to import this extra tags. One problem though, is that if these tags ALSO exists as XMP data, they will be duplicated. The patch will map these fields to photoshop:Headline mediapro:People Iptc4xmpCore:Location There is no check for if these tags already exists as XMP tags.
Created attachment 72935 [details] [review] Small patch to add handling of 3 IPTC tags This patch do not detect if the XMP tags already exists. This means, there might be duplicates in the XMP part (one from these IPTC fields, and one from possible existing XMP fields)
Doesn't seem to work. Neither the IPTC tags nor the XMP tags were imported. The IPTC tags in my photos were created by BrilliantPhoto, and are in Hebrew, so that may be the cause of the problem. The XMP tags were created by Fspot, and are also in Hebrew.
I forgot to mention. I did have a problem appling the patch, that I think that I solved, but may still be relevant: dotancohen@ubuntu:~/development/f-spot/f-spot$ vi thepatch.diff dotancohen@ubuntu:~/development/f-spot/f-spot$ patch -p0 < thepatch.diff patching file src/IptcFile.cs patching file src/MetadataStore.cs Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 161. Hunk #2 FAILED at 169. Hunk #3 FAILED at 187. 3 out of 3 hunks FAILED -- saving rejects to file src/MetadataStore.cs.rej dotancohen@ubuntu:~/development/f-spot/f-spot$ patch -p0 < thepatch.diff patching file src/IptcFile.cs Reversed (or previously applied) patch detected! Assume -R? [n] y patching file src/MetadataStore.cs Reversed (or previously applied) patch detected! Assume -R? [n] y dotancohen@ubuntu:~/development/f-spot/f-spot$
The Ipc4xmp spec says that photoshop:Location should be taken from the Iptc Sublocation tag not ContentLocationName. The parts that handle the tags for Location and Headline separately in the switch statement are not needed and because the info has the xmp name for defined and will be handled by the default case. That leaves the iview mediapro info which is still lacking a schema so I can't verify that it makes any sense to store in the contact field into the iview people predicate. Are you doing this based on the results of using iView or is it just a guess?
Created attachment 73059 [details] [review] update Patch Ok, A small updated patch. The last one did not really apply good I think. This patch will import all the fields from your test photo, apart from the description. That is, I see the following english tags (Keywords Field, Place Field, People Field) and I see three Hebrew tags as well. Larry: There might be applications out there that did not use the standard IPTC tags (like People and SubLocation) and therefore perhaps it would be appropriate to map these ones? The iViewMedia Pro XMP specification, have not seen one I agree. I will see if I can find one.
Larry: I have used iView and tagged photos with it. There I saw it using the People tag. I forwarded you my test photos as well. But No, I have not been able to find any official schema (looked for it on the web for some time, but only found indications...)
(Small footnote : Microsoft bought iView and its MediaPro a few months ago. I presume that the various tags will be more wide spread later...)
I building now... This was the output of the patch command: Hunk #4 succeeded at 393 with fuzz 1 (offset 2 lines). Hey! It worked! The IPTC data from BrilliantPhoto is imported! Great! Thanks, Bengt! Great work!
bengt, first in the previous review I mentioned that the headline and location parts were already handled by the default case of the switch statement. The code that handles them separately isn't useful. Second It isn't appropriate to map the Location because Iptc4Xmp clearly states where the Location information should come from. If we want to to map different tags we can map them to a different predicate (probably one in an f-spot namespace) but we wouldn't be following the spec if we violated the mapping for that predicate.
Created attachment 74681 [details] [review] Map IPTC People to XMP IviewMedia People Larry, of course you are right. CVS imports the IPTC Keyword field nicely. The location field is as you stated stored as a IPTC SubLocation. (Could be handled as another bug if needed) The IPTC people field is not handled by CVS. Would it be possible to apply that part of this patch? Since CVS do import the People field from the XMP part I mean. I updated the patch to handle only the IPTC People tag. Any comments?
Any comments on this one?
Comment on attachment 74681 [details] [review] Map IPTC People to XMP IviewMedia People Maintenance update: In the past we've been less than stellar in reviewing patches. As such we have a pile of patches in bugzilla which are outdated and don't apply anymore. Am currently marking all of these as "needs-work". My apologies for this. Since I've become a maintainer of the project, I've set the personal rule of quickly reviewing all patches, to avoid that this happens again. If you (or anyone) wants to go through the trouble of updating this patch, please talk to us to figure out if it fits in the F-Spot long term roadmap. Should you, in the future, notice a patch lingering around for too long, please notify us immediately and we'll look into it, to avoid situations like these from happening again. You can filter these mails by searching for ###F-OLDPATCHCLEANUP###
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.