GNOME Bugzilla – Bug 342137
import tags from exif in the database
Last modified: 2006-09-15 06:10:27 UTC
When you re-import a picture in f-spot, the tags written in the exif part are not imported to the database. Way to reproduce: - import pictures - tag them - delete from catalogue - import them again Now, if you make Ctrl-I, you can see the tags (if the option is checked in the preferences), but they do not appears as 'tagged' in f-spot. It could be very usefull to make backups for example. So you can tag your pictures, make a backup and reimporting them again with the tags...
Perhaps you can check bug #337805 and see if it is a duplicate?
I don't think it's a duplicate, but we can merge the two. #337805 is about importing "comment", this one is about importing "tags". And the amount of work required to fix this is a bit bit higher, since you need to look for an existing tag and create it if required... For "comment", you jusst fill the database. But yes, one more time, we can merge the two and redefine #337805
Created attachment 65865 [details] [review] patch to allow partial xmp tag importing. This is actually a perfect place to attach my import fix. This patch gives partial xmp support. It adds a 'GetTagNames' method to MetadataStore - the method doesn't fully parse the XMP field - if it finds any 'bag' structures in the xmp it returns the strings contained in it. This won't necessarily do the right thing for the general xmp case --- but for xmp data exported from f-spot, or carefully constructed xmp data where the only bags represent tags, it will work. The actual tag importing is completely separated from the xmp parsing - so if someone can fix the xmp parsing, the tag importing should work fine. There's also a little bit of somewhat special case code that looks for a photoshop 'headline' field and puts the content in as a comment.
Created attachment 66189 [details] Screenshot of tags after import This is a small teaser screenshot of the tag sidebar after importing 400+ photos. Most of them are tagged with iView Media Pro. This patch creates Places -- Location -- Country -- City Last Import As well as set the Comment field.
Created attachment 66190 [details] Better screenshot A better (smaller) screenshot
Created attachment 66198 [details] [review] Patch to import (some) XMP tags This patch will create and set a number of existing XMP tags during import. Looking forward to some comments/review on this one, since I have not done anything before on XMP tags. Loading time is a bit more. My test load of 414 pictures took 6 min 10 sec, versus 3 min 40 sec for CVS F-Spot. It is checking for Photoshop : City, Country, Headline, Caption, Urgency Iview MediaPro : Location Adobe : UserComment (F-Spot stores the comment into this field) dc : subject, creator, rights, description, title Plus some various tags for EXIF and TIFF. See below. Have city = >>null<< Have country = >>null<< Have ps_headline = >>null<< Have ps_caption = >>null<< Have urgency = >>null<< Have location = >>null<< Have pu_title = >>null<< Have pu_description = >>null<< Have exif description = >>1<< Have adobe usercomment = >>standard title<< Have rights = >>null<< Have creator = >>null<< Have keyword = >>GuangZhou<< Have keyword = >>Jasmine<< Have keyword = >>Bengt<< Have keyword = >>Favorites<< Have keyword = >>Story Time<< Have make = >>Canon<< Have model = >>Canon PowerShot S70<< Have orientation = >>1<< Have resolutionunit = >>2<< Have exposuretime = >>1/60<< Have fnumber = >>5<< Have shutterspeedvalue = >>189/32<< Have aperturevalue = >>149/32<< Have exposurebiasvalue = >>0<< Have maxaperturevalue = >>149/32<< Have meteringmode = >>5<< Have focallength = >>559/32<< Have colorspace = >>1<< Have pixelxdimension = >>3072<< Have pixelydimension = >>2304<< Have exposuremode = >>0<< Have whitebalance = >>0<< Have digitalzoomratio = >>1<<
Outstanding issue. How to recover if cancelling. Possible optimisation? Only open the photo once, instead of twice as now.
O'h, sidecar needs to be investigated a bit more on how to deal with it.
Seems to be a crash in some use cases with this patch... I got it when I open a directory with XMP tagged photos (City, Subjects, Descriptions etc) Do not import, but Choose direct another folder. Crash --> System.NullReferenceException: Object reference not set to an instance of an object in <0x00fc2> IconView:DrawCell (int,Gdk.Rectangle) in <0x0017a> IconView:DrawAllCells (Gdk.Rectangle) in <0x00097> IconView:OnExposeEvent (Gdk.EventExpose) in <0x00054> Gtk.Widget:exposeevent_cb (intptr,intptr) in <0x00035> (wrapper native-to-managed) Gtk.Widget:exposeevent_cb (intptr,intptr) in (unmanaged) 0xb695584f in <0x00004> (wrapper managed-to-native) Gtk.Dialog:gtk_dialog_run (intptr) in <0x0001d> Gtk.Dialog:Run () in <0x0001e> CompatFileChooserDialog:Run () in <0x000a4> ImportCommand:ChoosePath ()
There is no crash in the patch submitted here. The crash is in my working patch with a small addition for how to delete just created tags if user cancels. See http://mail.gnome.org/archives/f-spot-list/2006-May/msg00117.html for more details.
Created attachment 66515 [details] [review] Patch with delete if cancel An updated patch that deletes the imported tags if user cancels. Due to the Cancel routines do not clean up properly, there was a crash a bit further down the track. Due to this I had to disable DisplayTags while doing the import. Let the comments begin :)
Quick patch review: patch 66515 for bug 342137 - no longer apply cleanly against CVS but easyly fixable by hand - compile and works as expected One missing thing in importing tags (so we can have a backup capability): re-create tag hierarchy. How to do it: *) when writing tags, write hierarchy, like "Places","Brussels","La Grand Place" in the same bag. *) when importing images, if the leaf tag (e.g. "La Grand Place") exists, ignores the hierarchy, but if the leaf tags do not exists yet, create the hierarchy. It could be useful to fill another bug for writing the tag hierarchy in the XMP bag...
Yes, we definitely need this. But before we fix the import, the export better be specified. I like the "tag1", "tag2" specifications. We do not use a separate character as a separator. I will create a bug for writing hierarchy tags. Done, bug #345405
about what I said in comment #12: if F-Spot support 'duplicate' tags (bug #338558), the handling of hierarchical tags should be a bit different: If the fully qualified tag name match with an existing tag, it's the same tag, else, create the new full path. But this raise the problem of knowing which tags have been imported...
Created attachment 68231 [details] [review] updated patch for simple xmp importing Updated my version of the patch - now applies against HEAD. This doesn't include Bengt's changes
Created attachment 68236 [details] [review] Update patch so it applies to Head Ok, I have now updated the longer version of this patch, which imports embedded F-Spot (XMP) tags from the pictures. Applies cleanly as of today anyway :)
Created attachment 68292 [details] [review] Updated patch (with the two new files) Yap, I did it again :( Forgot to add the two new files... :( Anyway, they are added in this version... (I hope)
Created attachment 68339 [details] [review] Latest version of Bengts XMP import (fixing a stupid duplicate store) Apparently a small bug was introduced in the last patch. So here is a small updated version.
The tags are created and attached nicely, but there are no small icons next to the tags, nor any icons under the thumbnails either. Guess this is not that good.... Any suggestions on how to fix this?
using patch 68339, I'm no longer able to import images using drag'n drop to the browse view...
One missing thing in patch 68339: an icon for the 'Last Imported Tags' category
Created attachment 68550 [details] [review] Bengts XMP import tag patch This version removes the Dialog parameter, and I also verified that the drag and drop from Nautilus works fine.
problem reported in comment #20 is fixed with the latest patch !
path 68550 no longer apply against CVS...
Created attachment 69375 [details] [review] Bengts XMP import tag patch Modified patch so it applies cleanly against CVS Please test review comment and hopefully commit... :)
Warren, Could you confirm that my longer patch does everything your does. Apart from the sidecar, which unfortunately do not work that good in my patch. I am using the generic ImageFile by default (compile option to use JpegFile though), which always returns true that there are XMP data in the image. So no check for a sidecar file. The import from a sidecar should probably be dealt in another bug. Larry: Have you had a look at this patch. Any comments/reviews from others? (Following comment is wrong + // SemWeb returns the language appended to the string as "....."@x-default, so if we remove everything + // between the first and last '"' it should be ok. Should be + // SemWeb returns the language appended to the string as "....."@x-default, so if we keep everything + // between the first and last '"' it should be ok. )
Patch review: patch 69375 for bug 342137 (as posted on f-spot-list) About the code: a) trivial: don't anti-date the Changelog entry :):) diff -u -p -r1.1525 ChangeLog --- ChangeLog 20 Jul 2006 20:23:57 -0000 1.1525 +++ ChangeLog 22 Jul 2006 09:26:11 -0000 @@ -1,3 +1,16 @@ + 2006-07-27 Bengt Thuree <bengt@thuree.com> b) in ImportCommand.cs: you're doing: tray = new FSpot.ScalingIconView (collection); + bool SavedDisplayTags; [...] + SavedDisplayTags = tray.DisplayTags; // So we know which state we had. + tray.DisplayTags = false; // Otherwise deleting just created XMP tags will crash. [...] + tray.DisplayTags = SavedDisplayTags; this.Dialog.Destroy (); It's useless to save the state after the new and restore it just after the Destroy. Just do: + tray.DisplayTags = false; // Otherwise deleting just created XMP tags will crash. c) XmpTagsImporter.cs: why not integrate all this code in a namespace ? d) XmpTagsMetadata.cs: idem e) the style policy for F-Spot ask to add a copyright notice and a short description for new files (XmpTagsImporter and XmpTagsMetadata) f) AddTagToPhoto: Hardcoding english string is probably not the good choice with an international app. g) why still naming the variable 'place' like in: + // Check if a tag exists for this place + Tag place = tag_store.GetTagByName (new_tag_name); now that the code will import all kinds of tags (not only places) ? h) is not better to always create the new tags under the 'Last Import' category, even for Places, Country or Location ? To avoid losing knowledge about the fact that's a place, maybe create them under LastImport>Places ... i)consider removing that #define UseImageFile, it's too C-ish j)it's really nice to check for a lot of other xmp info than just places and keyword. hope F-Spot will use them soon About the UI: Add a default Icon for Last Import
Created attachment 69404 [details] [review] Bengts XMP import tag patch Updated the patch after fixing Stephane's comments (and returning from the future... forgot the newspaper I bought there though :( ).
Created attachment 69565 [details] Icon for Bengts XMP import patch put this icon into f-spot's icon directory.... apply Bengts XMP import patch. compile... install... and test
The solution to solve the specials characters issue: replace (in src/XmpTagsMetadata.cs): string stmt_pre_str = stmt.Predicate.ToString(); string stmt_obj_str = stmt.Object.ToString() by: string stmt_pre_str = stmt.Predicate.ToString(); string stmt_obj_str; if (stmt.Object is SemWeb.Literal) stmt_obj_str = ((SemWeb.Literal)(stmt.Object)).Value; else stmt_obj_str = stmt.Object.ToString(); it's not a diff'ed patch, but it's more readable...
Created attachment 69577 [details] [review] Bengts XMP patch This patch have Stephanes and Cosmes fix for UTF-8 import. As well as importing a bit more of the XMP tags from iViewMedia Pro. Would be great if someone could verify the UTF-8 part...
works for me, with the complete set of French special characters
Created attachment 69656 [details] [review] Bengts XMP import patch I have reworked the patch a bit, and based it much more on F-Spot Metadata browser. This enabled me to get a few more tags, as well as made the code a bit nicer :) As usuall... Comments/Testers are much appreciated...
Created attachment 69706 [details] [review] Bengts XMP import patch Added extra XMP related comments to the code Added support for XMP tag Rating (Not confirmed though. To confirm, enable debug, and import)
Created attachment 69741 [details] [review] Bengts XMP import patch Ok, I modified my import function a bit to accomodate a possible Sidecar better. Check if jpg file, if it is, check if embedded XMP, if it is --> ImageFile. If no embedded xmp tags --> Sidecar file. A bit more opening and checking the files, but it works... Please check/test and comment.
The latest patch is not that good, since it skips all possible exif data in the picture, and only looks at the sidecar if no xmp tags. I am working on a new version, that will first read a sidecar if it exists, then the picture it self.
Created attachment 69865 [details] [review] Bengts XMP import tag patch This version of the patch will first import a Sidecar's tags (if any), and then import any embedded tags (exif, xmp etc). That is the embedded tags will take priority. As soon as a Sidecar photo is imported to F-Spot, the photo will be updated with the tags (keywords, titel etc). Even if you cancel the import, this will happend! I had to rework the logic a bit, so unfortunately, some more testing would be great :) Plus of course reviews and feedback. So far I have tried to incorporate everyones feedback so do give feedback. p.s. do not forget the Icon attachment in this bug also.
One more review, patch #69865 pros: *) apply and compile *) works with my pictures (French characters) *) the new logic (read sidecar first, do not import sidecar) looks ok for most of the usecases of most of the users *) nice tango icon for 'Last Import' *) code review: passed cons: *) none So, one more review of this and we can mark it as 'accepted-commit-now'
Review of patch #69865 Haven't actually run it yet, but I have a few comments from reading the patch. 1) Its FileImportBackend dependent, I guessing that once the import code gets fixed to not be FIB specific, that this can be fixed without too much of a problem. 2) Is LastImport just a place to stick tags that have to be created? Does it have anything to do with the patch that keeps track of imports? Does LastImport get cleared on each import? Would "Imported" make more sense? 3) Why are we creating/retrieving the root and subroot tags every time in AddTagToPhoto? Why not make it a property of TagInfo so it only needs to be done once? Also a private method GetTagCreateIfItDoesntExist(String name, Tag parent) (better name of course) might be in order to tie up all the functionality of trying POSIX, then normal String, then create. 4) The ":" character is used between the headline and caption (see line 401 of the diff) A colon seems like a fairly common character that might be used within either the headline or the caption. If we ever wanted to reparse the headline and caption out it wouldn't work. It would also be visually hard to parse for the user. What about using "::" or something else less likely to occur? 5) Fairly nitpicky I guess, but at least for me the logic is clearer, I'll see what you guys think. Line 417, the two if blocks. The second one overwrites the first if true. How about: if (xmd.ps_Caption != null) photo.Description += (( (xmd.ps_Headline == null) ? "" : " : ") + xmd.ps_Caption); else if(xmd.ps_Headline != null) photo.Description = xmd.ps_Headline; Overall looks really solid. I'll see if I can try it out tomorrow. I don't have any images tagged with other programs to try it with though. Oh and props to the writers for the comments as for me they give just about the perfect level of detail.
1) Hope so. 2) I'll change the "Last Import" to "Imported tags" 3) Good point. Will fix this (and use your good name :) Clear english, like it) 4) Will change ":" to a "::" 5) We need nitpickying :) Better logic in your sample. I'll also remove the Sidecar tag that is created if a sidecar is used. Do anyone have any other comments?
Actually, point 5 :) Sorry, was a bit hasty there. There is no overwritting. There is a "+=" which is add the following to the existing Description. code below. if (xmd.ps_Headline != null) photo.Description = xmd.ps_Headline; if (xmd.ps_Caption != null) photo.Description += (( (xmd.ps_Headline == null) ? "" : " : ") + xmd.ps_Caption); I will fix the comment a bit better.
Yes you're right about 5). I was getting tired near then end there. As I mentioned on IRC today, I'm now thinking that GetTagCreateIfItDoesntExist(String name, Tag parent) would be useful generally, and therefore would make more sense as a TagStore method.
On second thought, I am not to sure of this in this particular case. This because I am keeping track of all tags that are created, and if the user wants to cancel, all created tags are deleted.
Created attachment 70135 [details] [review] Bengts XMP import tag patch Very small update on this patch. Summary diff diff XmpTagsImporter.cs ../src.old/ <static private string LastImportStr = "Imported Tags"; >static private string LastImportStr = "Last Import"; <// We want to construct the following : Description = <Headline> :: <Caption> < <// Lets add the Caption to the existing Description (Headline). <photo.Description += (( (xmd.ps_Headline == null) ? "" : " :: ") + xmd.ps_Caption); >photo.Description += (( (xmd.ps_Headline == null) ? "" : " : ") + xmd.ps_Caption); <// Lets add the Description to the existing Description (Title). <photo.Description += (( (xmd.pu_Title == null) ? "" : " :: ") + xmd.pu_Description); >photo.Description += (( (xmd.pu_Title == null) ? "" : " : ") + xmd.pu_Description); <//if (xmd.AnySidecarTags()) <// AddTagToPhoto (photo, Mono.Posix.Catalog.GetString (XMPSidecarStr), null); >if (xmd.AnySidecarTags()) >AddTagToPhoto (photo, Mono.Posix.Catalog.GetString (XMPSidecarStr), null);
Just running over the source: What purpose does this serve: + if (xmd.Urgency != null) { + } + if (xmd.Rating != null) { + } + if (xmd.Rights != null) { + } + if (xmd.Creator != null) { + } Also the syntax is a bit strange at times, there's the utterly condensed begin of XmpTagsMetadata followed by an utterly streched switch in GetSingleRowData. But that doesn't affect functionality at all so it's basically nitpicking. Which in a way is a good thing, no obvious crack visible ;-).
The Urgency, Rating, Rights, and Creator bits in XmpTagsImporter do not serve any purpose at all today. You are right on that. Just put in some simple hooks for future use. :) Good point in XmpTagsMetadata. About the nitpicking. Started with the very condensed part, since I figured why take 3 pages with basically nothing. I perhaps should have been consistent and done the same for the switch statement in GetSingleRowData. If there are a objections on the code structure, I will change either one of them.
Dany found a bug in XmpTagsMetadata :( Please add "if (keywords != null)" on row 403. In more detail : Please replace Console.WriteLine ("====> Not handled importing XMP Collection TITLE >>{0}<<", title); foreach (string keyword in keywords) Console.WriteLine ("====> Missing tag = >>{0}<<", keyword==null ? "null" : keyword ); with Console.WriteLine ("====> Not handled importing XMP Collection TITLE >>{0}<<", title); if (keywords != null) foreach (string keyword in keywords) Console.WriteLine ("====> Missing tag = >>{0}<<", keyword==null ? "null" : keyword ); in XmpTagsMetadata.cs iaround row 402 I will upload a new patch soon, but wanted to see if more comments/problems have been reported. Dany also reported that he got the following output in the console: ====> Not handled importing XMP Collection TITLE >>Configuration des composants<< This indicates that the "Components Configuration" xmp/exif tag has been translated to a local language. Is this something we need to handle? Localized XMP/EXIF headings?
Created attachment 70192 [details] [review] Bengts XMP import tag patch Latest version, with the fix for the debug crash when an unknown XMP tag is encountered. Also handles 3 new tags for Photoshop.
Created attachment 70196 [details] [review] Bengts XMP import tag patch Latest patch against CVS. This one includes a fix for F-Spot running in non english language.
Tested... and it works !
Created attachment 70310 [details] [review] Bengts XMP import tag patch Ok, hopefully this is one of the last versions of this patch. Warrens suggestion of a Hash table has been implemented. Not to straightforward with bags (string, or string[] and should also have string[][] but have not done that) Ruben: I removed those prepared calls. Ben: I added a "AddImportRootTagIfNotExist" function, which should make it a bit easier to read. I verified the total number of tags imported before and after these changes, and they were the same (tested 700+ photos)
Sorry for the long post but I wanted to share my recent testing on the XMP patch : Sofware used : - F-Spot CVS + Patch described in bug 342137, comment #49 - Exiftool (Linux tool to read EXIF/XMP) : http://www.sno.phy.queensu.ca/~phil/exiftool/ - Pixvue (freeware to read/edit XMP) : http://www.pixvue.com/ - Adobe Photoshop CS2 Procedure : 1) Add a tag (keyword "Voiture") to a picture and import it under third-party tools to see if it can be seen 2) Add a tag (keyword "Voiture") to a picture using third-party tools and see if F-Sport imports it Results : 1) File containing XMP tags added by F-Spot is not read by third party tools (Pixvue, Adobe & Exiftool) 2) F-Spot correctly imports XMP enabled files from all software described above : (Pixvue & Adobe) # Original picture : http://nativel.net/f-spot/testimg-original.JPG - Exiftool output : http://nativel.net/f-spot/testimg-original.txt # Image tagged by F-Spot : http://nativel.net/f-spot/testimg-f-spot.JPG - Exiftool output : http://nativel.net/f-spot/testimg-f-spot.txt - Pixvue ouput : http://nativel.net/f-spot/xmp-properties-f-spot.jpg - Adobe shows an error box when opening the file : http://nativel.net/f-spot/photoshop-opening-f-spot.jpg # Image tagged by Photoshop : http://nativel.net/f-spot/testimg-photoshop.JPG - Exiftool output : http://nativel.net/f-spot/testimg-photoshop.txt - Pixvue ouput : http://nativel.net/f-spot/xmp-properties-photoshop.jpg # Image tagged by Pixvue : http://nativel.net/f-spot/testimg-pixvue.JPG - Exiftool output : http://nativel.net/f-spot/testimg-pixvue.txt - Pixvue ouput : http://nativel.net/f-spot/xmp-properties-pixview.jpg
(In reply to comment #52) > Sorry for the long post but I wanted to share my recent testing on the XMP > patch : > > Sofware used : > - F-Spot CVS + Patch described in bug 342137, comment #49 > - Exiftool (Linux tool to read EXIF/XMP) : > http://www.sno.phy.queensu.ca/~phil/exiftool/ > - Pixvue (freeware to read/edit XMP) : http://www.pixvue.com/ > - Adobe Photoshop CS2 > > Procedure : > 1) Add a tag (keyword "Voiture") to a picture and import it under third-party > tools to see if it can be seen > 2) Add a tag (keyword "Voiture") to a picture using third-party tools and see > if F-Sport imports it > > Results : > 1) File containing XMP tags added by F-Spot is not read by third party tools > (Pixvue, Adobe & Exiftool) > 2) F-Spot correctly imports XMP enabled files from all software described above > : (Pixvue & Adobe) > > # Original picture : http://nativel.net/f-spot/testimg-original.JPG > - Exiftool output : http://nativel.net/f-spot/testimg-original.txt > > # Image tagged by F-Spot : http://nativel.net/f-spot/testimg-f-spot.JPG > - Exiftool output : http://nativel.net/f-spot/testimg-f-spot.txt > - Pixvue ouput : http://nativel.net/f-spot/xmp-properties-f-spot.jpg > - Adobe shows an error box when opening the file : > http://nativel.net/f-spot/photoshop-opening-f-spot.jpg > > # Image tagged by Photoshop : http://nativel.net/f-spot/testimg-photoshop.JPG > - Exiftool output : http://nativel.net/f-spot/testimg-photoshop.txt > - Pixvue ouput : http://nativel.net/f-spot/xmp-properties-photoshop.jpg > > # Image tagged by Pixvue : http://nativel.net/f-spot/testimg-pixvue.JPG > - Exiftool output : http://nativel.net/f-spot/testimg-pixvue.txt > - Pixvue ouput : http://nativel.net/f-spot/xmp-properties-pixview.jpg > Also tried with Jbrout (http://jbrout.python-hosting.com/), pictures tagged with CS2 and Pixvue shows up in Jbrout but not the F-Spot one.
First. A bit confused. You did state F-Spot read Pixvue and Adobe first, then you stated F-Spot did not read Pixvue. Second: A quick check of the f-spot strings vs photo shop strings. For sure, photoshop makes them much more readable. A quick glance indicates that F-Spot is not creating the same xmp structure as photoshop. Have no more time to check though. If this is the case. It should be a new bug, for F-Spot not writing proper XMP structure. <?xpacket begin=" " id="testing"?><x:xmpmeta xmlns:x="adobe:ns:meta/"><rdf:RDF xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xmpBJ="http://ns.adobe.com/xap/1.0/bj/" xmlns:xmpidq="http://ns.adobe.com/xmp/Identifier/qual/1.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:tiff="http://ns.adobe.com/tiff/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xmpRights="http://ns.adobe.com/xap/1.0/rights/" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:exif="http://ns.adobe.com/exif/1.0/"><rdf:Bag rdf:nodeID="anon0"><rdf:li>Voiture</rdf:li></rdf:Bag><rdf:Description rdf:about=""><dc:subject rdf:nodeID="anon0" /></rdf:Description></rdf:RDF></x:xmpmeta><?xpacket end="r"?> <?xpacket begin=" " id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.1-111"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:tiff="http://ns.adobe.com/tiff/1.0/"> <tiff:Orientation>1</tiff:Orientation> <tiff:YCbCrPositioning>1</tiff:YCbCrPositioning> <tiff:XResolution>1800000/10000</tiff:XResolution> <tiff:YResolution>1800000/10000</tiff:YResolution> <tiff:ResolutionUnit>2</tiff:ResolutionUnit> <tiff:Make>Canon</tiff:Make> <tiff:Model>Canon DIGITAL IXUS 30</tiff:Model> <tiff:NativeDigest>256,257,258,259,262,274,277,284,530,531,282,283,296,301,318,319,529,532,306,270,271,272,305,315,33432;4E80A2AFBCE7D0E4FAEA9C8BF4E10E7D</tiff:NativeDigest> </rdf:Description> <rdf:Description rdf:about="" xmlns:xap="http://ns.adobe.com/xap/1.0/"> <xap:ModifyDate>2006-08-06T20:23:44+02:00</xap:ModifyDate> <xap:CreatorTool>Adobe Photoshop CS2 Windows</xap:CreatorTool> <xap:CreateDate>2006-05-07T11:24:31+02:00</xap:CreateDate> <xap:MetadataDate>2006-08-06T20:23:44+02:00</xap:MetadataDate> </rdf:Description> <rdf:Description rdf:about="" xmlns:exif="http://ns.adobe.com/exif/1.0/"> <exif:ExifVersion>0220</exif:ExifVersion> <exif:FlashpixVersion>0100</exif:FlashpixVersion> <exif:ColorSpace>-1</exif:ColorSpace> <exif:CompressedBitsPerPixel>5/1</exif:CompressedBitsPerPixel> <exif:PixelXDimension>2048</exif:PixelXDimension> <exif:PixelYDimension>1536</exif:PixelYDimension> <exif:DateTimeOriginal>2006-05-07T11:24:31+02:00</exif:DateTimeOriginal> <exif:DateTimeDigitized>2006-05-07T11:24:31+02:00</exif:DateTimeDigitized> <exif:ExposureTime>1/400</exif:ExposureTime> <exif:FNumber>35/10</exif:FNumber> <exif:ShutterSpeedValue>277/32</exif:ShutterSpeedValue> <exif:ApertureValue>116/32</exif:ApertureValue> <exif:ExposureBiasValue>0/3</exif:ExposureBiasValue> <exif:MaxApertureValue>116/32</exif:MaxApertureValue> <exif:MeteringMode>5</exif:MeteringMode> <exif:FocalLength>10093/1000</exif:FocalLength> <exif:FocalPlaneXResolution>2048000/224</exif:FocalPlaneXResolution> <exif:FocalPlaneYResolution>1536000/168</exif:FocalPlaneYResolution> <exif:FocalPlaneResolutionUnit>2</exif:FocalPlaneResolutionUnit> <exif:SensingMethod>2</exif:SensingMethod> <exif:FileSource>3</exif:FileSource> <exif:CustomRendered>0</exif:CustomRendered> <exif:ExposureMode>0</exif:ExposureMode> <exif:WhiteBalance>0</exif:WhiteBalance> <exif:DigitalZoomRatio>2048/2048</exif:DigitalZoomRatio> <exif:SceneCaptureType>0</exif:SceneCaptureType> <exif:Flash rdf:parseType="Resource"> <exif:Fired>False</exif:Fired> <exif:Return>0</exif:Return> <exif:Mode>3</exif:Mode> <exif:Function>False</exif:Function> <exif:RedEyeMode>False</exif:RedEyeMode> </exif:Flash> <exif:NativeDigest>36864,40960,40961,37121,37122,40962,40963,37510,40964,36867,36868,33434,33437,34850,34852,34855,34856,37377,37378,37379,37380,37381,37382,37383,37384,37385,37386,37396,41483,41484,41486,41487,41488,41492,41493,41495,41728,41729,41730,41985,41986,41987,41988,41989,41990,41991,41992,41993,41994,41995,41996,42016,0,2,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,20,22,23,24,25,26,27,28,30;2C7745B762DF0683AF0CB638837F3C30</exif:NativeDigest> </rdf:Description> <rdf:Description rdf:about="" xmlns:xapMM="http://ns.adobe.com/xap/1.0/mm/"> <xapMM:DocumentID>uuid:946212577825DB119789B87A5260C2DF</xapMM:DocumentID> <xapMM:InstanceID>uuid:956212577825DB119789B87A5260C2DF</xapMM:InstanceID> </rdf:Description> <rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:format>image/jpeg</dc:format> <dc:subject> <rdf:Bag> <rdf:li>Voiture</rdf:li> </rdf:Bag> </dc:subject> </rdf:Description> <rdf:Description rdf:about="" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"> <photoshop:ColorMode>3</photoshop:ColorMode> <photoshop:ICCProfile>sRGB IEC61966-2.1</photoshop:ICCProfile> <photoshop:History/> </rdf:Description> </rdf:RDF> </x:xmpmeta>
JBrout seems only to understand IPTC tags. F-Spot only writes XMP tags. ((tags (as IPTC keywords, in the picture))) So JBrout will not read the tags F-Spot have produced, but PHotoShop and Pixview probably writes IPTC tags as well.
(In reply to comment #55) > JBrout seems only to understand IPTC tags. F-Spot only writes XMP tags. > ((tags (as IPTC keywords, in the picture))) > > So JBrout will not read the tags F-Spot have produced, but PHotoShop and > Pixview probably writes IPTC tags as well. > Sorry for this one, you're right
> First. > A bit confused. You did state F-Spot read Pixvue and Adobe first, then you > stated F-Spot did not read Pixvue. I meant F-Spot can import pictures tagged by Pixvue and Adobe. But Pixvue, Adobe and EXIFTool are unable to read any picture tagged by F-Spot > Second: > > A quick check of the f-spot strings vs photo shop strings. > > For sure, photoshop makes them much more readable. > > A quick glance indicates that F-Spot is not creating the same xmp structure as > photoshop. Have no more time to check though. If this is the case. It should be > a new bug, for F-Spot not writing proper XMP structure. Photoshop structure looks pretty weird. Have you checked the Pixvue one which looks much simplier ? As far as Exiftool XMP support (http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/index.html) XMP XMP aux XMP cc XMP crs XMP dc XMP dex XMP exif XMP iptcCore XMP pdf XMP photoshop XMP PixelLive XMP tiff XMP xmp XMP xmpBJ XMP xmpDM XMP xmpMM XMP xmpPLUS XMP xmpRights XMP xmpTPg Dany
Created attachment 70388 [details] [review] Bengts XMP import tag patch Slightly updated patch. Handles a few more tags Flash bags are now handled as well. Bags can be 1) string 2) string [] 3) Bag_Couple (title (string), value (string) ) 4) Bag_Couple [] Example of a flash bag : Flash --> >>Fired::False<< >>Return::0<< >>Mode::3<< >>Function::False<< >>RedEyeMode::False<<
Most recent version of the patch works as advertised.
I read through the patch and following are my comments. As a summary I'd say the patch is good and I'm nitpicking. This probably reflects more of my personal preferences (keeping indentation level low, even using 'continue/break' and premature return. I hope these hasty notes are understandable. - TagStore tag_store = FSpot.Core.Database.Tags; -> "using FSpot.Core.Database.Tags"? -> single use, necessary? - ImportCommand.cs - unnecessary whitespace removal (those chunks of patch can be removed from patch by hand, then apply edited patch (will apply with fuzz) and rediff) - tray.DisplayTags = false; - better fix this. bug to submit. - AddImportRootTagIfNotExist() - if (root_tag != null) return root_tag; etc. ? - AddTagToPhoto() - if new_tag_name == null: return - AddTagToPhoto(), same - Import() - explicit checks for many nulls tells that this should be 'genericised' somehow. Maybe all 'li_foo':s should be moved to Hashtable() and then whole xmd.GetXmpTag() driven through: string[,] tags = {{"State", "li_subroot_state"}, {"City", "li_subroot_city"} ...}; for(int i=0; i < tags.Size(0);i++) if (xmd.GeXmpTag(tags[i,0) != null) AddTagToPhoto(...) - same for bags? - GetXmpBag() always to return string[] ? - XmpTagsMetadata, function and class naming, away with underscores - TrimEmptyChars - if(txt) return txt.Replace(' ','').Replace((char)0,'').Replace('\t','').Replace('\n',''); - UpdateXMPBagTable - xmp_bag_table should really always contain string[] - foreach(string in xmp_bag_tags) if(str != predicate) continue; (less indentation levels) - Hmm, whole thing should be taken away from foreach and only 'found' set true. string[] may also have '.Contains()' -method that can help get rid of foreach(). - May also consider 'PredicateKnown()' -function. - Read_tags(): - is if/else for Jpeg/Png really necessary? - if (store.StatementCount == 0) return true;
The icon (from Comment #29) should be called f-spot-imported-xmp-tags.png This is not mentioned in the comment or anywhere else.
Created attachment 71899 [details] [review] Bengts XMP import tag patch I found a small crash if you had a tag that were called the same as the root tags. Fixed in this release. In addition to this, I added People tags to the Keywords. Also, prepared for a full list of IPTC tags from iViewMedia Pro. See below for some samples. City --> >>City<< State --> >>State<< Country --> >>Country<< CaptionWriter --> >>Description Writer<< Credit --> >>Provider<< Category --> >>Category Bengt<< Source --> >>NIKON D100<< Headline --> >>Headline<< Urgency --> >>2<< Instructions --> >>Instructions<< TransmissionReference --> >>Job Identifier<< AuthorsPosition --> >>Creators Title<< DateCreated --> >>2005-09-02<< Make --> >>NIKON CORPORATION<< Model --> >>NIKON D100<< ResolutionUnit --> >>2<< YCbCrPositioning --> >>2<< ExposureTime --> >>1/125<< FNumber --> >>71/10<< ExposureBiasValue --> >>0<< MaxApertureValue --> >>3<< MeteringMode --> >>2<< FocalLength --> >>170<< ColorSpace --> >>1<< PixelXDimension --> >>3008<< PixelYDimension --> >>2000<< ExposureMode --> >>0<< WhiteBalance --> >>0<< DigitalZoomRatio --> >>1<< LightSource --> >>0<< ExifVersion --> >>0220<< DateTimeOriginal --> >>2005-09-02T04:57:11<< DateTimeDigitized --> >>2005-09-02T04:57:11<< CompressedBitsPerPixel --> >>2<< FlashPixVersion --> >>0100<< SensingMethod --> >>2<< FileSource --> >>3<< CustomRendered --> >>0<< SceneCaptureType --> >>0<< SceneType --> >>1<< ExposureProgram --> >>3<< FocalLengthIn35mmFilm --> >>255<< GainControl --> >>0<< Contrast --> >>2<< Saturation --> >>0<< Sharpness --> >>2<< Location --> >>Location<< Status --> >>Status<< Event --> >>Event Jade<< CountryCode --> >>ISO Country<< IntellectualGenre --> >>Ind. Genre Bengt<< Rating --> >>4<< ModifyDate --> >>2005-09-02T04:57:11<< CreatorTool --> >>Ver.2.00<< WebStatement --> >>URL<< SupplementalCategories --> >>Categories Wife<<, >>Categories Girls<<, subject --> >>Keywords Party<<, >>Keywords Summer<<, >>Keywords Beach<<, creator --> >>Creator First Name and Last Name<< rights --> >>Copyright Notice<< title --> >>Title<< UsageTerms --> >>Rights Usage Terms<< ComponentsConfiguration --> >>1<<, >>2<<, >>3<<, >>0<<, ExifCFAPattern --> >>Columns::2<< >>Rows::2<< Scene --> >>Scenes Wedding<<, >>Scenes Beach<<, CreatorContactInfo --> >>CiAdrExtadr::Creators Address1 Creators Address2<< >>CiAdrCity::Creators City<< >>CiAdrRegion::Creators State/Province<< >>CiAdrPcode::Creators postal code<< >>CiA drCtry::Creators Country<< >>CiTelWork::Creators Phone<< >>CiEmailWork::Creators Email<< >>CiUrlWork::Creators Web site<< SubjectCode --> >>Subject Codes Bengt<< People --> >>People Bengt<<, >>People Jade<<, >>People Jasmine<<
I've committed the patch then refactored the code a bit and disabled a few things until I have a little more time to think about them. Everyone intersted in this bug should test cvs and give feedback. I'm going to close this bug as fixed.