What does this error message mean? (while trying to add copyright info)

[pb]

I'm trying to add copyright info to a bunch of tif files that came from a Nikon slide scanner, to EXIF, IPTC, and XMP.

The command line is:

exiftool -overwrite_original_in_place -P -m -v0 -IFD0:Artist="me" -IFD0:Copyright="(c) Copyright by me" -iptc:By-line="me" -iptc:CopyrightNotice="(c) Copyright by me" -xmp:Creator="me" -xmp:Rights="(c) Copyright by me" *

where, "me" is actually my name, but I don't want it posted on the internet.

(I'm running it from a hairy bat file, but I'm pretty sure this has nothing to do with the bat file.)

I get this error message:

Code Select Expand

Warning: Bad format (0) for NikonScanIFD entry 0. IFD dropped. - 71930-SL-Sheet 1-001.tif

When I look at the file, all the metadata fields I wanted to change are what I wanted them to be, and without a thorough comparison, all the pre-existing metadata fields appear to be there and the same.

So, I don't actually know whether the error message relates to the EXISTING metadata, or the metadata I am asking exiftool to write.  I.e., which format is bad, what I'm asking for, or what is already there?  Also, I don't know what has been "dropped."

I might add that these tif files are multipage, with 2 pages (the second page is a preview image).

BTW, I could not find a listing of error messages in the exiftool online documentation.  So, if one exists, can you provide a link?

This is for exftool 8.87 on windows xp.

Now, I should also add that this scan data comes from a scanning service, and was given to me as tif, not nef, so I can't be entirely sure what was done to the output of the scanner before it was given to me, although supposedly the answer is "nothing".  BTW the EXIF data shows the scanner model as "Nikon SUPER COOLSCAN 5000 ED" and the software as "Nikon Scan 4.0.2 W", which agrees with the maker notes, and I know for sure that earlier versions of that software can output tiff directly, since I have used them myself.

Thanks.

--peter

[pb]

More info:
Apparently it's an EXISTING item it doesn't like.  The IFD0 entry "RowsPerStrip" is what exiftool is dropping from the metadata that it writes.  The value of this tag appears to be the same for all the files I'm interested in, but the value that exiftool prints for x in

Code Select Expand

"Bad format (x) ..." varies.  Another one I looked at it was 389.

However, when asked to simply print all metadata, exiftool doesn't complain and happily outputs the content of that field.  Should it have complained?  Is there a way to have exiftool make the complaint when it's only reading?

[pb]

And, yet more info.

Sleuthing around, it appears that the scanning people rotated a couple of images using unknown software.  Other images do not appear to show the problem.  So, it is probably some bad software that caused the damage.  However, it is still unclear to me why exiftool should complain when I ask it to write but not tell me something is wrong when I only ask it to read.

--peter

[Phil Harvey]

Hi Peter,

This is a very common error since few software packages know how to correctly preserve the NikonScanIFD.  Luckily though, this IFD doesn't contain anything really useful.

You mentioned that ExifTool drops the IFD0:RowsPerStrip.  I think you must be mistaken here.  ExifTool will not do this.

In general, more validation is done when writing.  Errors when reading are sometimes just ignored.

- Phil

[pb]

Hi Peter,

This is a very common error since few software packages know how to correctly preserve the NikonScanIFD.  Luckily though, this IFD doesn't contain anything really useful.

You mentioned that ExifTool drops the IFD0:RowsPerStrip.  I think you must be mistaken here.  ExifTool will not do this.

In general, more validation is done when writing.  Errors when reading are sometimes just ignored.

- Phil

As usual, you are absolutely correct.

It appears that the scanner folks' software that screwed up the NikonScanIFD is the one who dropped the IFD0:RowsPerStrip.  I was apparently looking at the wrong file for the "before" and comparing it to the "after" for one of the ones I processed with exiftool, because now when I check the "before" files they sent me on a CD, the two files that exiftool doesn't like are already missing the IFD0:RowsPerStrip datum, and I don't think the gremlins got to that CD, because it was in a gremlin-proof jewel case.

However, your answer does bring up a feature request, if I interpret your answer correctly.  Namely it would be nice to have some kind of -strict option when reading metadata, analogous to similar switches on compilers, that would spit out everything that's wrong with the metadata before you actually do a run writing stuff.  In this case, the files are about 133 MB, so even though everything is reversible, it can be rather time-consuming if the whole file has to be written in addition to being read, particularly if you're writing a hundred of them or a few hundred.  (And I have other scanner files that are over 200MB...)

[Phil Harvey]

Hi Peter,

I never intended for ExifTool to be a validation tool, even though many people seem to use it in this context.

However, I'll think about your request.

- Phil

P.S.  I missed your question about the error message documentation.  They aren't documented anywhere.

[pb]

Hi Peter,

I never intended for ExifTool to be a validation tool, even though many people seem to use it in this context.

However, I'll think about your request.

A feature that would provide equivalent functionality, without claiming to be an exhaustive validator, would be a -dryrun option, which would pretend to write files, but not actually write them.  That's probably easier to implement, too, if it doesn't already exist.

Although I guess I could set the output to stdout and redirect to /dev/null or nul, while keeping stderr, though that would not pick up errors relating to the output location, like a read-only directory, or the wrong directory.

--peter

[Jarb]

A feature that would provide equivalent functionality, without claiming to be an exhaustive validator, would be a -dryrun option, which would pretend to write files, but not actually write them.  That's probably easier to implement, too, if it doesn't already exist.

+1 for a -dryrun option! I've been studying the command line for two days and just got up the nerve to execute exiftool to update 20,000 jpg files. I'm holding my breath that it's doing the right thing. (I did all that I could think of to figure out out, but -dryrun would have been nice.)

[Phil Harvey]

If you don't use the -overwrite_original option, then you have a built-in way to undo any changes (other than moving or renaming files, which have a "TestName" dry-run feature).  Use -restore_original to un-do your changes back to before exiftool touched the files.

- Phil