Legacy ImageMagick Discussions Archive

Hi,

Problem description
The problem I have is that after a size conversion the XMP in the file is no longer recognized by other applications. The XMP in the original file is somewhat 'corrupt' with multiple empty XMP areas but nevertheless it seems that the XMP is touched in the convert process.
My own analyzis is this:
The original file has multiple XMP meta blocks. However between the end of one and the start of another the following characters appear
<?xpacket end='w'?>ÿá¬http://ns.adobe.com/xap/1.0/<?xpacket begin
In the result XMP the extra characters are washed away. I suspect that this means that applicatoins will look for XMP in the very last XMP block which is empty. In the original file I suspect that the extra characters are providing applications to think that the extra blocks in fact are XMP.

(I am not sure why the XMP looks like it does in the original, the file is going through a lot of workflows and my idea is that this workflow adds this and that this is an error, but still expect the XMP to be ok after the convert command)

System Information
==================
Tests have been carried out on Mac OSX 10.6.8 with
ImageMagick 6.7.8-0 2012-07-17 Q16

Files
=====
The following files can be downloaded for test

Original Image (appr 5.4 MB)
http://www.laidbacksolutions.se/ImageMa ... iginal.JPG
Result Image (appr 500 kB):
http://www.laidbacksolutions.se/ImageMa ... result.JPG

Test command
============
The command that have been executed to test is the following

The original file has 15 separate blocks of XMP text, each stored in its own JPEG file segment. In the result file, all the XMP text has been concatenated together into a single JPEG file segment. The characters you see between the blocks of XMP text in the original file are part of the JPEG file infrastructure.

I don't know the rules about how XMP is allowed be stored in JPEG files. Evidently, neither do the authors of at least one of the applications you're using.

Thanks for answer.

So (besides the error that the original image contains multiple XMP blocks) this means that the actual problem is the merging all the XMP blocks into one, since the XMP in the result file can be read perfectly but parsing that XML will cause a big problem.

Right. Apparently, some applications can't parse multiple XMP packets in the same JPEG/XMP segment, and ignore the whole segment that case.

I looked at the XMP spec, and my assessment is that both files are invalid:

All of the XMP about a resource should be stored in a single XMP packet. The XMP Specification does not describe any notion of merging multiple packets about the same resource.

If there are no known applications that can handle multiple XMP packets in the same JPEG segment, then I think it would be better if 'convert' ignored all JPEG/XMP segments after the first one. (Better than concatenating them, that is. Whether maintaining them in separate segments is even better is open to debate.)

Jason S wrote:Right. Apparently, some applications can't parse multiple XMP packets in the same JPEG/XMP segment, and ignore the whole segment that case.

I looked at the XMP spec, and my assessment is that both files are invalid:

All of the XMP about a resource should be stored in a single XMP packet. The XMP Specification does not describe any notion of merging multiple packets about the same resource.

If there are no known applications that can handle multiple XMP packets in the same JPEG segment, then I think it would be better if 'convert' ignored all JPEG/XMP segments after the first one. (Better than concatenating them, that is. Whether maintaining them in separate segments is even better is open to debate.)

I agree. I will investigate further where in the process the files get the multiple XMP blocks (which is the main problem here) but if the convert could just ignore 'empty' XMP blocks that would be great.