How to maintain virtual copies easily

Status
Not open for further replies.
A

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.
 
Sort by date Sort by votes
Snapshots are extremely useful if you are training someone how to use Lr. I create snapshots at different phases of the development cycle and can easily with a single click go back to predefined points. This can be done in history, but is more tedious. With Snapshots you can give them meaningful names. I do not use Snapshots or Virtual Copies if I want to process an image for a specific project.
 
Upvote 0 Downvote
The trouble is, snapshots compete with VCs for very important functionality - first class citizens in Library, ability to be output, communicating with Bridge. I'd be completely in favour of bookmarking History steps or other ways (like dates) to navigate History.
 
Upvote 0 Downvote
Gnits said:
I ran into severe performance problems a few years ago after a Lr upgrade. I did exactly what you suggested \[use 'Import from Another Catalog'\]... It solved the performance issue (ie back to performance level prior to update) .
Click to expand...
clee01l said:
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...

Remember, reimporting is never the right first answer.
Click to expand...

I have been dealing with serious slowdowns with my Lightroom Catalog (literally, the catalog becomes 60x slower than it was before). I have been having conversations with Adobe staff, and I hope that they will figure this out. I thought I could solve this problem by exporting the catalog and starting over, and what I found was that (a) after exporting the catalog was quite "zippy" (like 60x times faster for some operations), and (b) after using the catalog for a few days it was back to the original catalog's performance.
There is some problem that a few of us run into, possibly due to Lightroom maintaining indices in the database, and it is only temporarily solved by exporting and starting a new catalog.
 
Upvote 0 Downvote
That sounds really frustrating Alan. I wonder if it could be preview related. What kind of things have you been doing during those few days of use?
 
Upvote 0 Downvote
I thought it was a common database problem in which the cost of maintaining an index increases the cost of each delete operation. But I got an email from an Adobe saying that the problem is deeper in the code.

John Beardsworth has suggested that Abobe chose a N-squared algorithm, and that might be part of the problem.
 
Upvote 0 Downvote
At least it sounds like they've been able to reproduce it in that case.
 
Upvote 0 Downvote
clee01l said:
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.
Click to expand...

I do wonder about the plethora of Lightroom plug-ins I have accumulated in the short time I have been using Lightroom. What two authors are on your trust list Clee01l?
 
Upvote 0 Downvote
Ad Astra said:
I do wonder about the plethora of Lightroom plug-ins I have accumulated in the short time I have been using Lightroom. What two authors are on your trust list Clee01l?
Click to expand...
John Beardsworth and Jeffrey Freidl. There are others of course, but these are the ones that I use with confidence. Jeffrey is having ISP problems at the moment so his body of work is not currently accessible.
 
Upvote 0 Downvote
I was going to say I hope I'm not one of them, Cletus! ;) At least, I'm very conscious of not being a trained programmer and don't trust myself 100%.

It's worth saying that Adobe keep plugins firmly under control. That's partly deliberate caution, partly by just giving plugin FRs a low priority. It's actually quite hard for a plugin to gummy up the database by accident.

John
 
Upvote 0 Downvote
Upvote 0 Downvote
Victoria Bampton said:
I'd also add John Ellis to that list. Between those 3, they pretty well have the essentials covered.
Click to expand...

I have looked at John's Any Filter but was put off by the fact that it must be adding lots of fields into the database for it to work. Sorry for going off topic. Data corruption is nearly always silent so backups are not going to help if something goes wrong with the database. I would feel a lot happier if Adobe added this capability into the underlying database rather than using a third-party plug-in.
 
Upvote 0 Downvote
johnbeardy said:
I was going to say I hope I'm not one of them, Cletus! ;) At least, I'm very conscious of not being a trained programmer and don't trust myself 100%.

It's worth saying that Adobe keep plugins firmly under control. That's partly deliberate caution, partly by just giving plugin FRs a low priority. It's actually quite hard for a plugin to gummy up the database by accident.

John
Click to expand...
plugin FR = ???
 
Upvote 0 Downvote
Status
Not open for further replies.
Back
Top