Please restore copy XMP to IPTC function

[doug kerr]

Hi, Bogdan,

I would like to see the ExifToolGUI function IPTC: copy data to from XMP restored.

I typically will work up my IPTC metadata in the IPTC XMP  ("XMP") context. But then I like to copy the metadata to the IPTC IIM ("IPTC") form, as many recipients may have readers that only display the IIM form, not the XMP form.

Thanks.

Best regards,

Doug

[BogdanH]

Hi Doug,

I don't wish to encourage the usage of "old, abandoned, not maintained anymore" Iptc standard -and that's the only reason why this option (copy from Xmp to Iptc) is not included in GUI v4 -don't stop reading now! 

I have (much) better idea:
1. Go to ExifTool main page and download "Download Version n.nn" (right now, n.nn=8.64) -which is full ExifTool with source. Unpack the content and open main "Image-ExifTool-n.nn" folder. Now look after file "xmp2iptc.args" (there's also i.e "iptc2xmp.args" file) and copy that file into Windows directory.
2. Open ExifToolGUI and select files on which you wish to copy Xmp data to Iptc.
3. Click on button ExifTool direct and write the following command there:
-@ xmp2iptc.args
-and press Enter. You can see, that all "compatible" data was copied from Xmp to Iptc. Great, huh? 

If you wish to "remember" that command, then:
4. Click on Edit predefined button and write the name you like (for that command) into Command name field, i.e.: Copy from Xmp to Iptc -and click on ^Add new button.
That's it -next time, you can simply select that command from drop down list.

I hope, this was of some help for you.

Bogdan
PS: Phil, thank you for these args files -maybe you should include them into Windows executable..?

[doug kerr]

Hi, Bogdan,

I don't wish to encourage the usage of "old, abandoned, not maintained anymore" Iptc standard -and that's the only reason why this option (copy from Xmp to Iptc) is not included in GUI v4 -don't stop reading now!

I understand. That of course is my own preference. But . . .

I have (much) better idea:
1. Go to ExifTool main page and download "Download Version n.nn" (right now, n.nn=8.64) -which is full ExifTool with source. Unpack the content and open main "Image-ExifTool-n.nn" folder. Now look after file "xmp2iptc.args" (there's also i.e "iptc2xmp.args" file) and copy that file into Windows directory.
2. Open ExifToolGUI and select files on which you wish to copy Xmp data to Iptc.
3. Click on button ExifTool direct and write the following command there:
-@ xmp2iptc.args
-and press Enter. You can see, that all "compatible" data was copied from Xmp to Iptc. Great, huh?

Fabulous!

If you wish to "remember" that command, then:
4. Click on Edit predefined button and write the name you like (for that command) into Command name field, i.e.: Copy from Xmp to Iptc -and click on ^Add new button.
That's it -next time, you can simply select that command from drop down list.

Way cool! I'll try that.

Thanks.

Best regards,

Doug

[doug kerr]

Hi, Bogdan,

Way cool. Worked fine with two glitches:

• I got an invalid time format in IPTC(!) warning. Curious. I'll have to poke around a little.

• When I click on the ExifTool direct button, the app window doesn't expand vertically enough to accommodate the panel with the other buttons  - I just see the very tops of the buttons. (I have the app not-maximized, so it isn't a problem of them being blocked by the task bar.) I have a screen shot, but I have to mount it on my host so I can embed it in a post here (I guess) so maybe later.

But otherwise, it worked fine. Thanks.

Best regards,

Doug

[Phil Harvey]

PS: Phil, thank you for these args files -maybe you should include them into Windows executable..?

A good idea, but I don't know how this could be done.  I don't want to just add them to the .zip file because this would complicate things for the users, and I don't know of a way to add them to the .exe package.

• I got an invalid time format in IPTC(!) warning. Curious. I'll have to poke around a little.

I can help if you post the original XMP that caused this problem: exiftool -xmp -b a.jpg > out.xmp

Edit: Belay that request.  I figured out the likely problem:  XMP allows incomplete date/time values.  If the XMP date/time value does not contain a time (ie. only a year or date) then you will get this message when you try to copy it to an IPTC time tag.  Let me know if this isn't the problem.

I have to mount it on my host so I can embed it in a post here (I guess) so maybe later.

You should be able to add it as an attachment to a post here.  Attachments are downloadable by members only, and not viewed as inline images.

- Phil

[doug kerr]

Hi, Phil,

• I got an invalid time format in IPTC(!) warning. Curious. I'll have to poke around a little.

I can help if you post the original XMP that caused this problem: exiftool -xmp -b a.jpg > out.xmp

Edit: Belay that request.  I figured out the likely problem:  XMP allows incomplete date/time values.  If the XMP date/time value does not contain a time (ie. only a year or date) then you will get this message when you try to copy it to an IPTC time tag.  Let me know if this isn't the problem.

Almost certainly! The date in the XMP was date only, not date-time.

Does this mean that we try to make an invalid IPTC date? (Older versions of ExifToolGUI did this with no complaint, but maybe made something invalid in the IPTC.)

I'll do a little reverse engineering here.

The error message is a bit misleading!

I have to mount it on my host so I can embed it in a post here (I guess) so maybe later.

You should be able to add it as an attachment to a post here.  Attachments are downloadable by members only, and not viewed as inline images.

Good. Of course, inline would have been easier, and I regularly do that elsewhere (mount it on my server so it can be an inline image), but I was just too lazy today!

Thanks.

Best regards,

Doug

[Phil Harvey]

Hi Doug,

Does this mean that we try to make an invalid IPTC date? (Older versions of ExifToolGUI did this with no complaint, but maybe made something invalid in the IPTC.)

I'll do a little reverse engineering here.

The error message is a bit misleading!

They shouldn't write an invalid date.  I'm not sure why older versions didn't give a message.  What version of exiftool are we talking about and I can check this?

I agree the error is a bit misleading, but it is hard to be more specific because the conversion routine accepts just about anything and tries to pull a valid time out of it.  If it can't pull out a time, then it gives this message.  Here, it is trying to pull a time out of an XMP date/time value, but the IPTC time conversion routine of course doesn't know this.

- Phil

[doug kerr]

Hi, Phil,

Does this mean that we try to make an invalid IPTC date? (Older versions of ExifToolGUI did this with no complaint, but maybe made something invalid in the IPTC.)

I'll do a little reverse engineering here.

The error message is a bit misleading!

They shouldn't write an invalid date.  I'm not sure why older versions didn't give a message.  What version of exiftool are we talking about and I can check this?

Perhaps my comment wasn't explicit enough. I had not tried the ExifTool direct approach before. What I used to do was invoke the ExifToolGUI function IPTC: copy from XMP. That seemed to work fine, and no error message came to me in the process. ExifTool may well have issued one "to GUI".

I any case, I have created thousands of images in which the IPTC (that is, IPTC IIM) has a created date with no time component (which I guess is, strictly speaking, illegal).

In many cases, depending on the work flow, I have no idea what the created time is (for example, the Exif metadata may have already been lost or deleted). I just enter the date via ExifToolGUI and then blow all that over to the IPTC area when I am done.

I agree the error is a bit misleading, but it is hard to be more specific because the conversion routine accepts just about anything and tries to pull a valid time out of it.  If it can't pull out a time, then it gives this message.  Here, it is trying to pull a time out of an XMP date/time value, but the IPTC time conversion routine of course doesn't know this.

I understand - "Check engine soon".

Thanks.

Best regards,

Doug

[doug kerr]

Hi, Phil,

I note with interest that in the latest version I have of the IPTC-NAA IIM spec (Version 4, July 1999), Date Created and Time Created are two separate data sets ("fields"), both optional (per section 1.4).

Date Created is data set 2:55 (8 octets, ASCII numeric characters) and Time Created is data set 2:56  (11 octets, ASCII graphic characters), both in Application Record no. 2.

Thus it does not seem right to declare an error simply because there is no source data for one of them.

And my thousands of files are legitimate (at least in that regard)!

Best regards,

Doug

[Phil Harvey]

Hi Doug,

You are correct.  The date and time tags are separate in IPTC IIM, and one may exist happily without the other (ie. this is allowed by the spec).

Thus it does not seem right to declare an error simply because there is no source data for one of them.

Agreed, but the source is an XMP date/time tag, which may exist but without a time value.  Hence the warning when xmp2iptc.args tries to copy this to an IPTC time tag.

- Phil

[BogdanH]

Hi,

Just came from work and after quick reading here, my add:
When copying "similar" tags from Xmp to Iptc in "old" GUI, only one date related command was used:
-iptc:DateCreated<xmp-photoshop:DateCreated
-that is, Iptc:TimeCreated was not populated.
At that time, my though was, that if user manually entersDateCreated, he won't bother with time (say, exact time isn't of that importance) -especially because Xmp allows date only.
For the same reason, in "new" GUI, for manually entering DateCreated, there's only space for date value. However, if option copy from Exif:CreateDate is checked, then complete DateTime value is copied into Xmp:DateCreated.

From what I can see, Xmp2Iptc.args "behaves" as expected, except warning message about "Invalid Time format" is misleading in case, Time part is just missing in Xmp:DateCreated.

Bogdan

[doug kerr]

Hi, Bogdan,

Hi,

Just came from work and after quick reading here, my add:
When copying "similar" tags from Xmp to Iptc in "old" GUI, only one date related command was used:
-iptc:DateCreated<xmp-photoshop:DateCreated
-that is, Iptc:TimeCreated was not populated.
At that time, my though was, that if user manually entersDateCreated, he won't bother with time (say, exact time isn't of that importance) -especially because Xmp allows date only.
For the same reason, in "new" GUI, for manually entering DateCreated, there's only space for date value. However, if option copy from Exif:CreateDate is checked, then complete DateTime value is copied into Xmp:DateCreated.

From what I can see, Xmp2Iptc.args "behaves" as expected, except warning message about "Invalid Time format" is misleading in case, Time part is just missing in Xmp:DateCreated.

All makes perfect sense to me.

Thanks.

Best regards,

Doug

[BogdanH]

PS: Phil, thank you for these args files -maybe you should include them into Windows executable..?

A good idea, but I don't know how this could be done.  I don't want to just add them to the .zip file because this would complicate things for the users, and I don't know of a way to add them to the .exe package.

Yes, I know what you mean (just realized that). Anyway, I will mention usage of these args files in GUI manual as well.

Bogdan

[doug kerr]

Hi, Phil,

Just to get closure on this matter:

Is it your position that to receive error messages from ExifTool when using the xmp2iptc.args file  to do XMP -> IPTC copy when there is no Created Time in the XMP source is appropriate, or impractical to avoid, or something?

Thanks.

Best regards,

Doug

[Phil Harvey]

Hi Doug,

I believe this message is appropriate and informative when using a command such as:

exiftool -IPTC:TimeCreated="anything that doesn't contain a valid time" ...

It is probably still appropriate, but less easy to see what is going wrong when you do this:

exiftool "-IPTC:TimeCreated<XMP-photoshop:DateCreated" ...

And I think still appropriate, but even further removed from the actual source of the problem with a command like this:

exiftool -@ xmp2iptc.args ...

(which just uses "-IPTC:TimeCreated<XMP-photoshop:DateCreated" in the argfile to copy this value).

So my position is that the message is appropriate and impractical to avoid, but not necessarily as informative as one might like in this situation.  However, I think it is also impractical to tune the warning message for a specific case like this.

- Phil

[BogdanH]

Hi Phil,

I'll ask here, because it's related to discussion in this thread. Does something like this:
-iptc:TimeCreated<xmp:DateCreated -if Length(xmp:DateCreated)>10
...exist in Perl? You get the idea 

Bogdan

[Phil Harvey]

Hi Bogdan,

Yes, you can do this in Perl, but ExifTool doesn't have a feature to apply a condition when writing individual tags.

- Phil

[BogdanH]

Thank you, Phil. I didn't thing about args rule.

Bogdan

[BogdanH]

In case Doug comes along...

I've digged a bit and here's my idea about error message appearing in case xmp:DateCreated doesn't contain Time part:

First, you need to modify xmp2iptc.args file, by commenting particular line there:
...
# magically extracts time from a date/time value
# -IPTC:TimeCreated < XMP-photoshop:DateCreated
...

In GUI, enter the following command into ExifTool direct field:
-if (length($xmp:DateCreated)>10) "-iptc:TimeCreated<xmp:DateCreated" -execute -@ xmp2iptc.args -common_args -overwrite_original

It seems to work properly here, but try on non-sensitive files first 

Bogdan

[Phil Harvey]

In GUI, enter the following command into ExifTool direct field:
-if (length($xmp:DateCreated)>10) "-iptc:TimeCreated<xmp:DateCreated" -execute -@ xmp2iptc.args -common_args -overwrite_original

The -if is totally unnecessary because xmp2iptc.args accomplishes this anyway.  I think the only problem that Doug had was that xmp2iptc.args issues an "Invalid time format" warning, but it would with your command too (unless the GUI hides the warning).

- Phil

[BogdanH]

No, above I said, he should "comment" (thus, disable) -Iptc:TimeCreated < xmp.... line in args file, so this command is never executed. However, if my if statement is true, then this command will be executed additionally.
This way, warning message doesn't appear. Instead of that, "regular" message x files failed condition might appear.
At the end, I'm not sure, if that makes any difference for user. Probably, I was just exercising Perl commands in Exiftool

Bogdan

[Phil Harvey]

No, above I said, he should "comment" (thus, disable) -Iptc:TimeCreated < xmp.... line in args file

Sorry, I missed that.  I understand now.

- Phil

[dd-b]

Yeah, this topic is nearly 10 years old.

But the progression of XMP replacing IPTC (or not doing so) is a significant part of the topic of this thread, and it's still an issue.

My latest personal example is that Piwigo, one of the major open-source photo gallery web site packages, doesn't handle XMP data. So when Darktable puts the names of the people I tagged as present into the xmp:dc-subject field (that's from memory; I think it's somewhat related to the right name :-) ), Piwigo doesn't see them. So I'm looking at using an extra step, using Exiftool to fix that. The published file of tags to copy will work fine for that (as well as is possible given the differences between IPTC and XMP). But the bigger story is still there.

Piwigo is written in PHP. Checking the Piwigo forums and PHP docs, I believe they're using the iptcparse feature in PHP. So far as I can tell there is no corresponding feature to handle XMP format metadata. So...what I'm saying here is that, across however long it's been going on (more than a decade), the attempt to chase people into XMP has not been entirely successful. And that supporting IPTC is really quite important still for people trying to make actual use of free software to deal with photos with metadata locally and on the web.

It's my observation that the Adobe tools, Bridge, and Lightroom and Photoshop, seem to manage to provide access to the new fields while keeping the old fields populated. And that commercial online galleries like Flickr do, too. This may be starting to be a dividing line, where the better, commercial, tools handle this and the cheaper, open source tools do not. Which is not good, certainly for those of us who prefer to use open source software where possible (I'm entirely stuck in the Adobe tool chain, though, for fine printing of photos, and also for video editing, sadly).

I don't really know what exiftool in particular should (or can) do to make this situation better rather than worse; but I want to put it out there that the problem is a real problem, and not one that the field has moved past.

[Phil Harvey]

I don't really know what exiftool in particular should (or can) do to make this situation better rather than worse; but I want to put it out there that the problem is a real problem, and not one that the field has moved past.

ExifTool makes this situation better by providing an open source tool to allow you to easily move metadata from one format to another.  But this isn't really a function of the GUI (the board you posted in), but the exiftool application and the Image::ExifTool Perl library.

- Phil

[StarGeek]

It should be pointed out that, as per the sticky thread in this part of the forum, the exiftool gui has been unsupported for nearly 8 years.

I haven't tried it but you might take a look at the newer hvdwolf's jExifToolGUI.  They've been regular with updates.  I don't know if it can do this exact operation, but if not you could ask for such support in that thread.

[Phil Harvey]

If you want this function in ExifToolGUI, couldn't you just use -@ xmp2iptc.args in the "exiftool direct" box?

- Phil

[StarGeek]

If you don't already have the xmp2iptc.args file, you can get it from Github.

[dd-b]

This was the thread that most resembled what I was worried about (found by Google search), but I didn't look at where it was placed in the hierarchy, yeah, I see it's not really the right place. Still, people seem to have seen it, so I won't at this point go start another thread also.

[StarGeek]

On the command line, you could use this command to copy the data.
exitool -@ xmp2iptc.args /path/to/files/

You can find similar args files to copy between groups on GitHub.

[dd-b]

Yep, in the short run I'm going to be using something like that arguments file; either that one from the distro, or I'll make small mods if I run into issues with it interacting with some of my idiosyncratic uses of IPTC and XMP fields.

I've found a Piwigo plugin, now badly out of date, that lets it read XMP data as well as IPTC data, and the first layer of obvious problems running it in the current version of Piwigo are easily fixed (they mostly seem to be old code running into PHP changes and throwing warnings when they didn't used to). But forking it (it hasn't been updated in nearly a decade, the chance of the original author suddenly taking an interest again seems not something I should rely on) does leave me dealing with at least my own future problems with it, and to some extent other people's as well. (I could fork it and run my private copy but not share it, but that's not really how it's done!)

Yet another not ideal solution is to write a Perl script to move my rendered web-resolution versions of photos to the gallery server, and incorporate the metadata fixups there (so using the exif library in Perl rather than exiftool at the command line). There are other, file-naming issues I could handle there, which I'm currently handling manually, so that might be convenient.

(I had a 50 year career in software; I'm kind of used to my plans running into constraints in the tools environment every day or two. It still annoys me but it doesn't surprise me one bit.)