GNOME Bugzilla – Bug 712477
Expose Adobe Lightroom hierarchical subject tags
Last modified: 2015-03-17 01:54:46 UTC
---- Reported by lucas@yorba.org 2011-08-07 06:50:00 -0700 ---- Original Redmine bug id: 3950 Original URL: http://redmine.yorba.org/issues/3950 Searchable id: yorba-bug-3950 Original author: Lucas Beeler Original description: The Xmp.lr.hierarchicalSubject tag is the most commonly used way of encoding hierarchical keyword information I've found. Right now in Shotwell, we can read from this tag but not write to it. We can't write to it because exiv2 doesn't understand the Lightroom schema. I filed a bug about this on the exiv2 team's Redmine server, and they suggested this workaround, which we should be able to implement in gexiv2: > Well, you're right, Exiv2 doesn't know > the Lightroom schema yet. But that > shouldn't stop you from registering the > `lr` prefix and adding this property with > a value of the correct type anyway. Along the lines of the examples here: http://www.exiv2.org/example5.html Related issues: related to shotwell - Feature #4050: find vendor-neutral tag for storing keywords in XMP (Open) related to shotwell - http://redmine.yorba.org/show_bug.cgi?id=4096: "Hierarchical Subject" not updated when metadata writing on (Fixed) related to shotwell - Feature #6719: Write HTags to Xmp.lr.hierarchicalSubject (Open) ---- Additional Comments From valencia-maint@gnome.bugs 2013-11-08 17:23:00 -0800 ---- ### History #### #1 Updated by Jim Nelson 11 months ago * **Category** set to _implementation_ #### #2 Updated by Jim Nelson 7 days ago * **Assignee** deleted (<strike>_Lucas Beeler_</strike>) --- Bug imported by chaz@yorba.org 2013-11-16 14:44 UTC --- This bug was previously known as _bug_ 3950 at http://redmine.yorba.org/show_bug.cgi?id=3950 Unknown version " in product gexiv2. Setting version to "!unspecified". Unknown milestone "unknown in product gexiv2. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
exiv2 issue report is here: http://dev.exiv2.org/issues/784 I'll take a stab at getting support for this implemented in exiv2.
There is a patch to exiv2 attached to http://dev.exiv2.org/issues/784 If someone could test it, that would be great! It works as expected on my system, but more testing would be better.
Alan, am I correct that your fix requires no changes from gexiv2?
Jim, as far as I understand that is correct. But my understanding of the internals of both gexiv2 and exiv2 are pretty minimal. Robin Mills accepted my patch into exiv2 as it passed their test suite. How would I now test that this tag can be written via gexiv2?
I would imagine the easiest way would be with the Python bindings. We don't currently have a command-line tool for gexiv2.
Does gexiv2 need some direct instructions to write as XmpBag instead of XmpText? With my patch exiv2 can write Xmp.lr.hierarchicalSubject as type XmpBag, but the gexiv2 python script I tried writes as type XmpText. Here is the script: #!/usr/bin/python3 from sys import argv, exit try: from gi.repository import GExiv2 except ImportError: exit('You need to install gexiv2 first.') if len(argv) < 2: exit('Please specify an image on the commandline.') # Note, these are equivalent: metadata = GExiv2.Metadata() metadata.open_path(argv[-1]) # metadata = GExiv2.Metadata(argv[-1]) tags = '1st|3rd|4th' metadata['Xmp.lr.hierarchicalSubject'] = tags if metadata['Xmp.lr.hierarchicalSubject.'] == tags: print('I just set the LR tags to %s.' % tags) else: print('There was a problem setting the LR tags.') # If you wanted to save your changes, call save_file: metadata.save_file()
> Does gexiv2 need some direct instructions to write as XmpBag instead of > XmpText? gexiv2 doesn't have any facility to write XmpBags, or at least doesn't have any explicit understanding of them. My understanding (which may be flawed) is that the user wrote a string of pipe-delimited text as string value and Exiv2 knew to convert that into an XmpBag. Am I incorrect?
Here is the command I used: ~$ exiv2 -M"add Xmp.lr.hierarchicalSubject XmpBag 1st|2nd|3rd" lr.test.jpg If I leave out the XmpBag, it gets written as XmpText. Exiv2 does not automagically know that a string should be an XmpBag. It appears to need that specified in all cases. I tested with other XMP properties, and it is the same. It seems weird, because if you look at properties.cpp in the exiv2 code base, it is full of fields explicitly defined as XmpBag. But to no avail, XmpBag needs to be made explicit in all cases. So, how does one enforce XmpBag use in gexiv2?
Oops, looking further, it appears Xmp.dc.subject DOES default to XmpBag. I suspect that is because it is defined as such in the xmpsdk. Xmp.lr.hierarchicalSubject is not.
(In reply to Alan Pater from comment #8) > So, how does one enforce XmpBag use in gexiv2? Let's get down to basics: when you add that "XmpBag" to the -M parameter for exiv2, what does that do? Use a different method, add an enum parameter to the write call, what? Once we know that, we can figure out if (a) gexiv2 can be coaxed to do that or (b) add a new function to gexiv2 for writing XmpBags.
You got me there! ;-) I'm not exactly an expert on the internals of exiv2, I just added the LR namespace and a couple of properties. That was a very simple patch. My coding skills don't go much beyond that. The reason I used XmpBag on the command line is because I followed examples from the exiv2 website. Copy Paste, nothing more.
It would be a huge help for me if you could investigate this some (or even just go to the Exiv2 forums and ask). it may be this is a simple fix for gexiv2, but the first step is knowing what needs to be done.
The command format is: set | add | del key [[type] value] For "add Xmp.lr.hierarchicalSubject XmpBag 1st|2nd|3rd", XmpBag is the type. the default SHOULD be determined by the key (Xmp.lr.hierarchicalSubject) but in this case that is not working. Perhaps due to a bug in exiv2? I don't know. Anyway, it looks like gexiv2 accesses exiv2 from the api which says that XmpBag is an unordered array. http://www.exiv2.org/doc/classExiv2_1_1XmpArrayValue.html That appears to have functions to access and manipulate the array. Is that a start?
I don't know if this is relevant, but I found a report on pyexiv2 about lr.hierarchicalsubject. They put in a workaround. http://bazaar.launchpad.net/~osomon/pyexiv2/pyexiv2-0.3/revision/330 PS: pyexiv2 is now py3exiv2. http://python3-exiv2.readthedocs.org/en/latest/index.html
Never mind, it is working now. The python script from Comment 6 does correctly create the XmpBag type without having to be explicit about it. --- My mistake was that I made a typo in the exiv2 patch. It seems that the following are not equivalent. Xmp.lr.hierarchicalSubject Xmp.lr.hierarchicalsubject
Alan, are you saying this ticket can be closed?
Yes.
Great. Thanks!