http://www.perlmonks.org?node_id=809696


in reply to Re^2: XMP, Image::ExifTool, strawberryperl
in thread XMP, Image::ExifTool, strawberryperl

Thanks for the extra information.

Just to point out that one obvious difference is that the linux box is running Image::ExifTool version 7.30, whilst windows is running a more recent 7.89. This is a possible factor.

You could experimentally try backing out your Windows version using Image::ExifTool 7.30 from backpan, just to confirm this, or rule it out.

Replies are listed 'Best First'.
Re^4: XMP, Image::ExifTool, strawberryperl
by mrkjell (Initiate) on Nov 27, 2009 at 10:24 UTC
    That is a good tip. I will try to reproduce with 7.30. Other differences I have found:
    1. Block start with different chars:: Linux: HEX ASCII FF E1 0B 24 .$ Win: FF E1 0B 25 .% 2. After the slash in "/xap/1.0/ - And before the tag <?xpacket I have this: Linux: - HEX - - ASCII - 2F 00 3C - /.< Win: 2F 20 00 3C - / .< When I change 20 to 00 in a hexeditor, i get this: $ exiv2 -p x fromwin.jpg XMP Toolkit error 201: XML parsing failure Warning: Failed to decode XMP metadata. fromwin.jpg: No XMP data found in the file
    Strange. Ill get back with testresult on 7.30. It would be intresting if this bug/feature is reproducable on other systems.
      There may be some differences due to exiftool version when you diff the 2 files, but I know of no problems with version 7.30 that could cause this. Could you send me the two images so I can take a look? My email is phil at owl.phy.queensu.ca Thanks. - Phil
        Just to close this out. The problem was not exiftool. After writing the meta information, the image was resized with imagemagick causing the problem. Turns out that imagemagick was adding an extra space after the XMP identifier at the start of the APP1 segment, which would cause most XMP readers to ignore the segment. However, exiftool recognizes non-standard XMP segments, so it can still read the information.