.NEF.XMP files?? WHY??

[ferdinand-paris]

I guess they didn't think it through then....

This is a very peremptory comment. In fact they have thought it through very thoroughly, because they have to deal with the vagaries of many other applications.

Next you'll say that others haven't implemented it correctly. What's funny about that is other software vendors have told me that Bibble/ASP hasn't implemented it correctly either. None of these assertions are true at all. The reality is, as you already said, it's an imperfect implementation to begin with. No one is creating the fields exactly the same way. I've found many differences in XMP files from various vendors, comparing what should be the same fields, and yet use different syntax in the XMP file. I had started a thread on this over a year ago on the Bibble support board.

I agree with this. Given the ambiguities ... the issue is not what's right or wrong or who is most clever and has the best understanding. Rather it is who has done the best job of ensuring interoperability.

The B5/ASP approach works if you stay inside the B5/ASP world. What happens when you try this?: put a RAW and a JPG in the same folder. Given them different ratings. Export standard XMP files. As I understand it the XMP will only have one rating field, and I assume that it will be whichever of the RAW and XMP was written last. Now do a merge external metadata for these images. I expect that they RAW and JPG will now have the same rating, won't they?

F_P

[afx]

I guess they didn't think it through then....

This is a very peremptory comment. In fact they have thought it through very thoroughly, because they have to deal with the vagaries of many other applications.

But if their approach breaks, it still shows that it does not work...

The B5/ASP approach works if you stay inside the B5/ASP world. What happens when you try this?: put a RAW and a JPG in the same folder. Given them different ratings. Export standard XMP files. As I understand it the XMP will only have one rating field, and I assume that it will be whichever of the RAW and XMP was written last. Now do a merge external metadata for these images. I expect that they RAW and JPG will now have the same rating, won't they?

Yup. But the problem is not the ASP XMPs, but the silly Adobe XMPs.

If everyone runs like a Lemming when Adobe does something instead of standing up against it, nothing will change...

cheers
afx

[TheDude]

Because the concept is totally broken.
It will not allow for a JPG and a NEF in the same directory with individual XMPs.
You have to thank Adobe for their lack of thinking...

Much smarter people than me with a detailed understanding of XMP claim that B5/ASP could have used the standard XMP, even for the multiple versions in the same folder,

It is correct that you can store information about multiple versions of a file inside a single xmp. But a major drawback of this approach is, that the mapping of such information to a file is not visible from the file system level anymore. Imagine you want to move all jpg files including their meta information into a different folder. In case of a single xmp file for all versions you need a copy program that can export the jpg related information from the source xmp file into a new one inside the target directory. In case of individual xmp files, you simply take the file management tool of your operating system, select *.jpg* and move it into the target directory.

So what is the benefit of centralizing informations about multiple files inside a single xmp? It avoids some extra files, but these are easy to handle anyway.

Apart from this, I think the naming convention for xmp sidecar files is not clearly defined. From http://www.adobe.com/content/dam/Adobe/ ... nPart3.pdf :

"For applications that need to find external XMP files, look in the same directory for a file with the same name as the main document but with an .xmp extension. (This is called a sidecar XMP file.)"

Since it dose not clearly require to replace the extension, the bibble/asp way seems compliant as well.

[RickHeath]

Too Bad Idimager can't use these same setting to WRITE out its info to this same file in a different namespace as well instead of always creating a standardly named XMP file... its a good solution for now.. but doesn't address the fact that I'll still always have 2 sidecar files hanging out with every image I edit now. Silly idea ASP!!!

I don't really think ASP's idea is silly. I understand Lightroom can get its knickers in a twist if there are 2 image files with the same name but different extensions in a given folder.

Your response has prompted me to action & I've added a feature request on the IDI forums to have an option to use custom XMP naming so you can have a single sidecar file.

Regards

Rick.

[pesto126]

Thx Rick - I think Idimager should allow for custom naming convetions for how it looks for and write's its XMP files.. at least that would make it flexible... of course, perhaps ASP should also do the same as mentioned.

Interesting discussion folks... guess I'll have to live with 2 XMP files for now.. but at least I know that Idimager will now move/delete,etc the ASP XMP file along with the standard XMP file going forward thx to its forward thinking customization ability.