XnView creates consistent error/warning on print (Exiv2 command-line, Cygwin and GNOME Linux)
Added by Steve Wright over 11 years ago
I'm trying to clear an error that has consistently cropped up since using Exiv2 0.19.
If, in XnView, I have my metadata editing set to "Overwrite all current values" (Version 1.96 standard, Edit>Metadata>Edit IPTC data or ctrl-I by hotkey), change one or two tags or add info to a tag, then poll the file (exiv2 -pa foo.jpg) in the latest Exiv2, I get three lines with the following: Warning: Photoshop IRB data is not padded to even size.
A similar uneven tag-write error comes up with PhotoFiltre Studio X 10.1, which I have been able to fix by deleting the Exif.Image.Software tag (I even wrote a bash script to do just this, in case anyone's interested -- it runs equally well in Cygwin core's and Ubuntu 9.04 GNOME Terminal's BASH). I can't seem to puzzle out how to avoid or correct this error, however, without completely erasing the changed tags or involving Photoshop itself. There has got to be a less-destructive, less-time-consuming way to correct this error.
Please advise.
Steve Wright
Attached to this OP is an example file -- the very latest JPEG that gave the error, in fact.
Replies (2)
RE: XnView creates consistent error/warning on print (Exiv2 command-line, Cygwin and GNOME Linux) - Added by Andreas Huggel over 11 years ago
I don't get any error with the attached image. Is this what you're saying:
1. Add IPTC tags with XnView
2. Listing the newly added IPTC tags with exiv2 -pa (or PhotoFiltre Studio) results in a warning
That would simply mean that XnView doesn't serialize the IPTC correctly. You can probably fix this by forcing exiv2 to re-write the IPTC tags (by adding/deleting/modifying one).
-ahu.
RE: XnView creates consistent error/warning on print (Exiv2 command-line, Cygwin and GNOME Linux) - Added by Steve Wright over 11 years ago
Yes, that's what I'm saying. With the PF Studio error, it was their method of adding Exif.Image.Software that created it in every case. I've started threads on their forum to discuss correcting it in a future version, but to date none of the coders/maintainers seem inclined to do so. Not unreasonable, as folks who tend to use all GUI apps to annotate wouldn't encounter the error -- unless and until they ran into something that used Exiv2's C++ libs to add or edit, and in M$-land that doesn't seem very likely. On balance I'd say Pierre (XnView's creator) is much more responsive to things like this, but even he would be hard-pressed to track down this IRB serialization problem, and might have to recode a good part of his app to make any corrections.
So maybe I should write a script to write new data to those fields when that particular error is encountered?
Exiv2 in its current state of error-reporting makes it a little difficult to do so, but I could probably patch something together to "spank" those fields. I'd have to write something that involved the last-modified date, as that would give some clue as to which fields/tags/elements had new values put in and when. Unfortunately, unlike PF Studio, I know XnView doesn't self-promote in the Exif.Image.Software field, and I don't see anything in the Options dialogs to invoke that by default. So mod date would be the only thing to go by, and even there you're guessing.
Maybe I'll wait until you've patched error-reporting and then have another go at the issue.
Thanks for replying.
Steve Wright