Lightroom: Performance and Cataloge size vs. Edit History management

  • 4
  • Idea
  • Updated 2 years ago
  • (Edited)
I recently had a discussion with Victoria Brampton on her Lightroom Performance blog topic.  Essentially, my LR catalog was disproportionally large (for the number of images therein) and the Open and Backup options and general LR performance were all sluggish.  It turns out that I had numerous images in several folders in which a great deal of editing was done with the Spot, Brush and Graduated Filter tools, along with long edit-history trails associated with each.  Victoria suggested that I locate those images and delete the associated histories.

Trouble is, LR has no tool or provision to for us to identify, locate or list the images with long Edit-history trails.  By way of the attached comments I posted on her blog (which follow, in quotes), I'm requesting that Adobe provision LR with that capability.

    " Since my original comment on 1/29/17 I have gone through some ‘housecleaning’ in LR, selecting (in Grid view) all images in some of my folders with large image counts and where I suspected many of those with long edit-history trails resided. Then I switched to Develop view, clicked on Develop>Clear History>Selected Photos. Amazingly, this action alone reduced the size of LR’s catalog from 2.7 GB to 834 KB, a reduction in size of about 69%!  Further, LR now is quicker to open, back up and has a generally snappier feel to it.

Besides pointing out what might be a good best-practice recommendation to not retain long edit histories on many images, it also leads me to an enhancement request for Adobe: providing a means of locating these images with long history trails so they can be managed, reviewed and deleted if necessary.

It strikes me that the feature would fit nicely if added as another of the ‘sort’ options in the Grid view."

~ Thanks, Frank P
Photo of Frank P

Frank P

  • 5 Posts
  • 3 Reply Likes

Posted 2 years ago

  • 4
Photo of Brian D. Tucker

Brian D. Tucker

  • 6 Posts
  • 0 Reply Likes
+1
Photo of Alex Furer

Alex Furer

  • 151 Posts
  • 37 Reply Likes
Absolutely +1
Photo of Dan Baumol

Dan Baumol

  • 11 Posts
  • 0 Reply Likes
great idea, I would use it
Photo of Peter Vogel

Peter Vogel

  • 63 Posts
  • 35 Reply Likes
Well, in my opinion that is a point where I would say, that Adobe didn't do their homework in programming in the first place!

I find it a bit ridiculous to request a sort and find feature to have users go through all their catalogues to delete edit histories in order to make the program faster and more responsive again. If this is the case, then there is a misconception in the architecture of the program to start with!

I am still waiting on fixes for:

- sluggish brush
- sluggish graduated filter
- sluggish to very delayed spotting brush
- unusable face recognition
- book module that was introduced and never progressed from there, it is still in elementary school level as far as I am concerned and I don't see that Adobe is doing anything anymore to make it a professional tool
- web module, same as books, it was introduced and has not really matured since then!

At the stage LR 6 is now, I personally don't need the slide show module, book module or map module and I certainly don't need the face recognition feature, because it just does not work, period!

If I had a fast browsing module, a developing module where the brushes are working in real time, a print module with enhanced options and a modern web module, that incorporates the fact, that most web content is consumed on a smart phone or tablet, then that would make me much happier than having all those half grown modules and an at times very sluggish program to begin with.
(Edited)
Photo of Cletus Lee

Cletus Lee

  • 88 Posts
  • 22 Reply Likes
I think this an excellent choice for improving LR performance.   The LR catalog could monitor develop history entries and when the count or size reaches a certain tipping point warn or make a recommendation to the user to delete parts of the Develop history.  Today, If I make crop adjustments I get a history entry for every time I stop dragging the crop window.  I am only interested in the final crop window position but may have 40 entries of crop adjustment  history steps before the final entry.   Ideally, I would like to select multiple develop edit history events that have no bearing upon the final adjustment OR are unimportant intermediate history steps. 
Photo of Anthony Stagge

Anthony Stagge

  • 42 Posts
  • 17 Reply Likes
Very interesting. I will attempt to clear mine up. Does deleting the history delete the actual edits on the image?
Photo of Beverly Parks

Beverly Parks

  • 56 Posts
  • 9 Reply Likes
I was about to post the same question. Will be watching for an answer.
Photo of Simon Chen

Simon Chen, Principal Computer Scientist

  • 1426 Posts
  • 438 Reply Likes
In develop, select the images that you want to purge the develop history, invoke Develop>Clear History... menu command. The command would keep your final/most recent adjustment settings, but purge the earlier intermediate history steps.
(Edited)
Photo of Anthony Stagge

Anthony Stagge

  • 42 Posts
  • 17 Reply Likes
Great, so I keep the image intact, but just lose the ability to go back to earlier steps. Seems amazing to me that clearing history would reduce the catalog file size so much. I always assumed the history is just series of text records that describe the edits. There must be more to it than that.
Thank you Simon.
Photo of Russell Cardwell

Russell Cardwell

  • 39 Posts
  • 17 Reply Likes
That is a great idea for feature that should have always existed. My LR is so slow it's painful to work with. I'm definitely going to do this as soon as I can. I have never had any use for edit histories once I finish with an image. It never even occurred to me that there are histories attached every one of those 120,000+ images. There should be an option to delete those when you close LR. Or at least an option in the same dialog box where it asks if you want to optimize the catalog.
Photo of Simon Chen

Simon Chen, Principal Computer Scientist

  • 1426 Posts
  • 438 Reply Likes
Each history step is indeed some text that describes the edit (equivalent to the XMP sidecar description). If you do a lot of adjustments (like brushing), that could add up. It is quite normal that history data takes up about 20~30% of the catalog size, depending on how much you develop.
(Edited)
Photo of Dwight DeLong

Dwight DeLong

  • 14 Posts
  • 1 Reply Like
Deleting the history steps leaves the photo with your changes intact. It simply removes the ability to undo each step.

BUT, you can develop>photo>reset to revert to your original photo after deleting the history. And you can undo the reset to bring your changed version back. But if you reset and then delete the history, you've lost your changes forever (without restoring from backup I mean).
Photo of Carlos Cardona

Carlos Cardona

  • 271 Posts
  • 50 Reply Likes
The correct path to "Reset" is actually: Library Module/Photo/Develop Settings/Reset.
Photo of Dwight DeLong

Dwight DeLong

  • 14 Posts
  • 1 Reply Like
sorry. I should have said develop>settings>reset all settings.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3603 Posts
  • 936 Reply Likes
As an experiment, I cleared the develop history in a catalog with 27,000 photos, reducing the size of the catalog by 58%.   Perhaps 1/3 of the photos were JPEGs with no develop history.   I couldn't see any noticeable difference in speed afterwards (speed was fine before).

Details:

1. I optimized the catalog, reducing its size from 1.27 GB to 1.26 GB.

2. In Library, I clicked on All Photographs, did Photo > Stacking > Expand All Stacks and Edit > Select All.

3. I entered Develop, did Develop > Clear History, chose Selected Photos.

4. LR didn't show any progress bar, so I watched its CPU usage in Activity Monitor until usage dropped back to 4% (took a minute or two).

5. The catalog size remained unchanged.

6. I optimized the catalog again, and it dropped to 528 MB.

That's about 20K bytes of develop history per photo, which doesn't sound unreasonable, considering that a large number of the photos have a lot of adjustment brush strokes.