INTERACT FORUM
More => Old Versions => Media Center 16 (Development Ended) => Topic started by: Craig on September 02, 2011, 03:35:50 pm
-
I've been dabbling with IPTC tags in Lightroom 3 as a way of transferring info between the the two programs and have come across a problem whereby Lightroom cannot write the tags to the file and giving the error 'Sidecar file has a conflict'
It seems that if MC has written tags to the file then Lightroom cannot update the file. If Lightroom writes the tags first then MC is able to write tags later without upsetting Lightroom.
Has anyone got any ideas how to get around this?
I tend to use MC to manage my photos but find Lightroom easier for selecting keepers.
Craig
-
Just to narrow down the issue a bit, have you determined if the source file has any effect on the issue? In other words, do files from different cameras exhibit the same behavior?
Also, do you have to actually make a change to the file in LR first, or does simply importing it make it work properly?
Do the files you're using already have sidecar files before the import, or are they created when you make changes in LR? In my experience with LR and the file types I use (jpg and .mrw raw files), the sidecar files are actually first created by LR -- i.e. they don't exist before this point. If this is also the case with your files, perhaps MC is creating sidecar files that are missing something that LR expects to see. As long as LR creates the sidecar first, MC only modifies the existing sidecar, and everything works fine. If MC makes the sidecar first, however, LR gets confused.
I know that this doesn't exactly help all that much -- I'm just thinking out loud here in the hope that it might help point in the right direction.
Larry
-
As long as LR creates the sidecar first, MC only modifies the existing sidecar, and everything works fine. If MC makes the sidecar first, however, LR gets confused.
Larry
Thanks Larry
Thats pretty much how I see it although I can't see any sidecar files, what extension are they and where would they be?.
My files are jpegs from a Canon EOS7D.
Craig
-
Thanks Larry
Thats pretty much how I see it although I can't see any sidecar files, what extension are they and where would they be?.
My files are jpegs from a Canon EOS7D.
Craig
Separate sidecar files are not necessary with jpgs because metadata can be written directly to the file itself. This is also the case with a few other file types such as (I believe) tiff and psd. When separate sidecar files are needed, and when Lightroom is set to save metadata to the "file" rather than only to the "catalog," it creates them in the same location as the original file, and it uses .xmp for the file type. I don't know if the xmp file type is a "standard" sidecar file type for other programs, or if this is just what Lr uses.
The Lr error may be a somewhat generic error message that is pointing out a problem with the metadata structure -- i.e. it may be using the word "sidecar" even though jpgs don't use a separate file for this data.
Either way, I've heard of this sort of error before when using more than one program to edit photos -- i.e. one program will alter a jpg in such a way that another can no longer write to it. I always recommend keeping an untouched, original version of the photos saved in order to deal with situations like this (just in case the the problem cannot be undone.)
The next step would be to determine if the problem is limited to certain data fields (i.e. certain tags). Does writing ANY data to the file in MC cause this issue, or is it just certain fields? Is it perhaps just custom fields -- or maybe even a specific custom field -- that causes problems? Try to narrow down the issue as much as you can, and see if it points to something that others could check.
One other question: Is MC still running when Lr has the problem? Is there any way to test the same files on another system running Lr? One thing you could try would be to delete a "problem" jpg from the Lr library (but NOT from the drive) and seeing if it still doesn't work with Lr. Just remember to use COPIES of the files for your tests so you don't lose any originals.
Larry
-
Wikipedia article on XMP (http://en.wikipedia.org/wiki/Extensible_Metadata_Platform)
-
Jim, any chance you will give xmp support some more love during this version?
I'm thinking as a priority:
1. MC using exposure and color info from xmp metadata instead of using DCRAW etc to render the files.
2. Writing xmp data into DNG files, or MC being able to read/write to xmp sidecar files
-
I had what sounds like a similar issue with some JPGs that were tagged in MC which then could not be tagged in Windows (built-in tagging in Windows Explorer and Windows Live Photo Gallery). It seemed that MC somehow corrupted the tags but I can't say for sure and it was just a small subset of all the files. I did a "batch processing" of the effected files in Adobe Photoshop Elements which seemed to "fix" the files.
-
I had what sounds like a similar issue with some JPGs that were tagged in MC which then could not be tagged in Windows (built-in tagging in Windows Explorer and Windows Live Photo Gallery). It seemed that MC somehow corrupted the tags but I can't say for sure and it was just a small subset of all the files.
We haven't had any other reports of this.
-
I've reimported my pictures from the camera as suggested by Larry,
I then tagged them in LR and then in MC and they all worked fine.
It seems to be as simple as, if MC has written tags to the file then LR cannot
If LR writes the tags first then MC and LR can both write them later.
But It seems that LR2 can write the tags either way so it's looking to me like the problem is with LR3
Craig
-
But It seems that LR2 can write the tags either way so it's looking to me like the problem is with LR3
With photo editing, compatibility issues sometimes crop up, and the issue of "fault" becomes very fuzzy. Just because Lr2 works but Lr3 does not, it does not mean that Lr3 is the "problem" per se. Nor does it mean that MC is doing anything "wrong." Sometimes there are compatibility issues that crop up becuase the standards did not take all situations into account -- i.e. two programs can be doing everything "legally" and still have compatibility issues.
Did you ever figure out if it's a specific tag that causes the issue?
Larry
-
1. MC using exposure and color info from xmp metadata instead of using DCRAW etc to render the files.
I don't think that sentence makes any sense. What are you looking for?
-
Did you ever figure out if it's a specific tag that causes the issue?
Larry
I'll try to have a go at that at the weekend and see if I can narrow it down any.
Craig
-
Ok, so I took two copies of the same file, the only tags in there are the ones written by my camera.
one file I exported metadata in LR and the other I did update tags from library in MC.
The file tagged first in MC cannot be updated in LR
The file tagged first in LR can be updated in MC but not subsequently in LR
Doing a 'remove tags' in MC doesn't make the file usable in LR
and the only tags being written by MC are the defaults
MJMD Tag: v1.0 (722 bytes - APPID 9)
<MJMD>
<Tool_Name>Media Center</Tool_Name>
<Tool_Version>16.0.173</Tool_Version>
<Album>10/09/2011</Album>
<Date>40796.3640856481506489</Date>
<Name>Tag test MC first</Name>
</MJMD>
I'm confused.
Craig
-
I don't think that sentence makes any sense. What are you looking for?
I believe that Lightroom saves the exposure and color adjustments you make to a raw file into the sidecar xmp file. Then when loading lightroom it uses those values to draw the thumbnail and displays. It would be cool if MC could read that same info to display the image in the way that you processed it in Lightroom.
-
I believe that Lightroom saves the exposure and color adjustments you make to a raw file into the sidecar xmp file. Then when loading lightroom it uses those values to draw the thumbnail and displays. It would be cool if MC could read that same info to display the image in the way that you processed it in Lightroom.
Those adjustments do not exist in a vacuum. They control the output of a specific rendering engine. Without ACR to render the files the adjustments are meaningless.
-
I see. So is there no way to use ACR's rendering engine when displaying the images? Or make DCRAW render using the xmp exposure/color adjustments?
-
I see. So is there no way to use ACR's rendering engine when displaying the images? Or make DCRAW render using the xmp exposure/color adjustments?
ACR might be scriptable. I'm pretty sure LR3 isn't.