Error: Bad format (0) for ExifIFD entry 16 - myfile.jpg

[Archive]

[Originally posted by unsolicited on 2009-10-20 01:33:45-07]

Code:

Huh?

Windows XP. As a test, perl exiftool -Software= myfile.jpg, returns:
Error: Bad format (0) for ExifIFD entry 16 - myfile.jpg
    0 image files updated
    1 files weren't updated due to errors

perl exiftool myfile.jpg, works fine.
perl exiftool -m -Software= myfile.jpg, no change from error above.
perl exiftool -D myfile.jpg, only reveals '   16 Color Space Data                : RGB' that seems to be of interest.

What am I looking for to fix this / nuke the offending entry?

Thanks.

[Archive]

[Originally posted by exiftool on 2009-10-20 11:28:36-07]

ExifTool is a bit more strict about EXIF errors when writing.
Please let me know if you have any questions or problems
after reading
https://exiftool.org/faq.html#Q20" target="_blank">FAQ
number 20.

- Phil

[Archive]

[Originally posted by unsolicited on 2009-10-20 18:51:43-07]

Code:

Thank you, yes, I had seen that and tried it and receive the same error.

That's why my question was more geared toward identifying the specific tag it was dying a horrible death on and then trying to clear that specific tag. e.g. which is entry 16? Be it hex or decimal, I see no entry 16.

May I suggest:
- indicate 16d, 16h, 0x16, or something, for newbs like me.
- some sort of descriptor for the entry so we know what we're looking for.

Can you confirm:
exiftool -unsafe -tagsfromfile        abc.jpg -all:all abc.unsafe.mie
exiftool -all= abc.jpg
exiftool -unsafe -tagsfromfile abc.unsafe.mie -all:all        abc.jpg

Is the same as:
exiftool -all= -tagsfromfile @ -all:all -unsafe abc.jpg

i.e. I'd like to dump the tags before / after and see the difference(s) to identify what did it in in the first place.

Interestingly:
exiftool -all = abc.jpg
- left quite a bit of info in place.
exiftool -Software= abc.jpg
- did not clear the entry. But this line is what it complained about originally.
exiftool "-Software=" abc.jpg
- returned me to the original error.

More confusing ... I don't have a FILE_original file.

I must be completely misunderstanding something.

Finally: exiftool -unsafe -tagsfromfile abc.jpg -all:all abc.unsafe.mie
    and: exiftool         -tagsfromfile abc.jpg -all:all   abc.safe.mie
' produce the same output, at least according to fc /b and windiff.

Using: exiftool -tagsfromfile abc.jpg -all:all -unsafe abc.unsafe.mie
produces the same output, according to fc /b, yet the file is 20 bytes bigger, according to dir. windiff shows the difference in a binary area at the top.

No doubt you're not surprised at the different command line results. (-unsafe before/after -tagsfromfile)

A visual glance of the binary difference seems like the unsafe has a newline in it. I don't see the 20 byte difference, but I haven't counted. I've no doubt it's there.

I've also no doubt that my issue here is all my learning curve. But then, that's why I've come here seeking help! (-:

I've used various programs on this file, my guess is Adobe Photoshop Elements 1.0 has corrupted something and exiftool is choking on it. Are there known issues?

So, looking to:
- dump tags first
- fix the file such that exiftool can operate
- re-load the tags
- dump tags again
- diff the two, and HOPEFULLY identify which stupid thing I or some utility did so I can stop doing this to myself.

Thanks kindly!

[Archive]

[Originally posted by unsolicited on 2009-10-20 18:54:15-07]

Correction: Photoshop Elements 3.0, not 1.0, if it matters.

[Archive]

[Originally posted by unsolicited on 2009-10-20 19:18:13-07]

Code:

Thank you, yes, I had seen that and tried it and receive the same error.

That's why my question was more geared toward identifying the specific tag it was dying a horrible death on and then trying to clear that specific tag. e.g. which is entry 16? Be it hex or decimal, I see no entry 16.

May I suggest:
- indicate 16d, 16h, 0x16, or something, for newbs like me.
- some sort of descriptor for the entry so we know what we're looking for.

Can you confirm:
exiftool -unsafe -tagsfromfile        abc.jpg -all:all abc.unsafe.mie
exiftool -all= abc.jpg
exiftool -unsafe -tagsfromfile abc.unsafe.mie -all:all        abc.jpg

Is the same as:
exiftool -all= -tagsfromfile @ -all:all -unsafe abc.jpg

i.e. I'd like to dump the tags before / after and see the difference(s) to identify what did it in in the first place.

Interestingly:
exiftool -all = abc.jpg
- left quite a bit of info in place.
exiftool -Software= abc.jpg
- did not clear the entry. But this line is what it complained about originally.
exiftool "-Software=" abc.jpg
- returned me to the original error.

More confusing ... I don't have a FILE_original file.

I must be completely misunderstanding something.

Finally: exiftool -unsafe -tagsfromfile abc.jpg -all:all abc.unsafe.mie
    and: exiftool         -tagsfromfile abc.jpg -all:all   abc.safe.mie
' produce the same output, at least according to fc /b and windiff.

Using: exiftool -tagsfromfile abc.jpg -all:all -unsafe abc.unsafe.mie
produces the same output, according to fc /b, yet the file is 20 bytes bigger, according to dir. windiff shows the difference in a binary area at the top.

No doubt you're not surprised at the different command line results. (-unsafe before/after -tagsfromfile)

A visual glance of the binary difference seems like the unsafe has a newline in it. I don't see the 20 byte difference, but I haven't counted. I've no doubt it's there.

I've also no doubt that my issue here is all my learning curve. But then, that's why I've come here seeking help! (-:

I've used various programs on this file, my guess is Adobe Photoshop Elements 1.0 has corrupted something and exiftool is choking on it. Are there known issues?

So, looking to:
- dump tags first
- fix the file such that exiftool can operate
- re-load the tags
- dump tags again
- diff the two, and HOPEFULLY identify which stupid thing I or some utility did so I can stop doing this to myself.

Thanks kindly!

[Archive]

[Originally posted by unsolicited on 2009-10-20 19:43:59-07]

Code:

PLEASE DISREGARD MY PRIOR RESPONSES TO PHIL, IN FAVOUR OF THE BELOW.
- FAQ 20 failed as I was using a .bat file, and the '-all=' became '-all' and I didn't notice.
  - thus my first two responses.
- going back in firefox resulted in a duplicate response being re-entered.
  - a CPAN::Forum usage error on my part.

Thank you, yes, I had seen that and tried it and receive the same error.
[- NOTE: In hindsight, this is because -all= got munged into -all, so of course it didn't work.]

That's why my question was more geared toward identifying the specific tag it was dying a horrible
death on and then trying to clear that specific tag.
e.g. which is entry 16? Be it hex or decimal, I see no entry 16.

May I suggest:
- indicate 16d, 16h, 0x16, or something, for newbs like me.
- some sort of descriptor for the bad entry so we know what we're looking for.
  e.g. If you put out the contents of the bad entry, even in binary, we can decide we don't
       care, run the repair, and just get on with our day. Or, we can decide we do care,
       and reapply that entry (probably correctly), after repair.
  Caveat: There may be more than one bad entry. So we'd have to re-iterate removing the bad
          entry, if we could, try the change again, and either succeed, or fail and go around
          again until all bad entries have been identified.
  Question for the more experienced users ... is this useful in practice? i.e. If your experience
          says only bad entries cause grief, and one never cares, then I should just go ahead and
          run the repair?
  Comments?

Can you confirm:
exiftool -tagsfromfile abc.jpg -all:all -unsafe abc.unsafe.mie
exiftool -all= abc.jpg
exiftool -tagsfromfile abc.unsafe.mie -all:all -unsafe abc.jpg

Is the same as:
exiftool -all= -tagsfromfile @ -all:all -unsafe abc.jpg

And that the position of -unsafe in the arg list is absolutely critical?
i.e. -unsafe before -all= will get one nowhere?
(Should a warning be generated on such usage?)

I'm looking to dump the tags first, repair the file, re-load the tags, dump tags again, then diff
the tag dumps, and HOPEFULLY identify which stupid thing I or some utility did so I can stop doing
this to myself.

Am I going about this the correct way. And, in more experienced users experience, am I really
likely to care about whatever exiftool is choking on. Just clear it out and get on with my day?

I've used various programs on this file, my guess is Adobe Photoshop Elements 3.0 has corrupted
something and exiftool is choking on it. Are there known issues?

Thanks kindly!

[Archive]

[Originally posted by exiftool on 2009-10-21 00:46:42-07]

I see how "entry 16" is ambiguous. If you use the -v
option, the IFD entries are numbered sequentially.  This indicates
entry number 16.

If you want to see the bad entry in binary format, I suggest using
the -htmldump option.   This option is very good at
diagnosing EXIF problems.

If you can recover the bad entry, then this is of course the best
option.  But you will have to do a bit of sleuthing with -htmldump
and poking with a hex editor to fix something like this.  The repair
strategy outlined in FAQ 20 is not ideal, because at a minimum the
corrupted entry will be lost, and maybe more.  But it is a reasonable
compromise because is it much simpler and may be applied to all
types of different problems. I don't know of any specific issues with
Elements 3.0.

Copying the tags via a .MIE file should be the same as doing it all in
one step.  I ran a test and the results were binary identical using
either technique.

The position of -unsafe is not critical except that it must
come after the -tagsFromFile option.  The order
of operations is a bit tricky when batch processing like this since in
general the -tagsFromFile @ tags are processed after all
other options on the command line (since most arguments are
processed once when the command is entered but in this case
the copying must be delayed since the source file is not known
until just before the target file is processed).

- Phil

[Archive]

[Originally posted by unsolicited on 2009-10-21 06:47:55-07]

Code:

Thanks for that.

It sounds like -unsafe is an error if -tagsFromFile is not present, and an error if it appears
beforehand.

I'm going to have a few dozen files to work on. It will be interesting to see if the corruption
repeats itself or is a one-off. If it repeats, then I'll have to sleuth the offending application.

<sigh>