# “Automatically write changes into XMP”



## argonauta (Apr 22, 2018)

I love this option, “Automatically write changes into XMP”. But we know that performance worsens in this way. 
I have a suggestion, there might be an option to write changes into XMP when we close the program. What about?


----------



## Zenon (Apr 22, 2018)

Does this option leave sidecars after?


----------



## johnbeardy (Apr 22, 2018)

Well, we don't all know that performance worsens in this way. It's a background task.

The option creates sidecars for proprietary raw file formats, not for other file types. It can also trigger image backup routines.


----------



## Zenon (Apr 22, 2018)

Thanks


----------



## PhilBurton (Apr 22, 2018)

johnbeardy said:


> Well, we don't all know that performance worsens in this way. It's a background task.
> 
> The option creates sidecars for proprietary raw file formats, not for other file types. It can also trigger image backup routines.


Specifically, if you use DNG RAW files, changing just a few bytes of metadata will trigger a backup of the entire multi-MB DNG file.


----------



## Laura Smith (Apr 23, 2018)

PhilBurton said:


> Specifically, if you use DNG RAW files, changing just a few bytes of metadata will trigger a backup of the entire multi-MB DNG file.



Any idea if CrashPlan is smart enough to only upload the changes rather than the whole DNG?


----------



## palengh (Apr 23, 2018)

Will We be able to (force) write XMP sidecars for every file?
I know LR does it for RAW, and other proprietary formats, but how do we does LR to make XMP’s for all files?


Regards

Pål Engh
Fredrikstad, NORWAY


----------



## Jim Wilde (Apr 23, 2018)

palengh said:


> Will We be able to (force) write XMP’s for every file?
> I know LR does it for RAW, and other proprietary formats, but how do we does LR to make XMP’s for all files?



You can automatically write changes into XMP for every supported file-type, but XMP sidecars are only created for proprietary Raw files. With all other file-types (e.g. DNG, Jpeg, Tiff), Lightroom writes the updated XMP data directly into the XMP section of the file header.


----------



## palengh (Apr 23, 2018)

Jim Wilde said:


> palengh said:
> 
> 
> > Will We be able to (force) write XMP’s for every file?
> ...


I meant sidecars. 
We use Fotoware at work. ( http://www.fotoware.com). My idea would be to use Lightroom as a client for meta tagging. I have not yet tested if Fotoware picks up the XMP’s embedded into the file. I assume it will. 
Sadly the file change date is updated after an XMP change, fuzzing the FotoWeb sort order. 

Any ideas would be appreciated. 


Regards

Pål Engh
Fredrikstad, NORWAY


----------



## Linwood Ferguson (Apr 24, 2018)

Laura Smith said:


> Any idea if CrashPlan is smart enough to only upload the changes rather than the whole DNG?


Highly unlikely.

This is an area where I've periodically turned it on the turned it off, not exactly for DNG (which I do not use) but old JPG's.  I will run off and start doing face recognition, or maybe correcting typos in keywords.  I might change one keyword, and affect 1000 images including a lot of old JPG's, and suddenly LR is rewriting all those files.  Even if they are small, I hate having all that churn (every time you rewrite a file you risk it being corrupted -- tiny risk, but do a tiny risk enough times and.... ). 

So mostly I keep it off, and periodically go back and do a mass update of the XMP's.  Not as good as a backup, but it does cut down on the churn.

Keywords, frankly is the worst of it.  I (almost) never apply any kind of develop setting to more than a few images (other than ones just ingested), but just some minor keyword changes and you can touch thousands.


----------



## Hoggy (Apr 25, 2018)

argonauta said:


> I have a suggestion, there might be an option to write changes into XMP when we close the program. What about?



If you create that suggestion on the Adobe site, please post the link here.  I'll certainly vote for it.
It's really what I always do anyways, but manually via a smart collection method.

And yep, I know about those minor keyword changes causing a rewrite of possibly thousands.   I still do it though.

So if such an option would be added to preferences, then maybe have a checkmark box within the backup dialog, stating "Write changes into XMP (x images need updating)".


----------



## LouieSherwin (Apr 25, 2018)

I am pretty sure that writing to XMP is a background task so that will already minimize any performance contention. But as Linwood says adding multiple keywords can trigger multiple writes to the same files and when working with anything other than XMP sidecar files for proprietary raw files you can trigger a lot of disk activity both local and for any backups.

You could mimic a save metadata at close by using the "Metadata Status" in the filter bar.  Select all in that need to be updated and use the Metadata ->Save Metadata to file (Cmd-S) to write all the changes at one time. 

The save XMP feature was really intended to provide interoperability with Bridge and Photoshop and other external editors in the early days. I don't believe that it was never intended as any kind of backup for metadata though it is often mentioned in that context. 

I turned off "Automatically write changes to XMP" a long time ago having come to the conclusion that there is nothing to be gained over having a consistent and reliable backup procedure for your catalog and your images. Backing up the catalog frequently especially when doing a lot of important work will be the best protection against problems. 

-louie


----------



## Laura Smith (Apr 25, 2018)

LouieSherwin said:


> I turned off "Automatically write changes to XMP" a long time ago having come to the conclusion that there is nothing to be gained over having a consistent and reliable backup procedure for your catalog and your images. Backing up the catalog frequently especially when doing a lot of important work will be the best protection against problems.



Yeah, I might do the same. I turned it on with the mindset of insurance against Lr being mysteriously discontinued in the middle of the night one day. But in hindsight if that happens I think I'll have bigger things to worry about ...


----------



## Gnits (Apr 25, 2018)

Remember...this is a per catalog setting, not a system wide setting.


----------



## tspear (Apr 25, 2018)

Depending on how much you are doing and how fast you work, automatic  writing meta-data can slow your system. 
Easiest example, make a keyword change and then run an import of a 1000 images with facial recognition turned on. 
However, for my normal usage, I never notice that write meta-data is enabled.

Now, a trick I have not tried since early 6.X. I convert to DNG (skipping whole reason why), but did not want the updates to meta-data in the DNG at the time. So I enabled the read-only flag on all my DNG files; Lr then proceeded to create an XMP sidecar file for each DNG. I did not do this very long, but it was possible. I no longer have a reason to test this functionality (and not sure I would recommend it anyway) but it did work.


----------



## Hoggy (Apr 26, 2018)

tspear said:


> Now, a trick I have not tried since early 6.X. I convert to DNG (skipping whole reason why), but did not want the updates to meta-data in the DNG at the time. So I enabled the read-only flag on all my DNG files; Lr then proceeded to create an XMP sidecar file for each DNG. I did not do this very long, but it was possible. I no longer have a reason to test this functionality (and not sure I would recommend it anyway) but it did work.



That's a good  trick to try and keep in mind.  Right now, I have an extension that will write xmp sidecars for all file types, including virtual copies - should I ever feel the need to.  But it may stop working some day, and I wouldn't know enough about Lua to fix it or write my own.  And something makes me feel that Adobe would not add such functionality natively, although it would be nice.


----------



## PhilBurton (Apr 26, 2018)

Hoggy said:


> That's a good  trick to try and keep in mind.  Right now, I have an *extension *that will write xmp sidecars for all file types, including virtual copies - should I ever feel the need to.



Hoggy,

Extension?  Do you mean plug-in?  Link?  

Phil


----------



## Hoggy (Apr 26, 2018)

PhilBurton said:


> Extension?  Do you mean plug-in?  Link?



Tomato, tomaato. 
pm sent.


----------



## tspear (Apr 26, 2018)

@Hoggy 

Send me a PM too! I wanna know. 

Tim


----------



## palengh (Apr 26, 2018)

Hoggy said:


> ... I have an extension that will write xmp sidecars for all file types, including virtual copies - should I ever feel the need to.



@Hoggy

Send me a PM too! I wanna know. 


Regards

Pål Engh
Fredrikstad, NORWAY


----------



## johnbeardy (Apr 26, 2018)

It's certainly possible for a plugin to create xmp files for files that don't usually have them.

But don't overestimate the value of those sidecars. If you try to read the metadata into LR and other apps, it's not always clear whether they read the metadata from the image file or from the sidecar.  [Without checking] I am pretty sure that because Lr doesn't expect to find an xmp sidecar for a DNG, it will ignore it.


----------



## Johan Elzenga (Apr 26, 2018)

johnbeardy said:


> It's certainly possible for a plugin to create xmp files for files that don't usually have them.
> 
> But don't overestimate the value of those sidecars. If you try to read the metadata into LR and other apps, it's not always clear whether they read the metadata from the image file or from the sidecar.  [Without checking] I am pretty sure that because Lr doesn't expect to find an xmp sidecar for a DNG, it will ignore it.


Correct. Apple Aperture can write sidecar files for any type of image, so also for jpeg and tiff, for example. But when you import such a jpeg or tiff into Lightroom, metadata like keywords will not come across, because Lightroom ignores the sidecar.


----------



## Hoggy (Apr 27, 2018)

Yeah, I'm not sure how LR would natively handle external sidecars for filetypes that support embedding.  One would definitely need  to check that.  But that plugin creates menu items for reading from the external sidecars - and also recreating missing virtual copies from xmp sidecars from virtual copies that were saved by it.

*BUT - and this is important:* that plugin stopped being developed, so it may not work fully anymore - or some aspects to it may stop working at any point in future versions of LR.  *So make sure you test things, if you're planning to rely on it.*

Also, if interested, just pm me directly - without writing a message here.  I honestly wasn't intending quite the stir-up, and don't want to burden this thread.


----------



## Hoggy (Apr 27, 2018)

Hoggy said:


> I honestly wasn't intending quite the stir-up, and don't want to burden this thread.



Yet, OTOH, the devil in me says that maybe people _should_ write here..   If anyone from Adobe is reading, then they might realize that people really _do_ want such functionality.
Come to think of it, even though I haven't used that plugin in quite a while - I probably should write xmp sidecars for just all my virtual copies.  The fact that there's no secondary/tertiary external backup for those has always made me feel a bit uneasy about using them, which is why I always make sure to snapshot them and 'save metadata' the main image.  The problem comes in, though, when LR won't show the 'has changed' badge on the main image (nor the VC) for snapshots created that way...  And I may easily forget to force a save - or it doesn't quite register, and I don't notice that it hasn't.

And then there's the aspect that should an unlikely total meltdown occur, VC's won't automatically be created by LR natively.  At least with that plugin, there's a chance that that part will still work down the road.  Although the problem would still remain, of the VC's or main image never showing a 'has changed' badge.


----------



## johnbeardy (Apr 27, 2018)

Hoggy said:


> Yet, OTOH, the devil in me says that maybe people _should_ write here..
> If anyone from Adobe is reading, then they might realize that people really _do_ want such functionality.



No, it does make sense to mention the existence of this plugin, but it's important to mention the dependence on the plugin for reading these sidecars and the fact that it's no longer being developed. From what I know of the area, I would expect that it still works, but I would not wish to fix it if there is a problem.

I'd be very surprised if Adobe opened this can of worms, and  the reading issue extends to third party apps, as Johan's example shows. Sidecars are a workaround for proprietary file formats that aren't publicly documented, not for standard file formats that don't need them.

John


----------



## argonauta (Apr 22, 2018)

I love this option, “Automatically write changes into XMP”. But we know that performance worsens in this way. 
I have a suggestion, there might be an option to write changes into XMP when we close the program. What about?


----------



## tspear (Apr 27, 2018)

johnbeardy said:


> I'd be very surprised if Adobe opened this can of worms, and  the reading issue extends to third party apps, as Johan's example shows. Sidecars are a workaround for proprietary file formats that aren't publicly documented, not for standard file formats that don't need them.
> 
> John



Digikam, darktable, rawtherapee, iMatch.... Many applications outside Adobe seem to be moving to sidecars only an not touching the original file actually. Not sure if these is because of a technical reason, philosophical, practical....

Tim


----------



## johnbeardy (Apr 27, 2018)

I'm not sure what any of those apps do is of much importance, Tim. Just backwards-looking desktop stuff?

It's as much philosophical as anything - if an image file format is designed to hold metadata, why complicate life by adding sidecars? Because it does.


----------



## Hoggy (Apr 27, 2018)

The place where sidecars really makes a whole lot of sense, though, is for virtual copies.  Although the terminology of 'sidecars' might not exactly fit -- but I can't think of a better word right now. 

And being able to recreate missing virtual copies from those 'sidecars' should also be included.

Whatever the original intention of '.xmp' files (or embedded xmp) is, the fact remains that nowadays xmp has evovled into also being a type of fallback backup for [many?] people.  And the virtual copies are a glaring hole in that regard.

Virtual copies would then be treated just as if they were real files..  The catalog always holds the current state as usual, and badges would show up for the changed states.


----------



## johnbeardy (Apr 27, 2018)

Why does it make sense? VCs' absence from embedded or sidecar metadata is an odd exception, but that's because Adobe have never resolved the inconsistency of having two virtual entities, VCs and snapshots.

As for fallback backup, in LR terms that's just lazy thinking


----------



## Hoggy (Apr 27, 2018)

......Although, just to play devil's advocate here, the can of worms may not be as bad as one thinks from the outset.  It could possibly be handled by a just a couple of preference items.  For example, I think Capture One has such preference items, IIRC - or at least something similar.

........  It could be something like 'always prefer sidecars over embeded xmp', and 'never embed xmp into embedding-capable filetypes'.  Well, someone might work out better wording, but that would be the general idea.

The use case would be for those people that absolutely don't want to touch, in any way, the original files that LR is pointing to.
.....  Obviously, judging by my sig, I am *not* one of these people, though - due to the hash layer. ​


----------



## Hoggy (Apr 27, 2018)

johnbeardy said:


> Why does it make sense? VCs' absence from embedded or sidecar metadata is an odd exception, but that's because Adobe have never resolved the inconsistency of having two virtual entities, VCs and snapshots.
> 
> As for fallback backup, in LR terms that's just lazy thinking



Well, it makes sense to _me_... 

Having that external '.xmp' file would help resolve that inconsistency.  Both the original file's xmp, as well as the VC's '.xmp' file would hold their own snapshots.  I'm one of those that finds different use cases for each, equally.

As far as xmp also acting as a fallback backup for some of us, it just provides us a feel-good security blanket..  Like a pacifier, if you will.  And I likes me my pacifier!    ...Not right or wrong...  Just a pacifier.


----------



## Johan Elzenga (Apr 27, 2018)

tspear said:


> Digikam, darktable, rawtherapee, iMatch.... Many applications outside Adobe seem to be moving to sidecars only an not touching the original file actually. Not sure if these is because of a technical reason, philosophical, practical....


There is no raw converter that changes the original raw file. They all store their edits either in a database or in sidecar files. Sidecars for RGB files is a different story. Some do, others don't.


----------



## Hoggy (Apr 27, 2018)

JohanElzenga said:


> There is no raw converter that changes the original raw file. They all store their edits either in a database or in sidecar files. Sidecars for RGB files is a different story. Some do, others don't.



I wouldn't say that's exactly true...  There are cameras that write DNG's natively - my Pentax's, for intance - and Leica IIRC, and some others, I think.  If one would do a 'save metadata' on those, LR would write it into the DNG.  True, the image data still isn't touched, but the file _is_ touched/altered by that 'save'.


----------



## PhilBurton (Apr 28, 2018)

johnbeardy said:


> Why does it make sense? VCs' absence from embedded or sidecar metadata is an odd exception, but that's because Adobe have never resolved the inconsistency of having two virtual entities, VCs and snapshots.
> 
> As for fallback backup, in LR terms that's just lazy thinking


John,

I have to respectfully disagree with the last sentence here.  It's not just hypothetical these days that catalog backups can be corrupted.  Relying on just the catalog, all information about VCs would be lost.  A plug-in that both writes out and then reads back VC metadata is "defense in depth" or "layered defense" against data loss.  

I would find this sort of plug-in  very valuable.

I agree that Adobe needs to resolve the inconsistency you point out.  Perhaps as a group, we could come up with enhancements that would focus each virtual entity on a different use case.

Phil


----------



## johnbeardy (Apr 28, 2018)

I wouldn't take out of proportion the recent bug affecting backups, Phil, or extend it to the issue of VCs not being backed up (or flags, stacks, collection membership, custom fields, history....). For me, this bug should make people question whether they should rely on LR to backup itself, rather than relying on a dedicated backup tool. I have always preferred the latter, perhaps more from gut instinct.

Snapshots should be VCs, and VCs should be Snapshots. OK, there are a few visibility issues and metadata issues that would need to be resolved, but I can't think of another app that offers competing types of virtual file. 

John


----------



## Johan Elzenga (Apr 28, 2018)

Hoggy said:


> I wouldn't say that's exactly true...  There are cameras that write DNG's natively - my Pentax's, for intance - and Leica IIRC, and some others, I think.  If one would do a 'save metadata' on those, LR would write it into the DNG.  True, the image data still isn't touched, but the file _is_ touched/altered by that 'save'.


I was talking about 'original raw files'. I know there are a few cameras that can shoot in DNG, but that meant proprietary raw files.


----------



## Hoggy (Apr 29, 2018)

johnbeardy said:


> I wouldn't take out of proportion the recent bug affecting backups, Phil, or extend it to the issue of VCs not being backed up (or flags, stacks, collection membership, custom fields, history....). For me, this bug should make people question whether they should rely on LR to backup itself, rather than relying on a dedicated backup tool. I have always preferred the latter, perhaps more from gut instinct.



As someone that in fact _did_ rely on LR-backups and_ did_ have LR-backup corruption, I would most certainly have been *very* glad that I always write metadata to files, should I have needed a backup - whether that would be inside DNG's or separate ".xmp" files.  I work around the lack of VC ".xmp" files by snapshotting the states of the VC with an automatic {copy-name.date - custom text} format - then trying to make sure to force-save the main file due to a lack of a badge showing up.
Flags, stacks, and collections and whatnot can be rebuilt in such a worst-case scenario - which I could have had I not been writing metadata to files - but develop instructions, not so easily.  As someone that only uses smart collections (people really aught to be using proper metadata organization!  ), I don't have to know/remember which pictures should go in which collections..  All I have to know is why any collection should deserve to exist in the first place, to recreate the smart collection.  If your flags are important, then every once in a while filter them and put a keyword of "flag" on them.  (Honestly, LR really out to be putting flags, stacks, and collection info into xmp.  And, I forget, does LR really not write custom fields into xmp either?  Well, it should do that too then.   But, I digress.)

Although, yes, the bug is certainly making me re-evaluate relying solely on LR for catalog backups.  The problem I'm running across is that LR will do the backup at a [normally] proper time - when the catalog is closed and in a proper state.  I would think that if an automated dedicated backup tool did a  'shadow-copy', it could copy the file when it's in an improper state.  But as someone with cognitive-memory (&other) problems, please just trust me that manually starting a dedicated tool's catalog backup task every time I exit LR (or even at any certain times, like once a day or whatnot) is not as easy as it sounds to other people (or even to myself!  ).  So the LR-generated backups still seem to be the best solution, to me --- when they're working correctly, of course.
So what do people do to make sure a dedicated tool's [automatic] backup task doesn't copy the catalog when it's in an improper state?


----------



## Gnits (Apr 29, 2018)

All my data, incl Lr catalogs is backed up automatically at 6 am every morning.  My Pc is in sleep mode and returns to sleep mode after the backup.  I start my day knowing all my data is backed up.


----------



## Hoggy (Apr 29, 2018)

Gnits said:


> All my data, incl Lr catalogs is backed up automatically at 6 am every morning.  My Pc is in sleep mode and returns to sleep mode after the backup.  I start my day knowing all my data is backed up.



Hmm..  I  have quite fluid sleep/wake/nap patterns.  Although of course there's times when the computer will go to sleep,  but the 2 backup programs I have (Cobian - stable/old-reliable & JaBut - moving to soon) don't have options I could find that wake the computer - or detect a sleeping computer.

But don't you ever end up leaving LR open when it ends up going to sleep?  Wouldn't it end up backing up an unstable catalog file in that situation?

And which programs are there that would wake the computer like that - and  hopefully even xx minutes after going to sleep?  I would hope for open-source or freeware, as outside of the sticky LR situation, things are covered between Cobian & Goodsync.  Of course I'll do some Googling, but would appreciated any possible directions I should head toward.


----------



## glg (Jul 20, 2018)

LouieSherwin said:


> I am pretty sure that writing to XMP is a background task so that will already minimize any performance contention. But as Linwood says adding multiple keywords can trigger multiple writes to the same files and when working with anything other than XMP sidecar files for proprietary raw files you can trigger a lot of disk activity both local and for any backups.
> 
> You could mimic a save metadata at close by using the "Metadata Status" in the filter bar.  Select all in that need to be updated and use the Metadata ->Save Metadata to file (Cmd-S) to write all the changes at one time.
> 
> ...


Greetings!
*XMP *neophyte here (non-photographer, IT support for photographer).  

Would you help me *understand if these two things are equal and/or produce the same target file when the image is exported to JPG or TIFF?:*
(1)  having the LR CC-Classic catalog option in LR>Edit>Catalog Settings>Metadata _*set to*_ "Automatically Write Changes to XMP"
(2) when exporting images, to choose File > Export and in the *Metadata *section choosing to include "All Metadata"
I have instructions to output images from LR with all the metadata for a client that uses Photoshop but not Lightroom.  The "raw" files were primarily drone DNG files and some NEF stills - both edited in LR CC Classic on a Mac.

I typically just choose the Export with All Metadata for the JPG and TIFF output - am I getting all the same info that I would if automatically writing changes to XMP?  .... or is this apples/oranges?

Thanks!
Gail


----------



## Johan Elzenga (Jul 20, 2018)

glg said:


> Would you help me *understand if these two things are equal and/or produce the same target file when the image is exported to JPG or TIFF?:*
> (1) having the LR CC-Classic catalog option in LR>Edit>Catalog Settings>Metadata _*set to*_ "Automatically Write Changes to XMP"
> (2) when exporting images, to choose File > Export and in the *Metadata *section choosing to include "All Metadata"


No, they are not equal. Write Changes to XMP will write all metadata to the file header, including the Lightroom edits (which can only be read by Adobe products). Export with 'Include All Metadata' will not write the edits to the metadata (everything else will be written).


----------



## clee01l (Jul 20, 2018)

Welcome to the forum.
"Automatically Write Changes to XMP" applies only to the source files.. If the source files are JPEG, TIFF, or DNG, the source file contains an XMP section in the header block.  "Automatically Write Changes to XMP" will open the source file and write the metadata there.  NEF source files are proprietary and do not contain an XMP  section in the header block.  For these, an XMP file (sidecar) is created and can store this XMP metadata.
"Export with All Metadata for the JPG and TIFF" does just that for the newly created export files. And these export generated  new files will contain an XMP section in the header block.
The XMP Section will contain the final develop parameters  used to generated a derivative from the original image data. It will also contain any snapshots saved in the develop module.  If the file is the original source file. You can use LR or Photoshop to generate a derivative from that source file.  If the file is a derivative, then the XMP develop settings will be the referenced values use to create the derivative image.


----------



## glg (Jul 20, 2018)

JohanElzenga said:


> No, they are not equal. Write Changes to XMP will write all metadata to the file header, including the Lightroom edits (which can only be read by Adobe products). Export with 'Include All Metadata' will not write the edits to the metadata (everything else will be written).


Johan - confirm that when I export an edited image from LR with "include all metatdata" but without write-XMP , it creates the  JPG or TIFF *edited photo* but without the specific detail on adjustments made in LR.  In your opinion, does a client's webmaster or art director needed the adjustment detail for the work they would do in Photoshop?  Or if the adjustment edit detail is needed would they know to ask for the XMP edit info?  Thanks much, Gail


----------



## glg (Jul 20, 2018)

clee01l said:


> Welcome to the forum.
> "Automatically Write Changes to XMP" applies only to the source files.. If the source files are JPEG, TIFF, or DNG, the source file contains an XMP section in the header block.  "Automatically Write Changes to XMP" will open the source file and write the metadata there.  NEF source files are proprietary and do not contain an XMP  section in the header block.  For these, an XMP file (sidecar) is created and can store this XMP metadata.
> "Export with All Metadata for the JPG and TIFF" does just that for the newly created export files. And these export generated  new files will contain an XMP section in the header block.
> The XMP Section will contain the final develop parameters  used to generated a derivative from the original image data. It will also contain any snapshots saved in the develop module.  If the file is the original source file. You can use LR or Photoshop to generate a derivative from that source file.  If the file is a derivative, then the XMP develop settings will be the referenced values use to create the derivative image.


Thank you Cletus!


----------



## Johan Elzenga (Jul 21, 2018)

glg said:


> Johan - confirm that when I export an edited image from LR with "include all metatdata" but without write-XMP , it creates the  JPG or TIFF *edited photo* but without the specific detail on adjustments made in LR.  In your opinion, does a client's webmaster or art director needed the adjustment detail for the work they would do in Photoshop?  Or if the adjustment edit detail is needed would they know to ask for the XMP edit info?  Thanks much, Gail


Nobody will ask for it, because it's already applied. If you export an image as TIFF or JPEG, then the edits are applied to that image, period. Regardless of whether you used Write XMP to files or not. As Cletus explained, 'write XMP' only applies to the originals, it does not mean anything for exported files.


----------



## glg (Jul 21, 2018)

Thank you Johan - this was very helpful.  I appreciate your time.  Regards,  Gail


----------

