The Adobe Lightroom Classic product is in a genre of products known as “Digital Asset Management”. The Asset in this case is the image and all data about the image and the management part are the actions we can do to an image. Every digital image that exists has some similar characteristics that are found in the EXIF (Exchangeable Image File Format) which I would encourage any reader to learn more about here.
When the original Lightroom was released in 2007, Adobe decided to use the SQLite database product to contain all EXIF information about an image. A key difference between the Digital Asset Management class of software and an editor is the ability to associate or group images with each other which became known as Collections. Instead of duplicating files into directories and having to search through those it was faster to present groups of images as thumbnails and to use a database rather the trying to navigate disk drives and generating previews on the fly.
The SQLite database was meant to contain data, not images so Adobe needed another way to be able to display the file previews quickly and made the decision to generate multiple previews of different sizes when the images are imported into the SQLite database and store these previews in directories near the SQLite database.
The Testing LrC Catalog
To get observable information for these articles, I created a new catalog that I called [PT] (for Preview Test). A new catalog tells LrC to create 3 folders and populate them with the initial files with the fourth file being part of the actual database.
[PT] Helper.lrdata – File folder
[PT] Previews.lrdata – File folder
[PT].lrcat-data — File folder
[PT].lrcat – Adobe Lightroom Classic catalog/SQLite database
This series of articles is centered around the previews so that is where I will be concentrating on, I want to learn more about how LrC manages them. When we import images into the catalog, we are asked what type of preview we want to build in the import process. Minimal, Embedded & Sidecar, Standard, or 1:1. These are stored in the appropriately labeled “Previews” folder.
Importing the single image into the catalog starts the preview creation process. LrC generates 5 preview files in different sizes. The file names are about 70 characters with the numbers after the right most underscore representing the “longest side” pixel count. The files have no extensions, but they are of the JPEG file type. This is an example of the filename
2E275321-6C7C-4FA9-BFF4-7259D20A184A-5b7dd70c0e0fae922af802e25692da37_1599
Adding a .jpg to the end tells the Operating system to use its built-in preview generator to display the contents of the image.
The Testing Setup
This was relatively easy to set up, and I encourage anyone to try it themselves.
- Create a new LrC Catalog. Then Exit the application
- Copy the entire catalog directory to a backup location and label it backup.
- Open your Finder or File Explorer to the previews directory of the catalog
- Start LrC, building Minimal previews. Allow the background processes some time to build the Preview files. You can monitor the progress through your finder or file explorer to see the directories being added dynamically.
- Once the Preview directories are built, exit LrC.
- Using your Finder or File Explorer app you can copy the preview files to other directories. The ones with VERY long names need to be renamed with a .JPG extension to get the EXIF details of them.
- You can delete your catalog directory and copy the blank backup to start from a known initial condition.
- Repeat Step 4 building different size previews and you can observe the files created by LrC.
- Include the creation of Smart Previews.
For this test, I’m using a single JPEG file. I found that using a single file makes the discovery process extremely simple as there is only 1 possible file that is being represented in all combinations of previews.
Disk Space Consumption
I created this table to document my observations. This shows that based on the Minimal and the 1:1 preview type the size of the preview file and the amount of disk storage it takes.
This is the table as you created it. I hoped it would format well, but not so much. In WordPress, tables can be a real pain. You don’t get a lot of control over column width. Because there were more columns than rows, the columns became really skinny which caused a lot of the number and words to split very awkwardly. So I flipped the rows into columns and the columns into rows. The second table looks a lot cleaner.
| All values in BYTES | Minimal Image Size | Minimal Previews File size | Minimal Previews Size on Disk | Number of Sectors @4K per Sector) | 1:1 Preview Size | File Size 1:1 | Preview 1:1 Size on Disk | Smart Preview 2560 X 1707 | Smart Preview Size on Disk |
| Preview Size 1 | 320 x 213 | 16,704 | 20,480 | 5 | 320 x 213 | 14,241 | 16,384 | ||
| Preview Size 2 | 799 x 532 | 63,295 | 65,536 | 16 | 320 x 213 | 63,543 | 65,536 | ||
| Preview Size 3 | 1599 x 1066 | 210,001 | 212,992 | 52 | 1728 x 1152 | 243,938 | 245,760 | ||
| Preview Size 4 | 3199 x 2132 | 644,371 | 647,168 | 158 | 3456 x 2304 | 833,317 | 835,584 | ||
| Totals | 934,371 | 946,176 | 1,155,039 | 1,163,264 | 568,138 | 569,344 | |||
| Unused Space | 11,805 | 8,225 | 1,206 |
| All values in BYTES | Preview Size 1 | Preview Size 2 | Preview Size 3 | Preview Size 4 | Totals | Unused Space |
| Minimal Image Size | 320 x 213 | 799 x 532 | 1599 x 1066 | 3199 x 2132 | ||
| Minimal Previews File size | 16,704 | 63,295 | 210,001 | 644,371 | 934,371 | 11,805 |
| Minimal Previews Size on Disk | 20,480 | 65,536 | 212,992 | 647,168 | 946,176 | |
| Number of Sectors @4K per Sector) | 5 | 16 | 52 | 158 | ||
| 1:1 Preview Size | 320 x 213 | 320 x 213 | 1728 x 1152 | 3456 x 2304 | ||
| File Size 1:1 | 14,241 | 63,543 | 243,938 | 833,317 | 1,155,039 | 8,225 |
| Preview 1:1 Size on Disk | 16,384 | 63,543 | 245,760 | 835,584 | 1,163,264 | |
| Smart Preview 2560 x 1707 | 16,384 | 568,138 | 1,206 | |||
| Smart Preview Size on Disk | 569,344 |
Often in exploring the disk operations we see a “Size” and a “Size on disk’ label. This is because computers store information on a disk in 4K or (4096 bytes) spaces for efficiency. If an image is less than or equal to 4096 bytes in length, then it takes 1 cluster but if the image is 4097 bytes, it will take up 2 clusters with the majority of the second cluster containing zero values.
In this example, approximately (11905/946176) × 100 ≈ 1.258% of disk space is taken up by the file system to pad the byte count to the cluster size per image. Doing some rough estimation if there are 50,000 images in a catalog we will end up with around 200,000 preview images. Each set of 4 or 5 images will take close to 1 MB which means that a preview directory will be approximately 50 GB in size and about 1.258% of that will be slack space that the OS uses to fill out to the sector size. This is just the previews and doesn’t count the actual source image sizes.
Smart Previews are based on the compressed JPEG image that the preview generates. This article provides a good description of this: What Are Smart Previews in Lightroom Classic and When Should You Use Them?. This means that the DNG file that the Smart Preview has is a lossy compression format. While it does retain more bit depth than a JPEG, it does support almost all Develop adjustments. It isn’t necessary to generate if you have access to your standard previews and images. There are certain use cases where Smart Previews make a lot of sense but this is narrow.
As all the preview files are dynamic and constantly changing. This is why it’s recommended to keep them on the fastest speed disk that you have on your computer.
(Since they are in the same directory as the catalog, it really means that you want the directory the data catalog is on to be on the fastest drive on your system)
Lightroom Classic previews are dynamic and background processes regenerate previews on the fly. LrC uses these previews to quickly display an image. When LrC does its catalog backup process it only keeps what’s necessary to recover your work in Lightroom. The Backup process does NOT backup your images because that’s your responsibility. The LrC backup process does NOT backup the Previews, because they aren’t necessary.
What I Learned
The important take away here is that for every image that is imported into Lightroom Classic there are at least 4 smaller JPEG images generated and stored. This is the image that displays in the Develop module along with the history of all the adjustments performed on that image. The original image is NEVER altered. [Simultaneously completely true and totally false. The image itself is never altered, but the EXIF/IPTC data in the image file can and will be changed in JPG, TIFF and some other files. This data includes the copyright & photographer information, keywords, if you told LR to keep them for JPG files and some of the other data.] The previews are dynamic and can be regenerated by background processes that do not show any indication that they are running so stopping the Adobe Lightroom task through the Operating system may have very bad consequences to the SQLite database. [probably not. My guess is they generate the preview followed immediately by an update to the catalog. Even if you kill it, the worst that will happen is that if it doesn’t find the preview file it in the catalog the next time around, and it will just rebuild the preview & update the catalog]
You want to put your catalog on the fastest disk you have available on your system and you may want to run the Optimize Catalog at least once per week. If you wanted to reduce your backup size you could omit all the directories labeled previews as if you truly need to restore your catalog from a backup, they can be regenerated. There is a lot in this article. The next article will be about scenarios, workflows and recommendations.
Return to the Article index page
0005
Recent Posts
Recent Comments
No comments to show.