PM Breaking my XMP files. Why?

[david_hill]

I'm editing Canon CR2 files in Bridge with the ACR pref set to write changes to XMP sidecar files. The normal expectation is that as long as you keep the XMP sidecar and corresponding RAW file in the same folder, the two should be recognized as a pair in Adobe products (as we all know).

Normally, it's expected that you can move a sidecare and RAW around together as long as they're still in the same folder, and they still work. (Right? Someone correct me if I'm wrong here.)

What I'm now seeing:

1. I adjusted a batch of files in Bridge, sidecars written out.
2. I moved a subset of those files into a different folder using Photo Mechanic, and I also untagged them once there.
3. After the move and untagging, Adobe no longer recognized the XMP files, despite the fact that they were present.
4. I had to re-edit all the affected files.

... I don't recall this being an issue prior to CS3 and current PM version. I have not done enough testing to fully isolate the issue, but I know two things:

1. A move and/or untag broke my XMP.
2. Separately, doing an EXIF time adjustment will also break the XMP association, even if the files are never moved.

Can someone educate me as to what is going on here?

Was it always this way?

Is this a bug (which I suspect), and if so, whose fault is this?

My PM version is 4.5.3. Mac OS X 10.4.11. Current CS3 udpate, whatever number that is, I let the auto update run recently.

Thanks,
David

 

[Kirk Baker]

David,

I'm editing Canon CR2 files in Bridge with the ACR pref set to write changes to XMP sidecar files. The normal expectation is that as long as you keep the XMP sidecar and corresponding RAW file in the same folder, the two should be recognized as a pair in Adobe products (as we all know).

Normally, it's expected that you can move a sidecare and RAW around together as long as they're still in the same folder, and they still work. (Right? Someone correct me if I'm wrong here.)

What I'm now seeing:

1. I adjusted a batch of files in Bridge, sidecars written out.
2. I moved a subset of those files into a different folder using Photo Mechanic, and I also untagged them once there.
3. After the move and untagging, Adobe no longer recognized the XMP files, despite the fact that they were present.
4. I had to re-edit all the affected files.

... I don't recall this being an issue prior to CS3 and current PM version. I have not done enough testing to fully isolate the issue, but I know two things:

1. A move and/or untag broke my XMP.
2. Separately, doing an EXIF time adjustment will also break the XMP association, even if the files are never moved.

Can someone educate me as to what is going on here?

Was it always this way?

Is this a bug (which I suspect), and if so, whose fault is this?

My PM version is 4.5.3. Mac OS X 10.4.11. Current CS3 udpate, whatever number that is, I let the auto update run recently.

I have no idea whose fault it is.  But it would be great if you could post the XMP file that works and the one that doesn't so we can see the differences.

-Kirk

[david_hill]

Kirk - OK. I'll have to break some new ones for you tomorrow, since I already "fixed" the ones I was writing about tonight

Oh, and to make this more interesting, a confession of sorts: I am running on a machine that once, long ago, ran the CS3 beta... I have uninstalled that to the max, using the undocumented extreme predjudice removal option that Adobe will only tell you about if you actually call in on the phone... So "officially" the beta is totally gone from my system. Unofficially, I will never trust this system again... Which is why I just did a fresh Leopard install on a totally new hard drive... However, I have not installed CS3 or anything else on Leopard yet... It will be fun to see if this issue carries over onto a new machine... Also, I suppose I can try to repro the issue on my totally "clean" 10.4.11 laptop system which has never been harmed by the CS3 beta... if it turns out to be a post-beta issue, then I guess the joke is on me.

[david_hill]

OK - I just repro'd, this time with NEF instead of CR2... still breaks the same.

I'm uploading you some files that will take about 30 minutes from now to get up on my FTP server. Links at bottom of this post. Here's what I did:

1. Created parent "PM_XMP_TESt" folder.
2. Created two folders, RAW and RAW2 in that folder.
3. Placed 7 NEF files in RAW.
4. In Bridge, set color temp of all 7 up to about 8K -- something very obvious since the "as shot" values were in 5K ballpark. Some other minor adjustments for un.
5. Set color class of first 5 images to 1 ("winner").
6. Of those 5 winners, tagged three of them.
7. Moved the tagged files into the RAW2 folder using PM.
8. Selected the 3 tagged files and group untagged them.
9. Moved them back into RAW using PM.
10. Went back into Bridge. The 3 moved files have had their XMP associations broken and appear unedited, despite presence of XMP file.

This is the state of the files that I'm uploading at the moment.

However, I tested a little further... In short, I determined that tagging a photo in place is all that is required to break XMP on my system. I did not even have to move the file to the other folder. Even though I initially perceived that as a requirement to break, it's not... Just tagging. I don't even have to untag: If I tag a file in the RAW folder, then go to Bridge, the file is immediately broken.

Here's my links:

http://davidhillphoto.com/previews/PM_XMP_TESt-working.zip
http://davidhillphoto.com/previews/PM_XMP_TESt-broken.zip

First upload is 70 percent complete now... Give it another 20 mins to finish.

p.s. -- Moving the file alone is not sufficient to break. I have moved the files several times without breaking. Additionally, I have re-confirmed my prior experience that using the EXIF time correction tool will also break the association. That file is not uploaded, but using my files all i had to to was shift the time on a file by one second to break the XMP.

[Kirk Baker]

David,

OK - I just repro'd, this time with NEF instead of CR2... still breaks the same.

I'm uploading you some files that will take about 30 minutes from now to get up on my FTP server. Links at bottom of this post. Here's what I did:

1. Created parent "PM_XMP_TESt" folder.
2. Created two folders, RAW and RAW2 in that folder.
3. Placed 7 NEF files in RAW.
4. In Bridge, set color temp of all 7 up to about 8K -- something very obvious since the "as shot" values were in 5K ballpark. Some other minor adjustments for un.
5. Set color class of first 5 images to 1 ("winner").
6. Of those 5 winners, tagged three of them.
7. Moved the tagged files into the RAW2 folder using PM.
8. Selected the 3 tagged files and group untagged them.
9. Moved them back into RAW using PM.
10. Went back into Bridge. The 3 moved files have had their XMP associations broken and appear unedited, despite presence of XMP file.

This is the state of the files that I'm uploading at the moment.

However, I tested a little further... In short, I determined that tagging a photo in place is all that is required to break XMP on my system. I did not even have to move the file to the other folder. Even though I initially perceived that as a requirement to break, it's not... Just tagging. I don't even have to untag: If I tag a file in the RAW folder, then go to Bridge, the file is immediately broken.

Here's my links:

http://davidhillphoto.com/previews/PM_XMP_TESt-working.zip
http://davidhillphoto.com/previews/PM_XMP_TESt-broken.zip

First upload is 70 percent complete now... Give it another 20 mins to finish.

p.s. -- Moving the file alone is not sufficient to break. I have moved the files several times without breaking. Additionally, I have re-confirmed my prior experience that using the EXIF time correction tool will also break the association. That file is not uploaded, but using my files all i had to to was shift the time on a file by one second to break the XMP.

One question: do you have PM set to embed IPTC4XMP into your RAW files?  If so, uncheck that checkbox.  Only embed IPTC or embed nothing at all and you'll have a complete XMP sidecar workflow.  Adobe's software has a bug in it where it prefers embedded XMP metadata over sidecar XMP metadata yet it won't update the settings in the RAW file so the RAW settings are lost.

It would be best for them to either ignore embedded XMP or if they want to use it, they should update it as well.  Either way would solve the problem.

-Kirk

[david_hill]

OK - that does resolve for files which are not yet affected. For files which are already affected, it is required to revert to a backup -- unless of course you can tell me some way to reverse the embedding. Both tag and EXIF time correction pass the test now when working from fresh files.

Thanks for the info.

[Kirk Baker]

David,

OK - that does resolve for files which are not yet affected. For files which are already affected, it is required to revert to a backup -- unless of course you can tell me some way to reverse the embedding. Both tag and EXIF time correction pass the test now when working from fresh files.

You can use the "Revert TIFF-based RAW to original" command on the Tools menu to remove the embedded XMP metadata.  This will correct your already affected files.

-Kirk