Lightroom catalog optimization a little bit different
The are a couple approaches to optimize the Lightroom catalog trying to increase the speed of Lightroom.
Base situation
The suggestions go from storing the catalog and the preview images on a [post id=81]SSD[/post] to [post id=401]splitting[/post] the catalog in serveral parts, like for every shooting or every year.
No matter what suggestion is right for your workflow Lightroom is first of all a database, based on SQLite storing every keyword, all your GPS-metadata, virtual copies and every single step of your image processingand much more.
Background
Already in the article about [post id=315]virtual copies and snapshots[/post] in Lightroom we took a look on the development protocol.
Lightroom stores every change on the image, for example if i exported the image or increase saturation by a value of 10. But even if i decide that the increase in saturation of 10 was too much for the image, decreasing this value will generate an additional entry in the database.
Since Lightroom is a non-destructive raw converter the advantages are obvious. This enables the user to go back to every wanted step of image processing.
In my opinion a more easier way is to use virtual copies if you intend to make severe changes to your image. In my workflow i’ll use virtual copies basically for every monochrome version of the image or if i want to experiment with high contrasts or something like this.
Looking at the database und getting informations how the data is stored i’m not surprised at all about the tremendous need for space on the harddrive or SSD. Lightroom stores the information in the original XML format you know from the [post id=73]XMP[/post] side-car files, without working with reference ID for repetitive entries like my name as a copyright holder of the image. and link them via this ID to another table in the database.
But maybe this space eating structure makes it easier for the programmers to store all the different presets, collections and other preferences within the database. And today a couple 100 MB diskspace don’t cost much even on a SSD.
Action
But this for a database unusual structure is the key to considerable reduce the size of the catalog file . My main catalog contains some 20.000 images and its size is 813.690.880 bytes. Deleteing all protocoll entries reduces the size to 507.157.888 bytes and this is quite a difference. To do this just mark all images (if you’re working with stacks a lot remember to show all stack images) and go to the development module. There you pick Development -> Delete protocol and delete all entries. There is no tool or something to selectivly delete the entries but before you try this out make sure you have a working backup of your catalog.
Conclusion
This option reduces the size of the catalog tremendously and virtual copies are not influenced (of course their development steps are deleted too), but i have doubts if Lightroom gains speed. Keep in mind if your working with snapshots instead of virtual copies that they are deleted too 😉
What do think about deleting the development protocol? Is it worth it? Just leave me your comments and questions are welcome too.
ciao tuxoche
Related Posts
About The Author
