• Welcome to the Lightroom Queen Forums! We're a friendly bunch, so please feel free to register and join in the conversation. If you're not familiar with forums, you'll find step by step instructions on how to post your first thread under Help at the bottom of the page. You're also welcome to download our free Lightroom Quick Start eBooks and explore our other FAQ resources.
  • Dark mode now has a single preference for the whole site! It's a simple toggle switch in the bottom right-hand corner of any page. As it uses a cookie to store your preference, you may need to dismiss the cookie banner before you can see it. Any problems, please let us know!

How to maintain virtual copies easily

Status
Not open for further replies.

aster

Active Member
Joined
Jun 12, 2010
Messages
181
I have used for years virtual copies to experiment with setting and fine tune photos.
I wasn't aware that all these virtual copies are not stored in xmp files and I considered these permanent.

But appears when LR catalog corrupts in 2-3 years time to time and requires recreation these virtual copies vanish.
Often that actually is the best part of work what is lost and therefore I even didn't come to think that it might be so by LR design.

Any suggestions how to make virtual copies permanent or to change work flow?
Thanks.
 
Not sure what you mean by "appears when LR catalog corrupts in 2-3 years time to time", but catalogues don't just corrupt - it's very rare.

In Lightroom, xmp is not intended for backup - it's designed for data exchange with other programs - and so it omits a range of the work you do. Even if you could write VCs, you'd also lose stacks, assignment to collections, history steps, flags.

Your best backup is to routinely back up your catalogues. That covers 100% of your Lightroom work.

If you really want to back up VCs to xmp, there is a plugin called Snapshotter than copies VC information to snapshots, which are saved to xmp. So Develop settings will be included in the xmp - but not any Library info which might be different in the VCs.

John
 
Because any file can get damaged by other apps or the OS, you have a system backup of all of your critical user files. This includes the LR catalog file. Should something manage to corrupt your master catalog file, you have a backup to far back upon. You never need to recreate the master catalog file from scratch.
 
Thanks for your replies.

I don't use collection and some other similar functions. Just star ranking system as it seems to preserve database renewal.
Collections and etc suppose a longer life cycle of database then few years.

From your feedback I'm happy to learn that wise usage of LR can avoid data corruption problems.

My personal LR experience so far has been that renewal of database every 2-3 years is an essential practice.
Personally last flaw I have experienced is with images 1. which doesn't import second time from SD, after deleted accidentally.
LR search can't find by name and doesn't exist on HDD on any location.
Often workaround has been to change first HDD folder tree outside LR.
2. Images which can't be moved to other location for unknown reason and etc or folder name can't be renamed ...

But overall corruption result has been selectively not accessible images or minor data loss.
But it's easy to fix with database recreation in every 2-3 year.
Not speaking of LR version switch, when catalog import result is far from perfect.
Certainly among is also human factor, as always. :)

I haven' noticed any operating system performance degradations and I test hardware always when there is any suspicion.
I have been working for computer industry more then 25 years and so far I haven't seen a single software environment or database solution which doesn't have it's weakness based on less or more significant bugs.

It came out a reply I am not happy to post here.
 
Last edited:
Thanks for your replies.

I don't use collection and some other similar functions. Just star ranking system as it seems to preserve database renewal.
Collections and etc suppose a longer life cycle of database then few years.

From your feedback I'm happy to learn that wise usage of LR can avoid data corruption problems.

My personal LR experience so far has been that renewal of database every 2-3 years is an essential practice.

What do you mean by "database renewal?"

Phil
 
When during longer period there have appeared LR catalog anomalies, I have just deleted old and started over creating new fresh catalog.
That is I name renewal.

So far I considered that through xmp file also all previous image editing and ranking settings were maintained.
Now appears concerning virtual copies it is not true, which I considered essential part of LR.

Because I want to have original in comparison to edited image, I have discovered virtual copy for myself.
Which purpose appears to be somehow different in LR.

I considered xmp being cross platform format file "above" LR, being capable to preserve all important info about image previous editing.
 
If you want to ensure you have a hard copy of the virtual image, one option may be to export the virtual image as a DNG file and pick the option in the export page to keep in same folder and add to stack. You will then have the original, the virtual image and a DNG copy of the virtual image with all the edits all stored in the same folder in the same stack. If you lose the virtual copy due to unforseen problems, you will still have the DNG with all the edits made in the virtual image.
Of course this will increase disk storage and once exported and linked as a stack the virtual copy will be redundant as it is the same as the DNG copy and could be deleted if you wished.If you did this to all your virtual images, you will have preserved them from any database problems and your images would be safe

Steve V
 
If you want to ensure you have a hard copy of the virtual image, one option may be to export the virtual image as a DNG

That is a good idea. You can also export as"Original", which is what I do. Normally if I need two different treatments of the same image (maybe for different projects) and want to produce high quality fine art prints..... I will :
1. Export as Original
2. Develop in Lr as needed for the specific project
3. Round Trip to Ps for luminosity masks, toning, sharpening and resizing for my final image size.
4. Back to Lr to print and maybe generate web friendly jpgs.

Personally (ie my view) while the Virtual feature in Lr can be useful for all types of scenarios, I think it is flawed or incomplete because the Lr develop settings are only stored within the Catalog, are not in the xmp file and cannot travel with the image if I am sending to someone else (or want on my laptop without exporting / importing a Catalog).
 
Let me start by saying that I've never heard or read anything about the need for periodic 'database renewal' and I have certainly not found a need for it myself. However, if I ever felt it was needed for whatever reason, I think I would simply create a new catalog, and then use 'Import from Another Catalog' to import all my images from my existing catalog into the new one.
 
Let me start by saying that I've never heard or read anything about the need for periodic 'database renewal' and I have certainly not found a need for it myself. However, if I ever felt it was needed for whatever reason, I think I would simply create a new catalog, and then use 'Import from Another Catalog' to import all my images from my existing catalog into the new one.

I ran into severe performance problems a few years ago after a Lr upgrade. I did exactly what you suggested. I also discussed this with Victoria at the time. It solved the performance issue (ie back to performance level prior to update) and I also ended up with a much smaller catalog. I can only assume that there was crud in the catalog which got cleared and all the tables, indices, etc., got re-built from scratch.
 
I ran into severe performance problems a few years ago after a Lr upgrade. I did exactly what you suggested. I also discussed this with Victoria at the time. It solved the performance issue (ie back to performance level prior to update) and I also ended up with a much smaller catalog. I can only assume that there was crud in the catalog which got cleared and all the tables, indices, etc., got re-built from scratch.

I'm not saying that a database cannot become compromised somehow, I'm just saying that I've never heard about a kind of 'periodic maintenance' by renewing the catalog. Lightroom does have it's 'Optimize Catalog' feature, that runs if you let it make catalog backups. But if you ever need a renewed catalog, the 'Import from Another Catalog' option is much simpler (and preserves more) than using XMP.
 
Let me start by saying that I've never heard or read anything about the need for periodic 'database renewal' and I have certainly not found a need for it myself.
There is no need for "periodic database renewal" I am still working from a copy of my original catalog which has been continuous since 2009. I always have a recent backup near by. The worst situation that I got into required that I "Export as a Catalog" to get a clean database, but every edit adjustment, keyword and collection that I have ever chosen to maintain is still there. even on the first images imported in 2009.
 
Chaps, I don't think the OP means periodic database renewals in the sense that you are taking it, what I think he is trying to say is that he had to renew his catalog in the past due to anomalies, has lost his virtual copies because of this and additional he is questioning the XMP files and why they cannot help with his problem. To keep scolding him for stating periodic renewals does not appear to be very helpful.
 
he had to renew his catalog in the past due to anomalies, has lost his virtual copies because of this
Working from a backup of your master catalog or using a catalog created through "Export as a Catalog" does not cause the virtual copies to disappear. So no, this is not what the OP is talking about. The only way to preserve the integrity and continuity of the catalog is through frequent backups.
 
Chaps, I don't think the OP means periodic database renewals in the sense that you are taking it, what I think he is trying to say is that he had to renew his catalog in the past due to anomalies, has lost his virtual copies because of this and additional he is questioning the XMP files and why they cannot help with his problem. To keep scolding him for stating periodic renewals does not appear to be very helpful.

That's not how I read it (he wrote "it's easy to fix with database recreation in every 2-3 year"), but that's not important. Nobody is scolding him. In fact, he could be on to something and making regular backups of your catalog may not solve that problem. If your database deteriorates over time, your backups may have that same deterioration (it depends on how Lightroom creates a catalog backup: by creating a new database or by simply copying the existing one). So renewal may indeed be the only way to solve that, but XMP would not be the best method to preserve as much as possible.
 
I have been using LR 4-5 years.
I have run into catalog database performance degradation, limitations or just anomalies 3-4 times, when only creation of new fresh catalog have fixed the anomaly.
I guess perhaps I did some unexpected actions with folders or there was something unconventional with images or hardware properties.
I'm afraid even backups can't offer escape, if corruption reason is unknown.

Upon these figures I guess that everyone of here had considered as me, that it is wise to build new catalog with each hardware (PC) upgrade.
That is without knowing loss of virtual images.
My mistake, that I misinterpreted xmp capabilities or purpose of virtual copy. :)
 
I have been using LR 4-5 years.
I have run into catalog database performance degradation, limitations or just anomalies 3-4 times, when only creation of new fresh catalog have fixed the anomaly.
If you have third party plugins, these can be sloppily written and can gummy up a database should that be so. There are only two plugin authors that I trust to write good code. Still should that happen, the solution is still there to Export as a New Catalog and preserve your Virtual Copies. Virtual Copies only exist in the database that is the LR catalog file. In the 7 years that I have been a LR user, I have only needed to Export as a New Catalog one time. That one time was when Adobe released a very buggy version of LR6/LRCC2015. In spite of Adobe's claim that LR can not damage a catalog. I had to export my whole catalog to a new file. Presumably, this exports only the good bits and leaves the orphaned records and indexes behind. With the Export as a new Catalog I got every history step of every image and virtual copy. I had to rebuild my collections and publish services, but I still have all of my essential LR adjustments keywords etc.

Remember, reimporting is never the right first answer.
 
Upon these figures I guess that everyone of here had considered as me, that it is wise to build new catalog with each hardware (PC) upgrade.
That is without knowing loss of virtual images.

Not me. I've been using LR since version 1, and have changed/upgraded system several times, but I've never even considered building a new catalog. I view the catalog upgrade at each version change to be sufficient. The only thing I have done once or twice after an upgrade is delete the previews cache and build it from fresh (the upgrade process "steals" the previews cache from the previous version, so it's not rebuilt during the upgrade).
 
I've had the same experience as Jim. My catalogue is a direct descendant of the one I created in LR 1.0, and I've never encountered any corruption.
 
Upon these figures I guess that everyone of here had considered as me, that it is wise to build new catalog with each hardware (PC) upgrade.
That is without knowing loss of virtual images.
My mistake, that I misinterpreted xmp capabilities or purpose of virtual copy. :)

I have felt strongly for years that the xmp files should hold the develop details for all virtual images.
 
I have felt strongly for years that the xmp files should hold the develop details for all virtual images.
Yeah. I think PSDs can store all history and snapshots; be nice if you could export XMP for any state in Lr, whether for a snapshot or a virtual copy. Would make it easier to just pass around the parameters, not the file. Even for DNGs or JPGs. That's basically what Mylio does to synch, and it works great.
 
I've never been convinced we need two separate entities.
I do not have much use for Snapshots I can walk backward in history to reach any place where I might have made a snapshot. Export and Publish Records are also inserted in the Develop history effectively acting as a snapshot. A Virtual Copy OTOH represent a fork in the development history with one copy taking a different future develop path from the other
 
After "successful" develop phase image may obtain totally new value and outlook.
It's a main purpose of LR develop module.

A year later I still occasionally want to see side by side original and developed virtual copy to recall the way I have already passed and what to expect from other shots of same session.
I have tried history reverse but couldn't find this method very comfortable and flexible enough compared to virtual copy explore before and after images.

And it's very encouraging to read that database since LR version 1 can still be alive.
Thanks.
 
I do not have much use for Snapshots I can walk backward in history to reach any place where I might have made a snapshot. Export and Publish Records are also inserted in the Develop history effectively acting as a snapshot. A Virtual Copy OTOH represent a fork in the development history with one copy taking a different future develop path from the other

I don't have much use for snapshots either - and I'd have even less need if history steps were dated. Snapshots were originally in ACR/Bridge, hence they save to xmp, but I have always been unconvinced by their existence alongside VCs. This means we have two competing ways of creating versions of a photo, each lacking important properties that are available in the other. Other similar applications haven't needed this duplication - Aperture had versions, C1 has variants. That's how Lightroom should have been.
 
Status
Not open for further replies.
Back
Top