Exiv2

Steve

I always pipe the output from exiv2 through grep to do that (or egrep if necessary). On Windows I have Cygwin installed and that provides good emulation of the unix command-line tools.

exiv2 -pt foo.jpg | grep GPS

I'll leave Andreas to speak up for himself, however I'm not sure I see a great benefit in making the command-line more complex when the grep tool is so readily available on all platforms.

Robin

exiv2 -pt foo.jpg | grep GPS

That was the original thinking exactly. But this is UNIX philosophy and several users have asked for this feature in the meantime, so that I now consider adding it rather than embarking on a mission to spread UNIX philosophy among exiv2 users. It's probably quicker.

Besides, Robin, interesting to hear you're using Cygwin. Have you ever compiled exiv2 under Cygwin? I'd be interested to hear if that works. Personally, I'm using MSYS/MinGW here for the same thing - to get a usable command line interface and access to UNIX powertools also on Windows.

Andreas

Andreas Huggel wrote:

Besides, Robin, interesting to hear you're using Cygwin. Have you ever compiled exiv2 under Cygwin? I'd be interested to hear if that works. Personally, I'm using MSYS/MinGW here for the same thing - to get a usable command line interface and access to UNIX powertools also on Windows.

Andreas

Andreas,

Robin's not the only one. I also use Cygwin. Exiv2 0.19 was a smooth compile, too. In fact, I had more trouble with the install I did from source in Ubuntu Gnome 9.04 than I did with Cygwin. I tried compiling a modification of the exiv2comment.cpp sample file (that I'd successfully compiled with Cygwin's gcc a week or so ago) and, on first running the binary, the shell told me it couldn't find a certain ".so" file. So I went to the Ubuntu Forums and found out I could soft-symlink an .so file in /usr/lib with the name the exiv2 was "looking for." I did so, then ran the binary again with no further issues or complaints.

S.

Robin Mills wrote:

Steve

I always pipe the output from exiv2 through grep to do that (or egrep if necessary). On Windows I have Cygwin installed and that provides good emulation of the unix command-line tools.

exiv2 -pt foo.jpg | grep GPS

I'll leave Andreas to speak up for himself, however I'm not sure I see a great benefit in making the command-line more complex when the grep tool is so readily available on all platforms.

Robin

Robin,

I happened across your reply at the worst possible time, so I haven't been able to try your suggestion. How bad was it? As it happens, I'd been knocking my head against a problem with a bash script that, coincidentally or no, involved grep directly. Seems I couldn't get it to parse the tag value of a JPEG file's FixtureId. It kept giving me just the tag name. I was using -PInv for the option(s), but it wasn't until I applied a sed string to a pipe that I got the return I wanted. Then it wouldn't pass the cropped string with that value to the variable I was using to echo, until I prefixed the command string (a piped exiv2, grep and sed combination at the end-up) with a *$*.

The script (see attached) is specifically for changing FixtureId values in files that support IPTC. I think it's just about ready for prime-time, as they say, so I'll let you give it a go at your convenience.

S.

Thanks for posting that, Steve. I ran it on my Mac, and it worked. I found your discussion about this on LinuxQuestions: http://www.linuxquestions.org/questions/linux-newbie-8/bash-script-command-line-same-commands-different-returns-need-help.-786992/

I'm a little puzzled because I'm not sure what FixtureId is. Is it an IPTC field? Can you upload a suitable test file for your script?

If you'd like a comment about the script, I'd suggest you make it a command-line tool (and don't ask him to read from the keyboard). I'd suggest one script can be used to read or write with the following syntax:

fixtureid [pathname [new fixtureid]]
so:
fixtureid - reports syntax and quits
fixtureid pathname - reports the current value of FixtureId
fixtureid pathname 'a new value for the fixture id' - updates FixtureId

(however it's totally OK if you prefer not to follow my suggestion).

To answer Andreas question about building under MingW, I've never bothered to build with mingw on windows, because I thought you'd totally taken care of all of that. However it seems that Steve's been able to build this without mishap.

Robin

Robin Mills wrote:

Thanks for posting that, Steve. I ran it on my Mac, and it worked. I found your discussion about this on LinuxQuestions: http://www.linuxquestions.org/questions/linux-newbie-8/bash-script-command-line-same-commands-different-returns-need-help.-786992/

I'm a little puzzled because I'm not sure what FixtureId is. Is it an IPTC field? Can you upload a suitable test file for your script?

If you'd like a comment about the script, I'd suggest you make it a command-line tool (and don't ask him to read from the keyboard). I'd suggest one script can be used to read or write with the following syntax:

fixtureid [pathname [new fixtureid]]
so:
fixtureid - reports syntax and quits
fixtureid pathname - reports the current value of FixtureId
fixtureid pathname 'a new value for the fixture id' - updates FixtureId

(however it's totally OK if you prefer not to follow my suggestion).

To answer Andreas question about building under MingW, I've never bothered to build with mingw on windows, because I thought you'd totally taken care of all of that. However it seems that Steve's been able to build this without mishap.

Robin

Robin,

FixtureId is an IPTC field. It corresponds to "Event" in iView Media Pro, and to "JobId" in XnView. I've got a PDF file that lists a few applications and what they "label" the standard and extended IPTC v.4.0 metadata tags, so if you name an application that allows one to view IPTC fields I could probably look it up in this file and tell you what it's called. Of course, not being in journalism, I use it in a somewhat different way than how it was intended.

Coincidentally, I did manage to compile this script using shc, a generic script compiler. It was a smooth compile, once I puzzled out the name that Cygwin's gcc was giving to shc on compiling it. I needed to rename it from the basic, super-generic a.exe to shc.exe, after which I moved it into my PATH of course. So far I've run it on only one file, just to test out a "Yes-Yes-Yes-and-here's-a-string-to-write" sequence, and it works as well as the original shell script did when I uploaded it for you to try.

No keyboard input? That was part of the challenge I gave myself in writing the script in the first place. I asked myself the question, How many prompts does it take to do a job? and proceeded to answer it in the script. Saying as my own last Mac died of power-supply failure in 2008, and since then I haven't done much scripting at all, in BASH or anything else, it was good to get a feel for things as I knew them before I became a "refugee." (I even named the C: drive on this Windows box "Resurgam," Latin for "I will rise again." I have, after a fashion.)

S.

Robin Mills wrote:

Steve

I always pipe the output from exiv2 through grep to do that (or egrep if necessary). On Windows I have Cygwin installed and that provides good emulation of the unix command-line tools.

exiv2 -pt foo.jpg | grep GPS

I'll leave Andreas to speak up for himself, however I'm not sure I see a great benefit in making the command-line more complex when the grep tool is so readily available on all platforms.

Robin

Robin,

Just saw a flaw in that thinking with regard to grep. Let's say I have a folder with a good lot of jpegs whose names follow the pattern "image001.jpg", "image002.jpg", etc., all the way up to, for argument's sake "image199.jpg." I happen to know, having just used MS Expression Media on the lot a few days ago, that they all have my good friend the "FixtureId" field with at least some data in it. Just for the pure fun (?!) of it, I try to get exiv2 to give me the file names, field names and data in those tags, and print them out to a plain text file. So I issue the command:

echo -ne $(`exiv2 -PInt image*.jpg | grep FixtureID`) > image-events.txt

or something like it, and the result? An empty plain text file.

Now I'm sure I could write a short bash script, setting variables and values and passing them on to such things as awk and sed, which would probably work, but why should I (or anyone) have to take the time to do that when "for the same money" Andreas could write a tag "parser" or "picker" into exiv2 itself and we could all stick to the command line without resort to vim, nano, TextWrangler or Crimson Editor.

S.

Steve,

exiv2 -PInt image*.jpg | grep FixtureID

Isn't there a typo here - it's Id not ID, isn't it?

But in any case, you're right, it's not a big deal to add the required functionality to the utility. I've added it this afternoon in-between playing with the kids. So please check out the latest source code from the repository and test the new -g option and let me know if it does what you need. It lets you do things like this (the updated manpage will follow later):

$ exiv2 -g Iptc.Application2.Program digikam-example-d90.jpg
Iptc.Application2.Program                    String      7  digiKam
$ exiv2 -Pv -g Iptc.Application2.Program digikam-example-d90.jpg
digiKam

Andreas

Steve

Well, I think Andreas is offering to add something like that. My contribution was only to say that restrict the keys being listed with grep.

I suspect there a very simple alternative command (using find or xargs or for) to meet your needs, however we've really wandered into the land of unix shell scripting.

Andreas Huggel wrote:

Steve,

exiv2 -PInt image*.jpg | grep FixtureID

Isn't there a typo here - it's Id not ID, isn't it?

Andreas:
Saw that later. Too bad the "forum-ware" part of Redmine doesn't allow for coming back and editing "goofs and gaffes." Then again, if it did, it probably would be a lot more lagged (a la phpBB) in terms of how fast we got our email copies on subscribed, or "watched" as they're called here, threads.

Anyway, it was only after looking at the fife.sh script I attached for Robin two or three times that I recognized there was a typo in the command I referred to in my post above.

But in any case, you're right, it's not a big deal to add the required functionality to the utility. I've added it this afternoon >in-between playing with the kids. So please check out the latest source code from the repository and test the new -g option and let >me know if it does what you need.

To Robin:

I suspect there a very simple alternative command (using find or xargs or for) to meet your needs, however we've really wandered into the land of unix shell scripting.

And on that score, I've come up with an idea for another script that looks for any tags with data in a given file and gives the user the option of viewing the data in them by name. Though as I think about it more, it might work better as a python script or even done up in Perl, neither of which code do I have much more knowledge than that they are very popular and useful in these instances. The only code/coding/scripting I actually know is an odd smattering of command-line BASIC, HTML/CSS, and a little AppleScript. Plus I can sometimes tell whether when and why a Photoshop batch action isn't working the way I want it by looking at it in a text editor.

But now with the patch for the -g option, none or very little of the above might be necessary.

S.

Andreas Huggel wrote:

Steve,

But in any case, you're right, it's not a big deal to add the required functionality to the utility. I've added it this afternoon in-between playing with the kids. So please check out the latest source code from the repository and test the new -g option and let me know if it does what you need. It lets you do things like this (the updated manpage will follow later):

[...]

Andreas

I have to confess, I don't know how to "check out the source code." I downloaded the new source code and tried a command similar to the one shown here...
http://dev.exiv2.org/boards/3/topics/show/271#message-272
...using first "actions.cpp" and then "exiv2.cpp" in place of the "exivprint.cpp" mentioned in that threadand all I got was a long string of errors. Evidently I'm using the wrong command. I'm sure the lexiv2 option still obtains, but I'm not sure of where to put it in a command such as "./configure," "make," etc. There seems only to be a passing reference to it in one other thread on this forum. I'd Google it, but my luck in that direction has, as has been proven by my track record here - all four threads I've started have been on topics and looking for specifics that I couldn't find via Google -- that would, likely as not, just lead me back here.

BTW: I also discovered there is no "html" folder in the "doc" subfolder of the tarball for exiv2-0.19. There's an "index.html" that tries to redirect to the eponymous file inside that folder, but as it doesn't exist all one gets is a "Page not found" error. That was the first place I went, right after discovering that the command (with which I'd successfully made my one tweak of a sample code page into an executable) failed.

Hope you can help on the first part -- and soon; I'm anxious to try out the new option, "-g".

S.

But in any case, you're right, it's not a big deal to add the required functionality to the utility. I've added it this afternoon in-between playing with the kids. So please check out the latest source code from the repository and test the new -g option and let me know if it does what you need. It lets you do things like this (the updated manpage will follow later):

I have to confess, I don't know how to "check out the source code."

Just follow the link above, it's explained there.

-ahu.

Thanks for pointing that out, Andreas.

It took me awhile, saying as I had to add autoconf to Cygwin. When I first installed it, the shell still wouldn't see it so I repeated the same steps as I did on my Ubuntu box for the "ornery" .so file. Having had the Cygwin setup program give me both of the recent builds of gcc automake did raise the question, briefly, of which one to soft symlink. I tried the older-by-number first. It didn't have the -o option, so I trashed that one's soft symlink and made a new one for the newer-by-number version. That worked. After the usual Unix three-step dance (./configure, make, make install), I tested for the -g option, and found it was available. Again, thanks for adding it.

S.

Andreas,

Have you added the details for "-g" option usage to the man page yet? And how does that work? Do you put up a "master" page with changes to the site concurrent with updating the man.x file that goes out in the tarball, and have the folks who run manpage sites update at their leisure? Or do you make the change, publish the manpage in the repository here,and then inform the larger or more popular manpage sites (linux.die.net comes to mind -- it's the one I use quite often) that a revision has been made, giving them a choice between HTTP and TeX of which format to 'grab'?

In any event, the -Pv and -g in tandem are perfect for a shell script I've started working on. One of my GUI image viewers doesn't have IPTC FixtureId under any name in the list of fields it's able to read and display either in its Image Info summary window or its slideshow. So I've had to resort to copying the data from that field to Iptc.Application2.ObjectName, which this app does "see."

Of course, to do it on batches of files, I want to use exiv2, as there isn't yet -- and probably will never be -- such a narrowly-focussed field-to-field copying or cloning feature in any of my GUI apps, MSXM2 included. I recall back towards the start of this decade watching the slow deterioration, as I see it, of any given application of this class able to read in files (whole lists of files and tag data) generated by another application, and annotate according to file name and field. So I know I'll find no help for this in that corner. Even XML and XMP are too "slippery," as Adobe and Apple are frequently making changes to both to suit their more or less proprietary purposes. So I'm back to the command line, and all its quirks and foibles.

S.

Have you added the details for "-g" option usage to the man page yet?

Yes, just now. See r2028.

And how does that work? Do you put up a "master" page with changes to the site concurrent with updating the man.x file that goes out in the tarball, and have the folks who run manpage sites update at their leisure? Or do you make the change, publish the manpage in the repository here,and then inform the larger or more popular manpage sites (linux.die.net comes to mind -- it's the one I use quite often) that a revision has been made, giving them a choice between HTTP and TeX of which format to 'grab'?

For now the changes have been checked-in just like changes to the source code. With every release, the man page is included in the distribution. It's not on the exiv2 website and people publishing it on theirs have their own ways to detect changes and convert it into a format suitable for them.

-ahu.

Andreas Huggel wrote:

Have you added the details for "-g" option usage to the man page yet?

Yes, just now. See r2028.

And how does that work? Do you put up a "master" page with changes to the site concurrent with updating the man.x file that goes out in the tarball, and have the folks who run manpage sites update at their leisure? Or do you make the change, publish the manpage in the repository here,and then inform the larger or more popular manpage sites (linux.die.net comes to mind -- it's the one I use quite often) that a revision has been made, giving them a choice between HTTP and TeX of which format to 'grab'?

For now the changes have been checked-in just like changes to the source code. With every release, the man page is included in the distribution. It's not on the exiv2 website and people publishing it on theirs have their own ways to detect changes and convert it into a format suitable for them.

-ahu.

Andreas,

It appears that linux.die.net, freedom.dicea.unifi.it, and digipedia.pl are the only three man page sites "serving up" a man2html version of exiv2. I just did a 12-page Google search with "man exiv2" as my search string, and those were the only three to come up; all else were technical reviews, links back to the Wiki and Issues pages here, and some RPM and DEB index lists.

And since word-of-mouth (or word-of-keyboard) promotion is the traditional route of open-source software promulgation, you may want to read
this post [http://tinyurl.com/yghyb43] where I make mention of the recent cvs revision for the -g option. I hope I didn't overstate your receptiveness to new ideas.

S.

Andreas Huggel wrote:

Steve,

exiv2 -PInt image*.jpg | grep FixtureID

Isn't there a typo here - it's Id not ID, isn't it?

So please check out the latest source code from the repository and test the new -g option and let me know if it does what you need. It lets you do things like this (the updated manpage will follow later):

Andreas,

I took another look at the g option, and while I think it's great as a shortcut to return the value of a particular tag, it may be that it returns a little too much information. Lately, I've been polishing off a script to add three- and four-letter extensions to files by their actual filetype. Linux may not need them, but those other two, Mac OS X and especially Windows, seem to rely on them quite a bit. In so doing I re-acquainted myself with the -b (brief: no filename) option of the file command in bash. I think that was more what I had in mind.

It would certainly make it easier to copy one tag value to another field or tag, such as IPTC caption to JPEG comment or EXIF User comment to IPTC caption. The typical line returned by -g <tagname> file.jpg now still needs a bit of trimming to get just the "meat" of the tag copied. By this I mean: set to a variable that can be written back to the same file somewhere else in the metadata.

I just took a look at the updated manpage. I'm wondering if there's already something there, and because I've not yet used the n option mentioned --lines 137-42 of the manpage, first in context with -g then on its own as an option - I'm not seeing it. The -n wouldn't necessarily apply to anything IPTC, as it's a means of decoding by charset in the EXIF 'block.' Or am I not seeing that quite right, either?

Hope you can help with this.

S.
P.S.: In the other script, file -b turned out to be a blind alley, but file -R <comma>, cut -d <comma> (with alternate fields isolated), all inside a for-do-done loop worked like a charm.

Andreas,

I think I have it figured out. If I do, and this tests well with the same or similar results with other users' files, there should be no need to tweak the g option.

The "meat" of any data returned by -g <tagname> file.jpg consistently starts with the fourth field, using a single space as delimiter. So setting variables such as

caPshun=$(exiv2 -g Iptc.Application2.Caption exb0000-34-70806.jpg)
sendme=$(echo $caPshun | cut -d" " -f4-)

and then adding

exiv2 -c  "$sendme" exb0000-34-70806.jpg

effectively copies the IPTC Caption to the JPEG Comment header.

I also tried it with FixtureId-to-ObjectName, using similarly Little-Rascals/Our Gang-themed variables btw, and it worked just as well.

Now to make it more broadly-applicable, I intend to write a bash script that searches out Field A (let's say "Iptc.Application2.Caption" for example), and checks Field B (either Exif.Image.UserComment or a plain old ordinary -c JPEG comment header) for a value before copying the first to the second by way of one or two variables.

And I have the strong feeling this is only the beginning.

S.

Steve,

Copying of values from one field to another is an interesting use case; please keep us posted.

As for the script itself, remember that the -g option can be combined with the -P option, and that can be used to filter specific fields. As long as you process the files one by one, that should simplify your code further, you should be able to do without the 'cut' command.

-ahu.

Andreas Huggel wrote:

As for the script itself, remember that the -g option can be combined with the -P option, and that can be used to filter specific fields. As long as you process the files one by one, that should simplify your code further, you should be able to do without the 'cut' command.

-ahu.

Andreas,

I just tried that. I took a peek at the man page before proceeding, and saw that -Pv returns "plain Exif tag values." I have to say I was pleasantly surprised when my first guess at the 'proper order' of option tags, exiv2 -g <tagname> -Pv (file) worked without errors. And -Pv is an "older" function, so to speak. It was probably even in the version I tried when I emailed you back in May 2009 to ask (complain?) about "IPTC tag values running over themselves."

So now it remains to puzzle out precisely how to replace those cut commands in my script with the -Pv option. Shouldn't take much doing at all. It's all too true that cut in one shell or distribution can be a little more particular about its delimiters than the one in Cygwin or Ubuntu GNOME.

BTW: on the way to writing the script (which so far only takes FixtureId values and copies them to empty ObjectName tag spaces), I wrote another quickie bash script that does something very simple. So simple you'd think the original authors of iView Media Pro would have made it part of their application. In IVMP/MSXM, there is no cut-and-dry way to find out if a file has any annotation tags. But by employing the -pa option in exiv2, I wrote a script that runs through every file in a directory and returns "This one is," "This one isn't" kind of messages.

Thanks again for pointing me in a new (and simpler) direction.

S.

Andreas Huggel wrote:

Steve,

Copying of values from one field to another is an interesting use case; please keep us posted.

Andreas,

I "caved in" and SVN'ed the latest build. As I was installing it, I looked back at the "make" stage from time to time, and at one point in the process, I noticed a file pair being worked on: "metacopy.cpp" and "metacopy.hpp". Just a minute ago, I looked at the former in a text editor. It occurs to me that what I'm doing with these scripts is analogous to what metacopy.cpp does, except instead of copying the same tag between two files, I'm re-assigning and/or adding the same data to the same file.

At first I thought metacopy might be useful to what I was doing with these scripts, and it still may be. Where I get caught up is in how to tweak it to point it to a different field in the same file, test it for data, then add the raw string read from Tag A into Tag B, properly classed and formatted. For the time being, I'll stick with my scripting method.

S.

Andreas,

Maybe without knowing it I've chanced upon a variation of "metacopy" that's worth coding and compiling, at a user's prerogative, for copying values from one field to another. It would certainly take the need to know shell scripting out of the business. Perhaps one could call it "metaclone.cpp" (or "metaditto.cpp") instead of trying to add letters and punctuation to the existing metacopy.cpp.

I've had some time to consider this since my last post to this thread. Some time yesterday it occurred to me that the more functions that can be compiled at the user end of things into small (tiny?) executables, the easier it may be for some who are used to having otherwise quite complex tasks performed for them at a stroke, so to speak, on the command line. Consider how much work grepping, awking and trimming was saved when "rename" was added to the BASH (and other) shells. The code page examples point to ways to do this for a number of functions or sequences of functions and commands already. This idea just takes it one step further, plus it "lends" the speed of C++ to what otherwise might turn out to be a lagging, plodding process on some machines.

And if it should prove that "metaditto.cpp" might get in the way of something, or several somethings, in the compile-and-install process, then it might just be practical to leave it "out of the loop," so to speak; include it in the tarball but leave it in the /src subfolder ignored and unused until pointed out as another "example" on the website.

Hope these notions sound practical and worthwhile.

S.