Is there any PRACTICAL way to speed up making 1:1 previews?

[DavePinMinn]

Dell 7740 Precision, i9-9880 CPU, 32gb, Quadro 3000 RTX, ALL M.2 SSDs, Windows 11 Pro

Lightroom 12.2.1 (I'm in East Overshoe FL, and don't have the bandwidth to do yet ANOTHER Creative Cloud update 'til I get to better access - but it's always been a pig and I don't think 12.2.2 is going to fix that)

Catalog is on an M.2 SSD separate from O/S and separate from images.

Cache is set to 25 GB, all temp are on M.2 SSD.

Performance preference SAYS it'll use full graphics acceleration.  I've tried it OFF, using graphics ONLY for processing, and full with graphics for export.

Nothing huge (Photoshop) is running, so there's PLENTY of spare memory.

Makes NO difference.  This thing is a pig at making 1:1 previews - and these at NOT gigantic images - Alpha 1, BUT in crop mode, shooting compressed RAW, so these are 20 megapixel images around 5600x3700px.  So, they'e about the size of a generations-old Nikon D500.

I'm in the process of having it generate about 2400 1:1 previews for review, and it's been going over TWO HOURS, and it's at about 2100 of the 2400.

It's always like this.  It's adequate for most other Lightroom/Photoshop stuff as long as it doesn't run out of memory, but making 1:1 previews - BLECH!

Ideas? (reasonable ones)

Is there ANYTHING REALISTIC (which means NOT replacing the laptop) I can do to configure Lightroom or the laptop differently

[dj_paige]

When you import compressed RAW images, LrC has to first de-compress the image, and then generate the preview. You could try an experiment with uncompressed RAW and see if those can be imported noticeably faster than compressed RAW images.

[Conrad C]

One reason those adjustments weren’t helping is that Lightroom Classic currently does not do much with the GPU when building previews. Preview rendering is still largely CPU-based.

It seems like what will eventually cure this might be some future update. Because Lightroom Classic has gradually been introducing the GPU into more operations. A few years ago they GPU-accelerated many Develop operations. More recently, they enabled GPU acceleration for exporting. Batch exporting JPEGs is similar to preview building, so what a lot of us are hoping is that GPU-accelerated preview rendering is getting closer. But it is not here yet, and we don’t really know what Adobe is working on next. So for now, the bottlenecks for preview rendering are not storage speed or the GPU. The bottlenecks are the clock speed of the CPU, the number of CPU cores it can throw at the images, and how effective the cooling is to allow the CPU to run at full speed without thermal throttling.

The way I understand the role of storage is (very very rough example here) that it only needs to be fast enough to read the number of images that the CPU can process at one time. So in theory, if a 12-core CPU is ready to load 12 images for preview generation (if we don’t think about system and application CPU overhead), and those 12 images are 30 megabytes each, then there is no need for storage to be faster than 360MB a second in this case. If each core was able to process say two images per core per second, then maybe 720MB/sec storage would be needed.

[DdeGannes]

Creating 1:1 previews is not a copy paste function, LrC has to render the original image and apply all edits you did in LrC then save them to the folder where the Previews are kept.

The timing of that function will be restricted to by the weakest link, RAM, GPU, Disk location ( Internal / External) capacity and free disk space, Connection.

I calculate 1.7 sec per image, if there are raw images involved that speed is quite normal and quick.

[dj_paige]

The timing of that function will be restricted to by the weakest link, RAM, GPU, Disk location ( Internal / External) capacity and free disk space, Connection.

And CPU, which is the part of the computer's hardware that is used the most in creating previews, I'm going to say over 80% of the time to create previews is because of the CPU. I don't think GPU is used to create previews, and I don't think a fast hard disk makes anything other than a slight difference.

[Per Berntsen]

FWIW, I've never had the need to build 1:1 Library previews.

I view almost every image at 100%, but use the Develop module, which renders the image instantly.

Don't know if this will suit your workflow, but it might be something to consider.

I'm guessing that at least part of the reason for it being so fast, is that the GPU is involved.

---

@DavePinMinn wrote:

Cache is set to 25 GB, all temp are on M.2 SSD.

---

This is the Camera Raw Cache, which contains the Develop previews.

There is, as far as I know, no limitation on the size of the Previews.lrdata file, which contains the Library previews.

[Conrad C]

That is how I work too. However, on my laptop the Develop module displays in less than one second only if the image is already in the Camera Raw cache. If it isn’t, it takes 1 to 3 seconds to render it into the cache. Which is fine for my needs.

It was not made clear in the initial post why the 1:1 previews are needed. The usual use case is needing to compare focus from image to image at 1:1 or higher magnification with zero lag. I can’t think of another reason to render 1:1 previous straight out of camera, although there might be one. If another reason is simply to get the fastest possible image-to-image viewing times in Library straight out of camera (before editing), then I get that by selecting Embedded and Sidecar previews in the Import dialog box. Then Lightroom Classic will just grab the previews that are already in the images.

For those who don’t know, embedded and sidecar previews represent how the camera rendered the image, but not how the Lightroom Classic engine will render the images. If I haven’t edited the images yet, that isn’t important. If I start editing an image, its 1:1 preview will be updated by Lightroom Classic anyway, to represent current edits. So I can’t justify the time and storage space needed to generate 1:1 previews in advance when they will already be replaced as soon as I start editing.

Given all that, it would help to understand why it is thought that generating 1:1 previews in advance is even needed, in case the reason is better fulfilled another way.

[DavePinMinn]

Thanks for the replies...

This isn't at import.  Importing is done with Standard previews unless I have hours for the import to complete while it makes 1:1 previews.

There's a significant difference, I think, between having an image display, and having an image display at 100%.  Even on the laptop, I can walk through loupe view in "fit" with subsecond delay. The "standard" preview is more than adequate.

BUT, the reason for having the 100% previews is because with that I can check critical sharpness of an eye or whatever is the critical area of the image, at 100%, with the same subsecond lag - essentially I can move as fast as I can see if it's sharp, press the "X" to reject or right arrow to move on.  Without the previews, the 100% view in the library is slow - in the multiple seconds per image as sit sits there doing "Loading".  I'd guess minimum 2 seconds, though it seems like an hour when you're going through a lot of images.  And this is with SMALL images - 20 megapixel.

As for Develop, it's SLIGHTLY faster to render 100% images, but it's perceptibly slow moving from image to image.  It's a lot slower than the library for going through images at 100% WITH previews.

NORMALLY, I try to have it build the previews for a day's shooting while I'm doing something else, but this morning I did it while sitting here waiting, and I was again reminded just how SLOW it is. 

One of the earlier replies spoke of about 1.7 sed per 1:1 preview.  I think on this box I'm somewhat slower than that - for 2400 images 1.7 seconds would be about 68 minutes, and I was over 2 hours.  BUT, I also had the "write XMP automatically" on 'til I remembered and paused it while the 1:1 previews were building.

BUT, in the end, since I've got enough memory, very fast storage for everything, a huge amount of cache, a huge amount of temp space, and so on, and the CPU is running 90-100% busy when doing the previews, it sounds like this is about as fast as this box is going to go without a CPU transplant.

Thanks for the answers, but in this case it sounds like I'd need to do something drastic to significantly speed up building 1:1 previews.

[Per Berntsen]

I use Compare view as well, and quite a lot, since I use focus stacking for most of my work.

It is somewhat annoying to wait for the 1:1 previews to generate, but I can live with it.

I sometimes use FastRawViewer to check focus, and to eliminate shots at the beginning and end of the stack that aren't sharp anywhere.

[DavePinMinn]

When I'm not in Florida photographing birds and things, I too do a fair amount of focus stacking.  Usually between 15 and 20% of everything I shoot is focus stacks. 

And it's not AS WRETCHED at home where the system is a 12900 CPU and 64GB of memory so they build SOMEWHAT faster, but it will be a lot worse with the Alpha 1 when I'm shooting full-sized RAW and focus stacking them.  The time to build 1:1 previews is just SLOW no matter what system I'm using.

Unfortunately, I've tried to do critical sharpness checking without 1:1 previews.  Whether eyes of a bird, or the focus point of a focus stack image, without the 1:1 previews, its inadequate.  I"ll just have to remember to have the system build in off-hours - which if I wasn't a nitwit, I could do OVERNIGHT when the system is idling...

[johnrellis]

Have you enabled Preferences > Performance > Generate Previews In Parallel?

[DavePinMinn]

Yes, I just checked to be sure, and that's turned on...

I think the BEST idea is to remember to have it build preview when I head for bed, though that can become a problem 'cause I've only got about 100GB of free space on the catalog partition, and I ran it out of space one time building 1:1 previews for several folders... 

Overall, unfortunately, it sounds like the laptop is doing about as well as it's going to.