Test File Args file

[StarGeek]

This is the Arg file I use to create the test file I use to see what metadata various programs use.  I originally used it to test the Windows Properties->Details tab, thus the name. edit: now changed

In most cases the tag will be filled with the name of the tag if possible (e.g. XMP-dc:Description is filled with the value "XMP-dc:Description"), otherwise with a unique value compared to similar tags e.g., EXIF:ISO has a different value than XMP:ISO.  This is especially important with the various date/time tags.

The command to use it would be something like:
exiftool -@ /path/to/MetadataTestFile.args TestFile.jpg
and then you'll have a test file with more metadata than you probably need.

Edit:

• 2019-06-18: Updated to version 1.03, some minor tweaks, a few tags removed, removed duplicate line
• 2020-10-04: Added small jpeg with all the data already embedded, needs to be unzipped

[Phil Harvey]

That looks useful.  Perhaps we should make this topic sticky?

But I have three issues with the name of the file.

1. The "Windows" in the name makes it seem like it may not be useful for other platforms.

2. The leading "!" makes it a bit awkward to use on Mac/Linux ("!" must be quoted).

3. Argument files in the ExifTool distribution have the extension ".args".  It would be good to be consistent.

- Phil

[StarGeek]

Any suggestions on a new name?  "MetadataTestFile.args"?

I used the exclamation point to make it first in my directory listing so it was easier to find in my increasingly messy test file directory.

[Phil Harvey]

Any suggestions on a new name?  "MetadataTestFile.args"?

Sounds great!

- Phil

[StarGeek]

Ok, name changed and thread stickied.

[colink]

@StarGeek

Thanks for creating this file - I am glad my suggestion for a test file / image was useful :-)

I am getting an error (Windows 10).
I created a new image named TestFile.jpg
Put MetadataTestFile.args in the same folder (ExifTool is also in the same folder)

run the following command
exiftool -@ MetadataTestFile.args TestFile.jpg

I get the error -  Error opening arg file MetadataTestFile.args

Am I doing something wrong?

Thanks ColinK

[Phil Harvey]

Hi Colin,

The args file must be in the current working directory unless you specify a path as in StarGeek's example command.

You can avoid having to type the path by dragging and dropping MetadataTestFile.args onto the cmd window.

- Phil

[colink]

Thanks again Phil

Sorry, my silly mistake (as usual) - I had previously worked in a different folder and forgot to do cd- "current folder"

ColinK

[mpegleg]

StarGeek. Windows doesn't like your Arg file. It cries Error 0x80070216!!!!

I get this "interesting" Windows error, when I try to clear the XPComments and attempt to save it from the Properties box:

[StarGeek]

Ooohhh, interesting.  You have a people entry.  I never had that.  Either Windows has updated it's metadata reading or your version does something different than the US version.  (edit: I have it as well, time to update my other thread)

I'll have to check on this, as I haven't kept this version up to date.  I had to remove a couple of tags because they would cause errors in other things as a simple string wasn't really allowed.

Edit: Ok, I see why I never encountered this.  I never bothered to try and edit the test file through Windows.  I'm not sure if it's worth trying to figure out which of the 1,400 or so tags is causing this, as this is only for testing purposes, you aren't supposed to have all this data for "real" files.  I'll give it some quick testing to see if I can narrow it down, but I don't think I'll put a lot of effort into fixing this.

[StarGeek]

What the bloody hell!

I decide to try and be methodical about figuring this out.  So I remove the first two hundred lines and see if the error goes away.  Cool, that does it.  So the error must be in the first two hundred lines, right?  Update the test file using the first two hundred lines and... no error.  Run it with the last 1200 lines, no error.

Ok, more testing.  Remove this, remove that, intermittent errors.  Oh, remove the GPS section, no error, that's were the problem must be, right?  Run the GPS section by itself, no error.  What the hell!

Start over, add 100 lines at a time. No errors until I add lines 901 to 1,000.  Aha!  There error must be there!  Test just lines 901 to 1,000.  No error.

Start removing some individual tags between 901 and 1,000.  It starts working.  Add those tags back in.  It... works?  Start over, remove lines 1,014 to 1,020.  It... works?  Those are XMP tags, same as the ones I was removing in the 900 to 1,000 range.  Go elsewhere, remove a handful of XMP tags, and it works.

Ok, I think this is a problem with the way Windows is parsing XMP data, not an actual mathematical error in the metadata itself.  You can "fix" it by removing about 10-20 XMP tags from the arg file.   Or just not edit the test file using Windows

[mpegleg]

Oooh. Sorry. Didn't mean to give you a headache over it. lol

I was just curious about the error message that was generated. I certainly don't need to use it at the moment.

[Phil Harvey]

I suspect this is a bug in the way Windows handles the extended XMP in JPG files.  (The generated XMP doesn't fit in a single JPEG segment, so an extended XMP segment is used.)  My guess is that it wouldn't be a problem for a TIFF file.

Note that I get this warning when I use your argfile:

"Warning: Argument "XMP-EXIF:ApertureValue" isn't numeric in numeric gt (>) in XMP-exif:ApertureValue (ValueConvInv)"

Due to this line in the file:

-XMP-EXIF:ApertureValue=XMP-EXIF:ApertureValue

- Phil

[StarGeek]

"Warning: Argument "XMP-EXIF:ApertureValue" isn't numeric in numeric gt (>) in XMP-exif:ApertureValue (ValueConvInv)"

Interesting.  I don't get that, but I also noticed that I have that line listed twice.  One that sets it to 1.0 and the one you list.  But easy enough to fix

[StarGeek]

I suspect this is a bug in the way Windows handles the extended XMP in JPG files.  (The generated XMP doesn't fit in a single JPEG segment, so an extended XMP segment is used.)  My guess is that it wouldn't be a problem for a TIFF file.

You are correct.  Tried on a Tiff file and there was no error.

[StarGeek]

Added a small jpg with all the data embedded for ease of use.  It needs to be zipped due to the security checks of the forum.

[blue-j]

Thanks so much for making this file!!!  This will leap us forward!  : )

- J

[ScannerBoy]

Resurrecting this thread, if that is OK?
Just came across it, as I was attempting to write metadata to some of my files and wanted to see if I understood the process.
The data covered looks very comprehensive, but it seems to me that none of the alternate language possibilities, or UTF-8 outside the plain ASCII range, are covered.
I may well have missed those as I am much a newb on the subject, but it is of major interest to me since my main application is for genealogy and 'foreign' languages seem inevitable.

The best place to locate which tags can accept such 'esoteric' data would probably be the comprehensive list on the Exiftool pages, but it is the proper application for writing the data which, at this stage, is not at all obvious to me.

It seems that images with such strings/data are rather scarce and hard to find.
Running under Win 10, ET 12.15

[StarGeek]

but it seems to me that none of the alternate language possibilities, or UTF-8 outside the plain ASCII range, are covered.

No, they're not part of it.  I use this test file to see what tags that a program can read, not to see if they can read alternate languages.  It figures out data like this

The best place to locate which tags can accept such 'esoteric' data would probably be the comprehensive list on the Exiftool pages, but it is the proper application for writing the data which, at this stage, is not at all obvious to me.

It seems that images with such strings/data are rather scarce and hard to find.

I'm not sure what the question is here.

[ScannerBoy]

No, they're not part of it.  I use this test file to see what tags that a program can read, not to see if they can read alternate languages.  It figures out data like this

Not trying to be difficult, but those alternate languages are an important part of the standards, and if these were covered by a 'test' program or data set, it would make it much more valuable

I'm not sure what the question is here.

It is more of an explanation, rather than a question, but if anyone can point me to either sample images or more details, I would be very grateful.
Frustratingly enough, even the IPTC sample images stick to plain ASCCI text strings
See: https://www.iptc.org/std/photometadata/examples/

[StarGeek]

Not trying to be difficult, but those alternate languages are an important part of the standards, and if these were covered by a 'test' program or data set, it would make it much more valuable

This file isn't meant to test standards.  It's basically a quick and easy FAQ #3 test file.  It already contains far more tags than most people will ever use.

And the lang-alt are rarely used by most people.  The only place I've seen them used is GettyImages and even then it's pretty rare.  And if someone needs to test lang-alt tags, it's easy enough to create a test.  Just take any XMP tag that is listed as lang-alt writable, add a dash and a ISO 639 language code.  For example
exiftool -Description-fra="French Description" file.jpg

See the 5th paragraph on the XMP tags page.

The lang-alt tags are extremely fragile, though.  I don't know of any program that allows editing of them.  A quick test with Adobe Bridge showed that in any change to the main tag caused the lang-alt tags to be overwritten with the new data.  I don't know if other Adobe products will do the same or not.

It is more of an explanation, rather than a question, but if anyone can point me to either sample images or more details, I would be very grateful.
Frustratingly enough, even the IPTC sample images stick to plain ASCCI text strings

I believe FAQ #10 will cover this.

[ScannerBoy]

This file isn't meant to test standards.  It's basically a quick and easy FAQ #3 test file.  It already contains far more tags than most people will ever use.

Agreed, but it is very useful for that purpose and I am very pleased to have found it. Thank you for setting it up & posting it.

And the lang-alt are rarely used by most people.  The only place I've seen them used is GettyImages and even then it's pretty rare.  And if someone needs to test lang-alt tags, it's easy enough to create a test.  Just take any XMP tag that is listed as lang-alt writable, add a dash and a ISO 639 language code.  For example
exiftool -Description-fra="French Description" file.jpg
See the 5th paragraph on the XMP tags page.

I will certainly work with this

The lang-alt tags are extremely fragile, though.  I don't know of any program that allows editing of them.

That is at the root of my problem. I do need the facility and have looked a fair bit, but without much luck.
Some programs claim to handle these type of strings, but it seems the command line version of Exiftool is about the only one I have found reliable enough to use as my 'standard' - but see below

A quick test with Adobe Bridge showed that in any change to the main tag caused the lang-alt tags to be overwritten with the new data.  I don't know if other Adobe products will do the same or not.

Yes, I have had my issues with the Adobe toolkit over the very same issues.

I believe FAQ #10 will cover this.

Thank you, yes it does explain a lot.
At the same time, I realize that I have to learn a whole lot myself and working under Windows is a severe handicap, especially with respect to these language and encoding issues.
Even running Exiftool at the command prompt is very confusing and sometimes downright wrong in this respect, because both the plain DOS box and Powershell are very deficient when it comes to handling foreign character sets.
If it weren't for the excellent debugger of MSVC, I am sure I'd be running some Linux flavor.
Still looking for alternatives to Powershell and I have experimented some with M$'s latest shell(s), but without much luck so far.