Library module Some questions on virtual copies

[JVMiddleEast]

Lightroom Version Number

14.01

Operating System

1. macOS 15 Sequoia

Dear forum members,

I am struggling a bit with the concept of virtual copies.

Do I understand correctly that:

1. If you make a virtual copy, you dont copy the original RAW file, but you omnly create an additional thumbnail.
2. This additional thumbnail allows you to create two different editing versions
3. If you use collections (like I do) then you can add the virtual copy to another collection (so basically the RAW file stays in the folder, and the two edited versions end up in two different collections.
4. If you edit the virtual copy, those edits only impact the copy, the original edit remains unchanged
5. You can create as many virtual copies of one raw file as you want.

Assuming (better put hoping) the above is correct than this leads to the following questions:

1. If I have two different edit versions in two different collections, which version will I then see if I go to the folder which holds the raw file? The first edit, the last edit or both?
2. After I have created the virtual copy, is it than possible to create a new file based on the virtual copy (meaning can I then make a real copy instead of the virtual copy)?
3. Is it possible to rename the virtual copy only?

I thought about testing this out with some photos, but to be honest: I sense that by doing so, there is a risk of messing up my library and catalogue (thats last thing I want).

I am looking forward reading your views and feedback on this.

Thanks in advance.

 

[Johan Elzenga]

Lightroom edits are stored in the catalog as metadata. A virtual copy is an extra set of such metadata. That means that they both refer to the same original image. The first (and often only) set of metadata is considered the original, so Lightroom will always show the original and next to the original it shows any virtual copies. So the answer to your questions is:
1: You will see both the original and the copies.
2: You can export a virtual copy, which then becomes a real copy.
3: You can change the ‘Copy Name’. If you rename the file name when you have a VC selected, then the original file will be renamed.

 

[clee01l]

Also the concept is two fold. The original copy is known as the Master copy and usually has no value assigned in the CopyName field. Virtual Copies default to the CopyName field being assigned "Copy1", Copy2, etc. Although you can assign any name you wish in the CopyName field.

Any Virtual copy can be promoted to Master Copy in the Library Menu {Photo}{Set copy as Original}. The Master Copy then appears in the thumnail with the turned up corner icon and the other copy then appeara as the original master copy. This is very useful if you decide to abandon the original Master and want to remove it from Lightroom without deleting the original file referenced by it.

 

[JVMiddleEast]

Lightroom edits are stored in the catalog as metadata. A virtual copy is an extra set of such metadata. That means that they both refer to the same original image. The first (and often only) set of metadata is considered the original, so Lightroom will always show the original and next to the original it shows any virtual copies. So the answer to your questions is:
1: You will see both the original and the copies.
2: You can export a virtual copy, which then becomes a real copy.
3: You can change the ‘Copy Name’. If you rename the file name when you have a VC selected, then the original file will be renamed.

Thank you so much. It confirms what I suspected but wasn’t quit sure off.

Thanks.

 

[JVMiddleEast]

Also the concept is two fold. The original copy is known as the Master copy and usually has no value assigned in the CopyName field. Virtual Copies default to the CopyName field being assigned "Copy1", Copy2, etc. Although you can assign any name you wish in the CopyName field.

Any Virtual copy can be promoted to Master Copy in the Library Menu {Photo}{Set copy as Original}. The Master Copy then appears in the thumnail with the turned up corner icon and the other copy then appeara as the original master copy. This is very useful if you decide to abandon the original Master and want to remove it from Lightroom without deleting the original file referenced by it.

Thank you so much.

If I combine your input plus Johan’s input, I get exactly what I was hoping for;

1 master file (saves storage of unnecessary copies of the 45 mb image files)
Multiple different edits of the master file using virtual copies
I can export both edited versions (which will create two different exported files)
And if so required I can still “upgrade” one of the virtual copies to a second new master file and rename as I see fit
And as a bonus: the original master RAW remains unchanged and all edits remain non-destructive

In short: I love it

Thank you both very much

Jurry

 

[Califdan]

A couple of other points to be aware of which may or may not be relevent.

1) If you sync a VC to the Adobe cloud it shows up in the Adobe cloud as a regular image.

2) If you save XMP data to disk, only the metadatra associated with the master image is saved. The metadata associated with the VC is not saved to disk

3) For some purposes a "Snapshot" can be used in place of a VC. These work differently than VC's but in both cases provide a way to see what images looked like with different edits. A VC is an additional entry in the catalog for the same image which (other than pointing to the same image file) are quite independent of each other. On the other hand a Snapshot is a marker in the edit history that you can return to by clicking the snaphost name. While VC's are way more versatile, I do find that for some purposes Snapshots work better. As an example where a snapshot may be a better choice, let's say you edit an image and send it off to a competition. Then based on feedback from the judge, you do some additional edits and send it off to a different competition. In this case Snapshots can be used to show that state of the image used in competion 1 and the state it was in when sent to competiton 2.

 

[JVMiddleEast]

A couple of other points to be aware of which may or may not be relevent.

1) If you sync a VC to the Adobe cloud it shows up in the Adobe cloud as a regular image.

2) If you save XMP data to disk, only the metadatra associated with the master image is saved. The metadata associated with the VC is not saved to disk

3) For some purposes a "Snapshot" can be used in place of a VC. These work differently than VC's but in both cases provide a way to see what images looked like with different edits. A VC is an additional entry in the catalog for the same image which (other than pointing to the same image file) are quite independent of each other. On the other hand a Snapshot is a marker in the edit history that you can return to by clicking the snaphost name. While VC's are way more versatile, I do find that for some purposes Snapshots work better. As an example where a snapshot may be a better choice, let's say you edit an image and send it off to a competition. Then based on feedback from the judge, you do some additional edits and send it off to a different competition. In this case Snapshots can be used to show that state of the image used in competion 1 and the state it was in when sent to competiton 2.

Thanks for your input.

I hadn't thought about using snapshots, but it is an excellent suggestion. It will probably be beneficial for part of my work; for other parts, I definitely require virtual copies and half of that work will require later upgrades to new full-image copies.

Under 2, you mentioned that metadata for the virtual copy is not stored on disk. Then where is it stored?

Jurry

 

[Califdan]

Under 2, you mentioned that metadata for the virtual copy is not stored on disk. Then where is it stored?

All the metadata for a VC is stored in the LrC catalog.

By "on disk" I mean that it is not stored in the image file itself nor is it stored as an XMP side car file next to the image file. However, if you EXPORT a VC, then indeed all the metadata for the VC is included in the exported file.

The reason I mention that is for folks who have chosen to store XMP data on disk (which is in addtion to its being stored in the catalog). Some save metadata to disk on a case by case basis but others turn on the automatically save XMP data for all the images in the catalog. As there is only one image file from which many VC's may be derived there is only one image file (or XMP side car file) in which to place the XMP data and they wisely decided that the XMP data they would store there (if asked to store any) would be that of the Master image and not one of the VC's

 

[JVMiddleEast]

All the metadata for a VC is stored in the LrC catalog.

By "on disk" I mean that it is not stored in the image file itself nor is it stored as an XMP side car file next to the image file. However, if you EXPORT a VC, then indeed all the metadata for the VC is included in the exported file.

The reason I mention that is for folks who have chosen to store XMP data on disk (which is in addtion to its being stored in the catalog). Some save metadata to disk on a case by case basis but others turn on the automatically save XMP data for all the images in the catalog. As there is only one image file from which many VC's may be derived there is only one image file (or XMP side car file) in which to place the XMP data and they wisely decided that the XMP data they would store there (if asked to store any) would be that of the Master image and not one of the VC's

Thanks for this explanation. It makes perfect sense.
The more I learn about LRC the more I’m surprised/impressed by the versatility of the system offering so many options for its users.

 

[BobMc]

I never edit the Master (original). I always make a VC. If I see a horizontal, vertical and B&W rendering, I make 3 VC’s. This lets me see the original and its renderings side by side in Grid mode or by selecting them all, an N will let me see them side by side larger.

One feature not yet mentioned is stacking. The master and all of its VC’s can be arranged with any one of them as the first in the list. If any one of the images, in the group, is selected, pressing the letter S will collapses them to have the first image show with all others hidden. The top image will have a small white block in its upper left showing the number of images in the stack. To open the stack, just select the image showing and press S to see all of the images in the stack again.

 

[ml_lrcl]

All the metadata for a VC is stored in the LrC catalog.

By "on disk" I mean that it is not stored in the image file itself nor is it stored as an XMP side car file next to the image file. However, if you EXPORT a VC, then indeed all the metadata for the VC is included in the exported file.

The reason I mention that is for folks who have chosen to store XMP data on disk (which is in addtion to its being stored in the catalog). Some save metadata to disk on a case by case basis but others turn on the automatically save XMP data for all the images in the catalog. As there is only one image file from which many VC's may be derived there is only one image file (or XMP side car file) in which to place the XMP data and they wisely decided that the XMP data they would store there (if asked to store any) would be that of the Master image and not one of the VC's

This excellent flag brings up something to be cautious about if you do generally save metadata to XMP (auto or manual), and then designate a different VC as the Master image.

When you designate a different VC as the Master image, Lightroom may flag that the file has new metadata changed "outside Lightroom." It'll ask if you want to import the settings from disk or overwrite with Lightroom settings. You want to be sure to overwrite using Lightroom's catalog.

The XMP metadata in the actual file hasn't been changed. It still has the XMP metadata—for the old master. What's changed is that the file's XMP metadata no longer matches what's now designated as the Master copy in Lightroom's catalog. The actual file on disk is meant to only have the Master's XMP metadata, as @Califdan says, so you need to write the "new Master" metadata to the file.

I manually save XMP, and a flag will usually show up immediately when designating a new master copy. I check to make sure this conflict is resolved each time I re-designate. I'm sure it crops up somehow if you auto-write, too.

 

[Johan Elzenga]

When you designate a different VC as the Master image, Lightroom may flag that the file has new metadata changed "outside Lightroom." It'll ask if you want to import the settings from disk or overwrite with Lightroom settings.

That doesn't (or shouldn't) happen, because if it did, then every little change you make in Lightroom (like adding a keyword) would flag this as well. The metadata haven't been changed 'outside of lightroom', they changed in Lightroom.

 

[ml_lrcl]

That doesn't (or shouldn't) happen, because if it did, then every little change you make in Lightroom (like adding a keyword) would flag this as well. The metadata haven't been changed 'outside of lightroom', they changed in Lightroom.

I agree, it doesn't seem like it really should happen? But, I consistently see it just with swapping masters on VCs. I've included the exact dialog language below as well as steps to recreate:

- Take DNG. Save metadata to file so that the Metadata Status is Up to Date.​

- Create VC. Adjust VC develop settings. Adjust Master develop settings. Save metadata to file for Master (you can't for VC, as expected).​

- Choose VC, "Set Copy as Original." Immediately, the Metadata Conflict icon appears on the formerly-VC-now-Master​

- Click on conflict icon. Dialog appears: "The metadata for this photo has been changed by both Lightroom and another application. Should Lightroom import settings from disk or overwrite disk settings with those from the catalog?" with either "Overwrite settings" or "Import settings from disk" options.​

"Overwrite settings" does what you'd expect Lightroom to have done in the first place—know that the file's XMP metadata is out of date with the catalog, and updated it the next time metadata was saved.

"Import settings from disk" applies the old Master's metadata (incl. develop settings) to the formerly-VC-now-Master.

Note: Sometimes the dialog will just be that the file has updated metadata, not that there's a conflict: "The metadata for this photo has been changed by another application."

I don't know why it thinks that the old XMP metadata is different because something other than Lightroom changed it on disk. But, I always run into this and have just taken it as a fact of life at this point.

 

[Johan Elzenga]

If you manually save metadata to file, and then change the metadata in Lightroom, then there is indeed a conflict, which will not be automatically resolved. So by itself this message is correct. The dialog is not correct however that another application is also involved. It's only Lightroom that has caused the difference, because you did not enable 'Automatically Write Changes to XMP'.

 

[Johan Elzenga]

So to me the conclusion of this is: If you want to write metadata to files regularly, then do this automatically. Or turn off the 'Metadata has changed' icon in View Options, so you will ignore these warnings because you won't see them.

 

[ml_lrcl]

Yup. Though, even if you turn off the icon, you'd probably want to save the metadata to file for the new master at some point. (In the manual save scenario.) It should then throw the error dialog, because Lightroom still thinks something else changed the file when that VC/master swap happened.

That's the weird part, and I really don't know why it thinks that—it seems like an incorrect interpretation on Lightroom's behalf, as you say. I just wanted to flag as something that does seem to happen/to be aware of, since saving metadata to file with master vs. VC came up.

In theory, I would actually think the auto-write might also run into the same thing? If a VC/master switch always causes Lightroom to think the file got changed outside of Lightroom, an auto-write should probably detect that too when writing after the swap. That'd throw up a dialog. Perhaps the auto-write process handles the VC/Master swap more gracefully than when using manual XMP saves. I haven't used auto-write and am not familiar with exactly when it triggers each write sequence, etc.

Lightroom of course expects the changes within Lightroom (keyword, develop) to bring it out of sync with the file, and handles that smoothly by noting that metadata has changed. It's just this one instance it seems to interpret differently, in my experience! If nobody else can actually replicate this, perhaps it's some weird permissions thing I have going on. It's ultimately not a big enough thing to dig into the "why" for me—it's just a fact of life.

 

[thommy]

Thanks for this explanation. It makes perfect sense.
The more I learn about LRC the more I’m surprised/impressed by the versatility of the system offering so many options for its users.

I agree! Even after years of using Lightroom Classic, I’m still occasionally surprised when I discover a new trick or feature I hadn’t fully explored before—though those moments are becoming less frequent. It’s a testament to just how versatile and feature-packed the system is. Lightroom Classic always seems to have something new to offer, even for seasoned users!

 

[Johan Elzenga]

In theory, I would actually think the auto-write might also run into the same thing? If a VC/master switch always causes Lightroom to think the file got changed outside of Lightroom, an auto-write should probably detect that too when writing after the swap. That'd throw up a dialog. Perhaps the auto-write process handles the VC/Master swap more gracefully than when using manual XMP saves. I haven't used auto-write and am not familiar with exactly when it triggers each write sequence, etc.

I have never tested it and I do not use auto-write, but I would expect that it will/can only throw up a warning if the metadata of the file on disk are newer than the metadata in the catalog. The other way round cannot happen, because as soon as the catalog metadata are newer, auto write takes place and solves that. I don’t see how switching a VC with the master can cause the metadata in the file to be newer, so I don’t think you’ll get a warning when you do that.

 

[ml_lrcl]

I have never tested it and I do not use auto-write, but I would expect that it will/can only throw up a warning if the metadata of the file on disk are newer than the metadata in the catalog. The other way round cannot happen, because as soon as the catalog metadata are newer, auto write takes place and solves that. I don’t see how switching a VC with the master can cause the metadata in the file to be newer, so I don’t think you’ll get a warning when you do that.

I understand, and agree with you in what should happen! I'm really not trying to argue with that or be difficult—I'm just relaying that my experience/testing has been to the contrary. I don't know why.

I think it might be good for me to start a thread in the Adobe Community around these specific behaviors? It truly hadn't clicked how "off" they are. If it is indeed a bug or some weird behavior to troubleshoot, etc, better to start fresh there. I'll start a discussion with (hopefully) reproducible steps, screenshots, etc. I kind of feel like we've drifted from the OP's (and others') excellent original thread intent & contributions, and apologies for that.