REQ: Adapt -g option for multi-entry tags (IPTC Keywords, Suppl. Categories, etc.)
Added by Steve Wright about 11 years ago
Hi.
The -g option in command-line Exiv2 is great, but it has one shortcoming that I've come to notice over the past few weeks. With tags such as those mentioned in my Subject line, it only returns the first found of that label or type. If the intended keywords list of a group of image files is- Abraham
- Lincoln
- Springfield
- Washington
...and the user wants to know whether or not all his Abe Lincoln-related pictures have both "Springfield" and "Washington" as keywords, using the -g option in the current and most-recent versions of Exiv2 will not help, as an
exiv2 -g Iptc.Application2.Keywords -Pv
will only return
Abraham
Could the -g option be modified to iterate over any data matching a particular class of tag (EXIF, IPTC or XMP) and return all the entries it finds for a particular tag "type" or "label," just as a matter of course? That way, multi-entry tags like IPTC keys and supplemental catgeories are treated no differently from single entry fields like Exif.Image.ImageDescription or Xmp.photoshop.AuthorPosition. And in the end-up, it becomes more of a "true grep" than it is now, alimo.
Steve W.
Replies (2)
RE: REQ: Adapt -g option for multi-entry tags (IPTC Keywords, Suppl. Categories, etc.) - Added by Andreas Huggel about 11 years ago
That can be considered a bug, I've opened #727 for this. Thanks for reporting this issue.
Andreas
RE: REQ: Adapt -g option for multi-entry tags (IPTC Keywords, Suppl. Categories, etc.) - Added by Steve Wright about 11 years ago
It might be a bug, but I recall the thread in which I suggested the feature. The "-g" option has been around for awhile (it was in developer snapshot 0.19.1, as I commented in some other recent posts). The kind of tags and entries I was looking to isolate more easily than with "-pa" options, and then "cut"-ting and "grep"-ping in BASH, were indeed prime examples of "monogamous metadata," to coin a phrase: the kind that only had one entry possible, like Caption, Source, Date-Time-Digitized, etc. So it's very easy to understand that in coding "-g", it didn't occur to you that "one and only one" in 1:1 fields would translate to "only the first" in multiple-item tags.
I hope the fix takes into account my point about "equal iteration" of all the fields: treating a tag or key the same way, whether that tag is monogamous or multi-line or no, pretty much ensures that the user gets to see "everything that's there," A true grep, as I said before, and one shuffle-step further away from having to use the command-line for the developers who work Exiv2 into their apps and utils.
Steve Wright