.xmp file CS4

Is there any way to export the .XMP files that are associated with the MPEG2 DVD files without exporting the whole file...
I have a project that I set the chapter points in Premiere but did not name them.  So I exported the file as a MPEG2 DVD file and when I imported it into Encore it has no Chapter Points, which I think is because I did not name them in Premiere.  So for future reference is there any way to get those chapter points to show up in Encore without exporting the whole file again.  I would love to be able to just export the .xmp file.
Any help would be appreciated...
Thanks
Phil

The .xmpses file contains the chapter information.  There is currently no way to create the file without a full MPEG2-DVD export.
However, I heartily agree that a method of exporting chapter information alone - usable in Encore with any video asset, not just those out of AME - is very much wanted and needed.

Similar Messages

  • 4.1.1 SDK Problems with missing xpacket tags in sidecar XMP files

    The current 4.1.1 SDK has problems with sidecar XMP files that don't have the xpacket headers and trailers, i.e:
    <?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
    <?xpacket end='w'?>
    is missing. Now, unfortunately Adobe Bridge CS2/CS3 does not export these xpackets in sidecar XMP files.
    The standard, http://www.aiim.org/documents/standards/xmpspecification.pdf, is also very vague about it all:
    ● Write external metadata as though it were embedded and then had the XMP Packets
    extracted and catenated by a postprocessor.
    The grammar is strange(past tense had) and the spec implies that the xpacket should be extracted and again catenated... Someone should review this document and clearly state if xpacket statements should be in sidecar files or not. I suspect myself that they should be there, but the standard is very vague.
    Anyway, there are two places in the SDK code where changes might be needed:
    XMPFiles::Initialize has XMP_Asserts in case the xpacket header/trailer is missing, but the underlying assert is only active in debug builds.
    XMPScanner::PacketMachine::FindNextPacket () also has in its truth table the assumption that the xpackets exist.
    There could be even other places in the code that assumes that the xpacket tags are present in all files, which includes text XMP sidecar files.
    Anyway.
    a) Shouldn't bridge export the xpacket tags? Same with any other application?
    b) If the spec is vague, then the SDK should not assume that the xpacket tags are present.
    Any comments? Has someone already fixed this issue as I suspect a lot of apps using the the XMP SDK would break concerning reading XMP sidecar files? Thx, Kent

    I was able to work around the problem by creating a mapped view of the .xmp file (this creates an array in memory backed by the file on disk, so there's no need to read the file into a separate internal buffer), and constructing the SXMPMeta object directly from the buffer. (The ctor for that class calls ParseFromBuffer, so this is the same thing as was suggested by other messages in this thread.)
    It seems that Adobe needs to do one of these things:
    (1) say that Bridge CS3 has a bug, and agree that Bridge CS3 should include a proper xpacket header when writing xmp sidecar files
    (2) say that the XMP Toolkit has a bug, and that the SDK should be able to parse sidecar files without an xpacket header, and agree to fix the toolkit
    (3) say that Bridge CS3 and the XMP Toolkit behave as expected, but then provide a sequence of steps by which users of the XMP Toolkit are expected to read xmp sidecar files written by Bridge CS3
    Does Bridge CS4 write an xpacket header to the xmp sidecar files?
    Maybe what I could do is create a custom file handler for .xmp sidecar files, so I could use the SXMPFiles for everything, instead of having to special-case .xmp files.
    My needs are pretty modest though, and it might be just as simple to use the MS DOM-based XML parser for load the xmp sidecar file. I bet I could get the data I need (only the "Rating" for now) using a simple XPath expression.
    -Matt

  • Is xmp files only availble for RAW files?

    When we develop a RAW image with Camera Raw, we always get an xmp file with all the settings,
    But after I developed a JPG image, I saw the Camera Raw Settings icon appeared above the right upper corner of the image thumbnail in Bridge,
    however, I couldn't find the xmp file.
    Is xmp files only availble for RAW files? JPGs or TIFs don't have xmp files for their Camera Raw settings??

    Read-only didn't work for me, on a single jpg file, although it did lead to some interesting behavior.  Set the read-only attribute on a jpg file in Windows XP and then tried the following:
    1.  Opened in Bridge, then into ACR 5.4.  Performed some edits, then tried "Done", received permissions error and would not save edits.
    2.  Did the same except now invoked "Open", went into CS4 with edits intact and allowed saving out as different file.  However, the ACR edits were not saved within the jpg, as expected, nor was a xmp created.
    3.  Removed the read-only attribute, repeated (2).  Even though did not save file in CS4 the "Open" action did embed the edits into the jpg.
    So read-only doesn't really allow creation of a xmp file, other than perhaps temporarily for transfer to Photoshop.  It does lead to somewhat inconsistent behavior, in that I would have expected the "Open" to fail also since it could not bury the edits in the jpg.
    Richard Southworth

  • Fix for Camera Raw 5.7 ignoring .xmp files?

    I have a problem, some people seem to have: From a certain date on, every sidecared .xmp gets completely ignored. Camera Raw as well as Bridge seem to ignore them. They get created, whether I open them with Bridge or CR. Someone suggested I could fix this problem by associating the CR2 Format with Bridge or Photoshop (CS4), it worked for a while... if I opened it with the Windows Explorer. Opening a CR2 with Bridge netted in the same result: .xmp gets created, but gets ignored by Bridge and Camera Raw. Now even that fix doesn't seem to work: Neither CR nor Bridge want to acknowledge the files.
    Is there a fix for that I'm unaware of?
    €:
    It seems I have found the problem: Someone mentioned it might have something to do with the timestamp of the files not being correct. I checked the date and time of my camera and realised I haven't changed the time, as Daylight-saving changed. Now the .xmp files read correctly. Perhaps that is some use for other people.
    €, Update2:
    I checked several things: If the modified time of the file lies in the future (here 1hr.), Bridge and Camera Raw have a problem recognizing the .xmp cause it seemed to have been created before the Photo was shot/modified last time. I took the pictures at 01:05pm (the were timed at 02:05pm). CR and Bridge ignored all .xmp-files created before 2:05pm. After 02:05pm, everything worked fine again.

    Good to hear that the matter is acknowledged.
    I had such cases. I think it was the renaming of old files. Not sure.
    Many things can go wrong. Whatever triggers it. It woulld be great to have the option (checkbox) to enforce the (re-)synchronisation of an existing xmp file with a given Raw and/or dng file.
    Best regards, Peter

  • What happened to .xmp files?

    I have noticed recently that my Bridge program (cs4) has not been automatically exporting .xmp files into the folder where I store my images. I have been doing a lot of reading, but still can't seem to find a solid answer as far as what to do.
    I have figured out how to export .xmp files into another folder, but what's the point of that? I want the metadata for my images to stay with my images. When I move them from folder to folder using Bridge, the xmp files used to move also, so I never lost my metadata.
    I also empty my cache fairly often. I noticed that Bridge was no longer exporting xmp files when I emptied my cache and ALL my metadata that I had added to my images was gone, just like that.
    I am a photographer and need that information to go somewhere permanent automatically, not in the cache which is supposed to store temporary file information.
    Anyone have any idea?
    Thanks so much!

    Tai Lao wrote:
    Your post #29 is completely blank
    Strange, I responded using email and this normally functions well, maybe the chance in formatting and quoting did not get through?
    I don't want you to think I'm ignoring you. 
    How could you think of that...
    here is a copy of the mail, hope the formatting keeps clear!
    >> Omke Oudeman wrote:
    >> 
    >> As far as I understood the producing of magenta colorcast is a fault by
    >> Pentax and the recovery utility does only work on original Pentax DNG, the
    >> PEF files already have some compression and don't display all the sensor
    >> data, Right?
    > 
    > Wrong, very wrong.  But that is definitely off topic.
    It is what I understood (after briefly scanning through page) from this post that advices to shoot in K20 generated DNG instead of the PEF format.
    http://www.pentaxforums.com/forums/pentax-dslr-discussion/67532-how-use-k20s-black-pixels- hidden-dngs.html
    >> Omke Oudeman wrote:
    >> 
    >> …I did something else, I opened 2 files in ACR, one the original CR2 and the
    >> other the DNG conversion of it. ............ I could not find one single >>difference between both files…
    > 
    > That is irrelevant.  The issue is that there is some information inside the
    > raw files that is not currently used either by the Pentax software or by
    > Adobe, but that a third party (Gordon B. Good in this case) was able to
    > utilize in order to improve the quality of certain converted raw files.
    For your files in certain conditions at high iso this seems to be the case, the DNG files converted by Adobe DNG converter do miss the border pixels needed for the script from GordonBGood.
    I tried to download that application but it seems only for Windows, how do you manage to use it?? Thought you have given up on Windows long time ago??
    Nevertheless I also tried the apply image method you quoted from Bruce Fraser in an other post, using subtract with offset 128 and both perfectly the same.
    I do agree that Raw converters from nowadays can get more out of the Raw data then they did 8 years ago, trying an 8 year old raw file gives a much better result (but then you also have to keep in mind that our knowledge and skills in Digital imaging have grown in combination with better color management understanding and good calibration soft and hardware is also due to this!)
    Also I'm not afraid my benefit from the future Raw converters will differ if I use DNG instead of the original Raw, but that is my personal believe. The result I get nowadays for combination of DNG and PS are already more then satisfying, and sure it will be better in the future but for that I have also faith in DNG :-)
    > Yes, I use PSDs exclusively.  However, if you don't think TIFF will be around
    > in 15 years, why do you think DNG will?  After all, *+Adobe owns the TIFF
    > format+* as well as the PSD format.  
    > 
    > If you trust Adobe to keep the DNG alive for 15 more years, why don't you
    > trust that same corporation to keep supporting TIFF, a format for which they
    > paid darned good money to acquire?
    That is just a question of the market, as you could see that our young friend that started this post never uses it and I do hear more voices saying they don't use it or don't see the use for it.  Eventually there will be no need for letting seldom used formats taking space in menu's and applications.
    DNG however is still talk of the town, whether you like it or not. And therefore more likely to be around in 15 years time. But you are right, If I was to know about what was going on in 15 years from now I would not be a photographer but a fortuneteller and in my free time bathing in countless money :-) :-)
    > Another one of the reasons why I don't like DNGs is, number one, that they
    > take an awful lot longer to open than the raw files.
    That I still can't understand unless you have chosen to use the original raw file included and created a double size for the file. But as stated in earlier post, not the case on my system.
    > Not that any of this—or anything else in the world for that matter—should be
    > an issue for me then. 
    Statistically you have lived the greatest part of your life and knowing your health is not something to be jealous of (to put it mildly) your statement about this also is something only time will learn.
    Let's wish we still can have a long period for our little chats, agreed or not.
    I will give up on getting you to DNG (for now as it is...) :-) :-)
    Vriendelijke groet,
    Con cordiales saludos
    感谢你和亲切的问候

  • PS4 shuts down... PS4 also adding XMP files after I edit images

    So there is another thing going on I have noticed...
    When I open PS4 and don't do anything else, it will shut down on it's own after 3 or 4 minutes. All I do is open the program and just wait... Poof-It's gone! (And it's also shutting down on it's own during image edits but i generally get a few more minutes out of it.)
    Also-everytime I edit an image, PS4 creates a XMP file that is about 6kbs. So now I have a bunch of extra files that I don't know what to do with. If this is a new feature, I sure would like to know about it.
    I am running XP (sp3) with 2GB RAM. Pentium D 3.00ghz (I am letting PS4 use 640mb of 1686mb available RAM)
    Never had these issues with CS.

    Hey thanks for the quick reply...
    I just downloaded the upgrade but funny... I am on 11.0 (Why didn't they sell me the most recent version since I purchased (and downloaded) the upgrade direct from Adobe a few days ago??)
    I will upgrade to the most recent version.
    Oh and yes- CS4 is what I meant.
    I will check the event logs and see if I can find what happened.
    Great link you sent on the sidecar files!! Appreciate your help!!
    Here's the log info...
    Event Type: Information
    Event Source: Service Control Manager
    Event Category: None
    Event ID: 7036
    Date:  9/12/2009
    Time:  11:39:53 AM
    User:  N/A
    Computer: *my system*
    Description:
    The FLEXnet Licensing Service service entered the stopped state.
    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

  • XMP files gone ??

    Just installed CS4 due to CS3 not being usable anymore. Bridge certainly works much better or so I thought- Just got through working on 5 folders...when I go back and look at the images..all the adjustments are gone.
    There is a symbol that says the image has XMP file (the one in the top right hand corner) it also still shows any crops I might have made...but for example the image might be at a temperature of 6000 and when I made the adjustments it was at a much cooler temp such as 3100.
    As I said this has happened in more than one folder ( but all images in that folder )...what the heck is going on ?
    Mac os 10.5.5 CS4

    Oddly enough this is almost the same issue I'm having with CS3 on an XP machine. Since about two or three CR4 releases ago I intermittently can't save changes to xmps either by Export Settings to XMP, by Open Image or by Done. They show the crop and that adjustments have been made but when opened the images are at the default and the crop is either not there at all or is a previous crop. Very strange.

  • .NEF Raw Files to .XMP Files.

    My RAW files have been changed from .NEF files to .XMP Files. How can I change the files back to RAW files?
    I am using CS4 PhotoShop and Bridge.

    So you have not opened any of the files in Camera RAW, so there’s no reason to have created an XMP file, yet?
    Are your XMP files are 10MB+ in size?  If so, it is possible that you’ve somehow renamed your raw files from an extension of NEF to an extension of XMP.
    The easiest way I know of to rename a bunch of files is with a DOS Command prompt.  My memory of what the menus in Windows 2000 are like is a little fuzzy, but here’s what I’d do, to rename XMP files to NEF files a folder at a time.
    Open a command prompt by going to Start / All Programs / Accessories / Command Prompt.
    Use the DOS CD command to find the folder the file are in.
    Do a DIR to see that you are the right place and that there are no NEF files in the folder (DIR *.NEF) but that there are XMP files in the folder (DIR *.XMP).
    Use the DOS rename command to change the extensions:
    REN *.NEF *.XMP
    Do a DIR to see that you now have NEF files (DIR .)
    If the XMP files were really XMP-sidecar files with settings in them, then renaming then to NEF files will not make them open and you’ll probably get an error, but if they were really NEF files that you’d accidentally renamed to XMP files, then the above process should work.

  • Adobe XMP Files not deleted with Raw Files in ACR

    I am using Photoshop CS3 on a Windows XP platform. My camera raw files are mostly kept on a Windows 2003 file server, which has a gigabit connection to my workstation. However, I have the same problems when using PS CS3 on my Windows XP laptop.
    I take many hundreds of 'technical' photographs using an Olympus E1 and Canon G9 cameras. I usually bracket the exposures on the E1, specially when photographing white painted yachts, and then rate and select the images that I want in ACR 4.1.1. Unwanted images are deleted at this time.
    The problem I am having is that the associated *.xmp files are not always deleted with the camera raw files, with the result that I now have literally thousands of these 'orphaned' files cluttering up the server. The only options I have are to delete the files manually, which is a pain, or to leave them on the server, wasting unnecessary space.
    I have the same issue with Canon and Nikon raw files, so this problem is not specific to Olympus files.
    This is a long standing problem, and I would be grateful if anyone has any answers?
    If any Adobe programmers are watching, it would be handy if you could provide a simple utility to delete orphaned *.xmp files, or at least compress them into some kind of archive.
    Thanks,
    Nigel.

    [quote] As far as Photoshop and ACR go, ALL raw files are treated as read-only.
    Your original raw files remain untouched, no matter what you do to them.
    Any adjustments you make to a raw file are kept only as metadata (flags, if you will) in that XMP side-car file. Every time you want to re-open that raw image file, ACR will reach for the XMP file and apply the adjustments automatically, transparently. [/quote]
    That is not quite correct. Camera RAW files can be permanently deleted from within Adobe Camera Raw. The problem with ACR 4.1 to 4.4 4 was that the XMP files were left behind. This now seems to have been rectified in the latest version (ACR 4.5).
    Thank you Adobe!

  • Bridge doesn't recognize its own .xmp files

    Using Bridge CS3 on Mac OS 10.5.8. I edit RAW (.nef) files in ACR. When I click done, save, or open image, an .xmp sidecar file is generated and saved in the same folder as the .nef. However, changes made in ACR do not show in the preview thumbnail in Bridge, and when I re-open the file in ACR, my changes are lost. The .xmp file is still there, it's just not applied. It's like Bridge doesn't know the .xmp file is there. The icons in Bridge indicating altered develop settings or crops do not appear after adjudstments are made. Star ratings made in Bridge remain. When this issue began, it would ignore sidecar files for some images, but not others. It is increasing in frequency, or may now be consistent. (If I open the file into Photoshop or save an image file out of ACR, the changes are applied to the developed image file, they are simply ignored by Bridge in regards to the Raw file.)
    Files that were adjusted before the problem began still synchronize with their sidecar files. Looking at the sidecar files in a text editor shows that they contain the adjustments made.
    There were no changes in any installations/updates to software or OS at the time of the problem's onset.
    I've tried using a Camera Raw database instead of sidecar files, and the changes are still lost. I've tried purging caches for Bridge and for ACR. I've tried resetting and dumping preference (.plist) files.
    Anyone have ideas on what I can do to salvage this program as my RAW library manager?

    Matthew,
    Same problem here. But I'm using CS5 in Win7.
    Bridge cannot find its XMP files. Bridge does not see its XMP files. XMP files do not work. Camera Raw settings do not show in thumbnails. ACR settings lost.
    I just now figured out the problem/solution.
    In my case, the association between CR2 files and Bridge was usurped by Canon DPP (the Canon raw converter) which I just installed this afternoon. When I installed it, there was no immediate problem. But when I started a new work session tonight, Bridge acted as if the XMP files weren't even there.
    Solution: In Windows, to set a file association, you just right-click on a file (in this case the CR2 file) and select "Open With", and then navigate to Bridge (in my case Bridge CS5). That re-establishes the link between Bridge and its own XMP files. Then simply purge your cache and let Bridge rebuild it using its XMPs (which it can now find again) to rebuild the cache with the adjustments that are stored in the XMPs.
    I don't know how to do this on a Mac, but the principle is the same.
    I hope this solves your problem.
    Dave

  • How can I use an old XMP file on a new set of images??

    I have an older XMP file that contains settings used to retouch some previous images in a particular way. I'd like to apply those same settings to a new set of images. How can I use that older XMP file on a new set of images in Lightroom?
    The contents of the XMP file are as follows:
    <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.2-c020 1.124078, Tue Sep 11 2007 23:21:40   
    ">
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
    xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/">
       <crs:Version>6.0</crs:Version>
       <crs:ProcessVersion>5.7</crs:ProcessVersion>
       <crs:WhiteBalance>Custom</crs:WhiteBalance>
       <crs:Temperature>4700</crs:Temperature>
       <crs:Tint>+4</crs:Tint>
       <crs:Exposure>-0.35</crs:Exposure>
       <crs:Shadows>5</crs:Shadows>
       <crs:Brightness>+50</crs:Brightness>
       <crs:Contrast>+25</crs:Contrast>
       <crs:Saturation>-8</crs:Saturation>
       <crs:Sharpness>25</crs:Sharpness>
       <crs:LuminanceSmoothing>0</crs:LuminanceSmoothing>
       <crs:ColorNoiseReduction>25</crs:ColorNoiseReduction>
       <crs:ChromaticAberrationR>0</crs:ChromaticAberrationR>
       <crs:ChromaticAberrationB>0</crs:ChromaticAberrationB>
       <crs:VignetteAmount>0</crs:VignetteAmount>
       <crs:ShadowTint>-1</crs:ShadowTint>
       <crs:RedHue>0</crs:RedHue>
       <crs:RedSaturation>0</crs:RedSaturation>
       <crs:GreenHue>0</crs:GreenHue>
       <crs:GreenSaturation>0</crs:GreenSaturation>
       <crs:BlueHue>0</crs:BlueHue>
       <crs:BlueSaturation>0</crs:BlueSaturation>
       <crs:FillLight>0</crs:FillLight>
       <crs:Vibrance>+5</crs:Vibrance>
       <crs:HighlightRecovery>24</crs:HighlightRecovery>
       <crs:Clarity>+8</crs:Clarity>
       <crs:Defringe>0</crs:Defringe>
       <crs:HueAdjustmentRed>0</crs:HueAdjustmentRed>
       <crs:HueAdjustmentOrange>0</crs:HueAdjustmentOrange>
       <crs:HueAdjustmentYellow>0</crs:HueAdjustmentYellow>
       <crs:HueAdjustmentGreen>0</crs:HueAdjustmentGreen>
       <crs:HueAdjustmentAqua>0</crs:HueAdjustmentAqua>
       <crs:HueAdjustmentBlue>0</crs:HueAdjustmentBlue>
       <crs:HueAdjustmentPurple>0</crs:HueAdjustmentPurple>
       <crs:HueAdjustmentMagenta>0</crs:HueAdjustmentMagenta>
       <crs:SaturationAdjustmentRed>0</crs:SaturationAdjustmentRed>
       <crs:SaturationAdjustmentOrange>0</crs:SaturationAdjustmentOrange>
       <crs:SaturationAdjustmentYellow>0</crs:SaturationAdjustmentYellow>
       <crs:SaturationAdjustmentGreen>0</crs:SaturationAdjustmentGreen>
       <crs:SaturationAdjustmentAqua>0</crs:SaturationAdjustmentAqua>
       <crs:SaturationAdjustmentBlue>0</crs:SaturationAdjustmentBlue>
       <crs:SaturationAdjustmentPurple>0</crs:SaturationAdjustmentPurple>
       <crs:SaturationAdjustmentMagenta>0</crs:SaturationAdjustmentMagenta>
       <crs:LuminanceAdjustmentRed>0</crs:LuminanceAdjustmentRed>
       <crs:LuminanceAdjustmentOrange>0</crs:LuminanceAdjustmentOrange>
       <crs:LuminanceAdjustmentYellow>0</crs:LuminanceAdjustmentYellow>
       <crs:LuminanceAdjustmentGreen>0</crs:LuminanceAdjustmentGreen>
       <crs:LuminanceAdjustmentAqua>0</crs:LuminanceAdjustmentAqua>
       <crs:LuminanceAdjustmentBlue>0</crs:LuminanceAdjustmentBlue>
       <crs:LuminanceAdjustmentPurple>0</crs:LuminanceAdjustmentPurple>
       <crs:LuminanceAdjustmentMagenta>0</crs:LuminanceAdjustmentMagenta>
       <crs:SplitToningShadowHue>138</crs:SplitToningShadowHue>
       <crs:SplitToningShadowSaturation>13</crs:SplitToningShadowSaturation>
       <crs:SplitToningHighlightHue>0</crs:SplitToningHighlightHue>
       <crs:SplitToningHighlightSaturation>0</crs:SplitToningHighlightSaturation>
       <crs:SplitToningBalance>0</crs:SplitToningBalance>
       <crs:ParametricShadows>0</crs:ParametricShadows>
       <crs:ParametricDarks>0</crs:ParametricDarks>
       <crs:ParametricLights>0</crs:ParametricLights>
       <crs:ParametricHighlights>0</crs:ParametricHighlights>
       <crs:ParametricShadowSplit>25</crs:ParametricShadowSplit>
       <crs:ParametricMidtoneSplit>50</crs:ParametricMidtoneSplit>
       <crs:ParametricHighlightSplit>75</crs:ParametricHighlightSplit>
       <crs:SharpenRadius>+1.0</crs:SharpenRadius>
       <crs:SharpenDetail>25</crs:SharpenDetail>
       <crs:SharpenEdgeMasking>0</crs:SharpenEdgeMasking>
       <crs:PostCropVignetteAmount>0</crs:PostCropVignetteAmount>
       <crs:GrainAmount>0</crs:GrainAmount>
       <crs:ColorNoiseReductionDetail>50</crs:ColorNoiseReductionDetail>
       <crs:ConvertToGrayscale>False</crs:ConvertToGrayscale>
       <crs:ToneCurveName>Medium Contrast</crs:ToneCurveName>
       <crs:ToneCurve>
    <rdf:Seq>
    <rdf:li>0, 0</rdf:li>
    <rdf:li>32, 22</rdf:li>
    <rdf:li>64, 56</rdf:li>
    <rdf:li>128, 128</rdf:li>
    <rdf:li>192, 196</rdf:li>
    <rdf:li>255, 255</rdf:li>
    </rdf:Seq>
       </crs:ToneCurve>
       <crs:CameraProfile>Adobe Standard</crs:CameraProfile>
       <crs:CameraProfileDigest>3DA8CE4A626CE36A1D0C55BF157793C9</crs:CameraProfileDigest>
       <crs:HasSettings>True</crs:HasSettings>
      </rdf:Description>
    </rdf:RDF>
    </x:xmpmeta>

    I’m pretty sure Adobe NEVER intended for someone to copy an XMP file from one photo to another outside of LR as a way to replicate settings.   You can make a preset from a photo, as discussed, or if you don’t want to do that, copy-paste the settings from a representative photo that you initially select to one or more new photos.  You could have a special LR folder that holds standard photos to copy/paste from.  Of course creating a Develop preset from the representative photo is the “normal” way to handle such situations, but maybe you have hundreds of different situations to copy settings from and don’t want to create presets for each one, but I’d argue that you could create a complex folder hierarchy for your presets and still have them findable without that much problem.
    As far as the mystery about why some photos show Reset and some show From Metadata, is the Process Version (down in Camera Calibration) of the photo before reading the settings the same between the two situations?  And in general, are these virgin photos newly imported into LR or have some been modified in LR, already?  Does an XMP file already exist for any of these, where that XMP is being overwritten by your external-to-LR copying?  Or do you have auto-write-XMP enabled and your hand-copied XMP is getting overwritten by LR, automatically, before you have a chance to read in anything?

  • How do I reconnect my xmp files in PE9?

    After moving and copying photos between two internal and one external hard drive I find I have a lot of xmp files in the Recycle bin.  Can I "reconnect" these files to the images and video clips they belong to?  The dates are messed up and tags are missing from a lot of my stuff after all the moving.
    Tim K

    dsf,
    Not sure exactly how you moved your library but this link may help
    http://www.ilounge.com/index.php/articles/comments/moving-your-itunes-library-to -a-new-hard-drive/

  • .XMP files no longer appear as sidecars--how to clear metadata?

    Photoshop CS2 ver 9.0.2
    Bridge ver 1.0.4.6
    ACR ver 3.7
    eMac G4 800 MHz
    Mac OS X ver 10.4.9
    1 Meg RAM
    12 GB available disk space
    Bridge and Photoshop are set to save metadata in .XMP sidecar files, but sidecar files no longer appear. That is, up till a few days ago, .XMP files appeared when I opened raw files, but no longer. The drop-down menu is still set to save metadata in sidecar files.
    Cannot clear metadata in Bridge. I can select "Camera Raw Defaults" in ACR, but that doesn't clear cropping.
    1) How do I return already-stored metadata to .XMP files?
    2) How do I get PSCS2 to store future metadata as .XMP files?
    3) How do I clear metadata currently stored in ACR/PS database?
    4) What did I do to cause system to store metadata in ACR/PS database despite being set to save in sidecar files?
    Thanks.
    --HC

    Noel,
    Excellent point.  I have no idea.  Maybe this was only working for
    .PSDs/etc. (which contain the metadata embedded in the file itself[,
    right?]).  I may have been deluding myself this whole time.  It's
    possible that it never really worked the way I thought it did to begin with.
    But, more specifically, here's the current question:  If I have this
    file (which is a backup from long ago):
    J:\backup of M90\Documents and Settings\philipt\Application
    Data\Adobe\CameraRaw\Database
    ...assuming that drives are currently mapped (by drive letter) the same
    way they were when that backup was made), can I just replace the current
    file:
    C\Documents and Settings\philipt\Application Data\Adobe\CameraRaw\Database
    ...with the one from J: and expect it to work correctly?
    What's the worst that can happen if I do this?
    BTW, the file on J: is 2,569 Kb; the (new) one on C: is 2,754 Kb.  This
    doesn't seem to bode well, since the old one (J:) should have much, much
    more data in it (assuming that the "Database" file per se is where the
    metadata is stored): the older file has complex,
    multi-tiered data for 10s of 1000s of images.  "??"
    Thanks again for your willingness to help with this!!
    Aloha,
    -pt

  • How can I make metadata saved to xmp file stay saved?

    When a raw file badge shows that the file has been changed, I use Metadata Save to File & for the large majority of my images, the badge goes away and Metadata Status Changed does not show the file.  For some of my files, however, the Save to File command doesn't work properly.  If I am only displaying files with changes, the file briefly disappears, then returns.  Even if I go to Windows Explorer and delete the xmp file, then again Save metadata to file, it pops up again with the badge saying it needs to be saved.  Can anyone tell me what I might be doing wrong, or is there a bug?  I'm using Lightroom 4.3 64 bit on Windows 7.

    I have determined one definite cause for this problem, documented (see 2nd post) here:
    http://feedback.photoshop.com/photoshop_family/topics/lightroom_4_4rc_metadata_needs_to_be _saved_status_not_cleared_by_saving_metadata
    As has been mentioned, following metadata save with metadata read is a work-around.
    Note: you can see exactly, everything, the difference between metadata in catalog and metadata in xmp on disk, using ChangeManager's "Compare Catalog to Disk" feature; hint: choose 'No Exclusions' to see the "inconsequential" differences too. Reminder: this does a bunch of stuff involving xmp file copying and saving xmp / reading metadata / restoring afterward... - which presents lots of hoops to jump through, at first, in Windows, and forever, on Mac, but if you tough it out, you will get the pot of result gold at the end of the hoop rainbow...
    Cheers,
    Rob

  • Bridge stops recognizing it's own .xmp files from Canon 5DMKIII

    I use Bridge to add keywords to my RAW files. I use both a Canon 1D MKII and a Canon 5D MKIII camera. I use Canon's "Digital Photo Professional" (DPP) to process my RAW files because I prefer the colors (I am a picky perfectionist, so don't try and convince me to use ACR to process my RAW files!) When I make changes to my RAW files shot with the 5DMKIII in DPP and "save" the changes to the RAW files, Bridge suddenly doesn't recognize the file's associated .xmp file, and my keyword association is lost. If I simply open the file in TextEditor and re-save it, suddenly Bridge recognizes the file again. RAW images shot and processed with this same procedure from my Canon 1D MKII don't exhibit this problem.
    This thread from a couple years ago is the same problem I am experiencing:
    http://forums.adobe.com/message/2933287#2933287
    Is there any other solutions to this? I shoot several thousand images per weekend, and opening each file in TextEdit and saving is NOT an option!
    Please help!
    P.S., I'm using Bridge CS5.1 v 4.1.0.54

    Wes Duenkel wrote:
    I am a picky perfectionist, so don't try and convince me to use ACR to process my RAW files!
    Birds of a feather you and I, except that (with the help of a very nice forum member here) I have actually managed to get the same color out of Camera Raw that I get from Canon, so that is now my default in Camera Raw.  Unfortunately, we created a profile for a different camera than you have (I use a 40D), so it is not applicable for you.  But I just wanted to comment to say that I know EXACTLY how you feel. 
    Sorry, I don't have much to offer re: help for your .xmp issue.
    -Noel

Maybe you are looking for