Skip to main content

Is the xmp sidecar file really necessary.

Comments

11 comments

  • Frank Schophuizen

    From the user guide I understand that the purpose of the XMP file is to export metadata to other applications, or to import metadata from other application. Only when metadata gets 'lost', you can 'Read metadata' (Photo menu) to grab metadata from the XMP file. Otherwise, the XMP file is not used by ON1 Photo Raw.

    0
  • Gerry Whitmarsh

    Thanks for the response, Frank.

    Ok, that makes sense. So after ON1 has read the xmp from LR (no need to go to Photo menu) I can safely delete the XMPs. As it is, for me,  a one-way route (LR -> ON1), it would be nice if I had an option in ON1 not to create XMPs. 

    0
  • Rick Sammartino Community moderator

    In browse under Photo there is an option to Embed Metadata. I think you'll want to do that before you start deleting things. Note that if you have a lot of files it will take some time. I'd try just a few first to get a feel for it.

    0
  • Kevin Pinkerton

    The xmp file for a photo is the primary source for the data you see in the right panel on Browse on PR. If the xmp file exists, PR will always use it to read the metadata. Or I should say, it will attempt to read it and then use whatever it finds. If the xmp file is not there, PR reads the metadata from the photo itself. If you get a corrupted xmp file, or you use one or create one that is not 100% compatible with what PR expects to find, it will display incorrect, or empty metadata in the right panel on Browse. So when that happens, the "read metadata from photo" can be used to completely blow away the existing xmp file and re-create it.

    0
  • Gerry Whitmarsh

    Rick,

    Embed Metadata will only create an xmp file for raw, which really defeats the object as I do not want the xmp. I have tested the LR => xmp => ON1 => delete xmp and it seems to do what I want. As long as I backup the .cr2 and .on1 I can always restore. After deleting the XMPs ON1 re-builds the previews which takes a little time, but the metadata is preserved. Other formats are not a problem and I can still run LR and ON1 side by side.

    Kevin,

    The metadata is also stored in the .ON1 sidecar file. I have checked this with an editor, so once the metadata in the .XMP from LR is read, it is stored in the .ON1 so the XMP is no longer needed. Metadata such as keywords are not embedded in raw files so the .XMP is necessary in order to get the keywords from LR into ON1. 

    0
  • Kevin Pinkerton

    Gerry, that is interesting. I do not use LR so that part of the conversion is not being done. I start with a raw file and begin editing and the .on1 file gets created from scratch right away. The metadata is indeed in the .on1 file. But the problem I had (and submitted as a bug) was dealing with the Nikon .NEF raw files I was using. There were two metadata fields that were empty (I cannot remember what fields they were) in ON1 on the right panel. When I told ON1 to reload the metadata from the raw file, these two fields were no longer empty. I am fairly certain that there was no .xmp file created until I did the reload. Anyway, the problem is no longer there, but I do remember ON1 support saying that they did not create .xmp files until absolutely necessary.

    0
  • Rick Sammartino Community moderator

    Ok. Just checked the user guide (page 45). I thought embed worked for all files, but looks like it's only for TIF, PSD, PSB and JPG.

    0
  • Gerry Whitmarsh

    Bummer. I have just discovered that ON1 doesn't write the lens information to the .on1 file and needs the .xmp in order to perform lens corrections. If I write the metadata to an xmp file in Lightroom (I only really need the keywords) then ON1 recognises the lens and makes the correction. If I then delete the xmp then all the metadata is preserved except that ON1 cannot find a match for the lens any more and I have to manually select the lens. There is a serious bug somewhere as ON1 knows the make and model of the lens but still can't find a match. 

    I have reported this to support months ago but have had no response. 

    0
  • Kevin Pinkerton

    Gerry,

    If there is no .xmp file, and you tell ON1 to read the metadata from the photo, it will create the .xmp file right there on the spot and if the lens info is in the photo, it will put it in the .xmp file. Am I missing something? Does the photo not have the metadata in it?

    This is very similar to a problem I had with nikon raw files. ON1 had some sort of problem reading the lens info from the photo, but when I told it to create the .xmp file (read metadata from photo menu option), it had no problem reading the lens data and putting it in the .xmp file. Once it was in the .xmp file, the lens correction worked.

    0
  • Gerry Whitmarsh

    Kevin,

    I have tried that. I export the xmp from lightroom in order to preserve the keywords. Read metadata from photo does create an xmp, but I already have one from LR (which I don't want). As you can see from the screen print ON1 does know which lens it is, but apparently has a problem finding a match. Tomorrow I will try to import with ON1 and see if that helps.

    0
  • Gerry Whitmarsh

    Ok, I now give up. I have given it my best shot, but I have spent way too much time trying to work around all the inconsistencies; I have no time left for taking photos. I have 3 almost consecutive photos. One finds a match for the lens, the next one doesn't but clicking on [Auto] finds the lens and the third one doesn't find the lens even after [Auto]. In properties - apply corrections "automatically" and there are XMPs. There is no rhyme or reason to it. In frustration I deleted all the .XMPs and for all the photos “Read metadata from photo”. Now, lo and behold, all photos that I had rotated were back to the original orientation and could not be re-rotated!!! Apparently ON1 does keep the orientation separate from the XMP and this can’t be undone. 

    So, it's remove the catalogued folders and back to using ON1 just as a plugin from Lightroom and having to create huge PSDs. It's a shame, it's great for effects but it is just so frustrating. 

    0

Please sign in to leave a comment.