.NEF.XMP files?? WHY??

[pesto126]

Hi all.. just starting using the software and like what I see so far.. except for one thing I don't like - extra XMP files. I use Idimager currently to manage my photos and want to use it in conjunction with ASP. Basic workflow:
1 - Import images from memory card using Idimager - NEF's are renamed and basic metadata is added. A imagename.xmp file is created which mirrors the imagename.NEF file.
2 - I cull images in Idimager, rate and label them.
3 - Images are highlighted and I drag/drop them into ASP... so far, so good

However, as soon as I start to make adjustments, new XMP files are created with the filename: imagename.NEF.XMP... huh!? Why not see the standardly named XMP file and just add your metadata to that file? I don't want to have a second sidecar file created tagging along with the one from Idimager...

I noticed the preference to create ASP XMP files and I unchecked that.. but as soon as I start making edits again - new XMP's are created.

Any ideas/thoughts about this?? Thx...

[gareth]

From my perspective, it's the IDimager xmp that is the 'extra' one here .
I load Raw to computer directly then do all culling in Bibble (now ASP) -- result = 1 xmp file.

[maggus]

This topic was discussed some time ago either for ASP or Bibble ... don´t know exactly right now.

But the general question here seems to be why "normal" programs generate "<basefilename>.xmp" while Bibble/ASP generates "<basefilename>.<ext>.xmp" ?

The answer is simple: because you can get multiple images with the same <basefilename> but different extension (image-type) within one directory, e.g. if you shoot RAW+JPG .... the "normal" programs would fail with their strategy .... clear ?

So whenever you apply any edits/changes within Bibble/ASP you´ll get a "<basefilename>.<ext>.xmp" sidecar file, regardless of any existing "<basefilename>.xmp" or any settings in the preferences. (else your edits would be gone !)

There was also a post somewhere that ASP imports any ratings/tags/... from existing "<basefilename>.xmp" when you import the images into the library ... but never tested it by my self.

cheers
Markus

[afx]

Why not see the standardly named XMP file and just add your metadata to that file?

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...

cheers
afx

[RickHeath]

FWIW I've added Custom Sidecar File Definitions in IDI (Tools>Options>Other Settings) of "%Filename.%FileExtension.xmp" for both JPG & CR2 to make sure that IDI will handle B5 & ASP sidecar files correctly if I rename files, move them, etc.

Regards

Rick

[pesto126]

Rick - thank you for your answer - I hadn't thought of that and that should allow me to maintain a single XMP file for both programs to use.

Afx/Maggus - yes.. I see that now and forgot that ASP can handle JPG's as well - though I would have expected JPG's to just embed the info directly into the XMP within the file rather than deal with additional sidecar files.. if the format can handle embedding metadata - why not take advantage and offer an option?

Gareth - Idimager embeds metadata directly into those file types that can handle it, so no need for an add'l XMP. JPG's/TIFF's/DNG's, etc all allow for XMP handling within the file block - idimager does a wonderful job of adding the data without the need for sidecar files. So, it isn't creating an extra one - just doing the an efficient job. As for your workflow, its all good if that works for you. I need more advanced DAM control than ASP offers thus I use Idimager... they are 2 totally different programs - I just need them to work well together and I think Rick's response should allow that!

Many thx all..

[ferdinand-paris]

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, by using their own namespaces. So AFX and I disagree on this point. But I can't see it being changed now. Personally I think it's the use of <basefilename>.<ext>.xmp rather than <basefilename>.<ext>.somethingelse which is particularly confusing, but that's not going to change either.

F_P

[claudermilk]

As usual, I'm on the same page as Ferdinand. Those who understand XML (what XMP really is at its core) know that you can define separate namespaces. The file structure could accomodate settings for multiple source files within a single XMP. This multiple-extension thing just adds to an already huge mess. At least in the Bibble days it was ".NEF.BIB" so was obviously a custom file; now that it uses the already-defined XMP extension the mess just got much worse. A foolish decision IMHO.

[maggus]

I know a bit about XML (just used it on some projects) and really understand the idea of namespaces .... to differentiate between the JPG and CR2/NEF/... of the same image within one XMP .... sounds like a great idea,
BUT still these two images (xxx.JPG and xxx.NEF) are 2 independent files on your system ... and just by accident show the same picture !

Just imagine you work on a job together with your partner, one with a Nikon, the other with a Canon. Both cameras nearly at the same picture counter AND the filename pattern is the same (or you rename them to look the same).
How should ASP differentiate between the xxx.CR2 and the xxx.NEF if you put all your pictures into one folder and ASP would NOT put the original extension into the name of the XMP ?

Of course I also would like the idea to handle the set of RAW+JPG as ONE image ... but this could cause trouble ... and you will never apply the same settings to the camera-generated JPG as to the RAW .... so why should it be within one sidecar XMP ?

All solutions have trade offs ... and making it adjustable by the user even increases confusion, especially when you change your settings on the fly, maybe after 1 year of work ...

So to me the ASP way of XMP naming is transparent, flexible and reliable .... and that´s the only thing I expect from SW.

You have to thank Adobe for their lack of thinking...

Don´t know if Adobe missed something (don´t know the spec of XMP), but at least it´s not 100% robust.

cheers
Markus

[afx]

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, by using their own namespaces.

I guess they didn't think it through then....
Namespaces are useful for separating information.
But they are utterly useless to handle multiple files.

If you have IMG.NEF, IMG.JPG and IMG.XMP in a folder and want to move the JPG to a different folder??? Only dedicated apps that know about the contents might be able to split up the XMP, but nothing file system based. Assuming that only one app manages files is a recipe for failure.

cheers
afx

[DocBrown]

Seems to me that the solution might be, at least as an option, to write/read XMP data to/from the files that support it. ASP can currently write XMP into files that support it while exporting, but does not have an option to write that data on the fly (in the same manner we can create XMP files), nor can it read XMP data already embedded in files by other applications.

I'm not saying this is a graceful solution. But it seems more workable than the clutter we have now.

[afx]

nor can it read XMP data already embedded in files by other applications.

What makes you think that? Works just fine with embedded XMP from iMatch.

cheers
afx

[pesto126]

I agree and do see an inherent issue with multiple files with the same name.. I do use 4 different cameras... however, I include the camera model in my rename so for me this is not an issue.. of course, others will choose not to and for them it might be an issue.

In the end, I just want a solution that doesn't involve 5 different XMP files trailing an image around... this solution that ASP has doesn't work for Idimager so well if you don't rename the idimager files to use ASP's custom naming convention. IDI will automatically move sidecar files that match the name of the image when you move a file... if we also have a asp sidecar file to deal with, that won't be included.

Sigh... always something isn't it!?

[pesto126]

FWIW I've added Custom Sidecar File Definitions in IDI (Tools>Options>Other Settings) of "%Filename.%FileExtension.xmp" for both JPG & CR2 to make sure that IDI will handle B5 & ASP sidecar files correctly if I rename files, move them, etc.

Regards

Rick

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!!!

[DocBrown]

nor can it read XMP data already embedded in files by other applications.

What makes you think that? Works just fine with embedded XMP from iMatch.

cheers
afx

Of course it does. With iMatch. But not a lot of other software. 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.