Lightroom: Have full size previews automatically created for the develop module on import

  • 2
  • Question
  • Updated 4 years ago
  • (Edited)
It would speed my workflow (and perhaps lower my blood pressure) if the develop module had the same preview-building functionality as the library module. I'd like to start an import and have full size previews created for the develop module while I'm busy doing other tasks. Who doesn't have lots of room these days to cache full size previews for more than one module?
Photo of Michael Burke

Michael Burke

  • 105 Posts
  • 3 Reply Likes

Posted 4 years ago

  • 2
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2613 Posts
  • 333 Reply Likes
Are you talking about wanting a menu item in Develop: Library / Previews / Build 1:1 Previews and are upset about having to go to Library: Library / Previews / Build 1:1 Previews and then back to Develop, or are you talking about something else?

You can compute previews in the background as part of the Import and be in Develop while they're computing.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
He's probably talking about avoiding the N-second "loading" delay when switching from photo to photo in the develop module. i.e. the "negative" cache (used to be 4 images deep, now just the one most recent). Once upon a time it could be disabled using config.lua, but not enlargened or pre-populated, dunno about now..
Photo of AF

AF

  • 10 Posts
  • 0 Reply Likes
What he means is that the "Develop" module uses Camera Raw cache. So it loads the preview for a few seconds then builds it own kind of preview on the cache folder. This slows everything down. If there was a way to build these previews adhoc it would simplify things.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2613 Posts
  • 333 Reply Likes
And this "negative cache" is in memory or on disk?

LR 1 used to have previews that were uncompressed TIFs and this soon got out of hand, so they relaxed and made the previews JPGs. Develop needs to show exactly what the pixels are like, not JPGs compressed versions, so TIFs would need to be stored.

For a 20MP raw, the decoded data would be 20x2(bytes/color)x3(colors-per-pixel)=60MB TIF (or similar) per image, which would need to be stored somewhere for each image in the working set or at least guess which ones you're going to click on next, and compute those in the background, while at the same time not getting in the way of computing adjustments to the foreground image you're moving sliders on.

So the request is to be able to compute full-sized TIFs in the background for a folder of images and have those be loaded quickly while moving from one image to the next along the filmstrip?
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
Negative cache may no longer exist as such (I haven't kept up, e.g. by trying to disable it and see if behavior differs).

But it used to hold 4 images cached in ram. There was no way to pre-fill it - it kept the last 4 images developed.

Test using Lr3 (I'm not sure when it changed - such change was pointed out to me by Jim Wilde).

Once upon a time, this line in config.lua in Lr app-data folder (e.g. C:\Users\{user}\AppData\Roaming\Adobe\Lightroom) would disable the negative cache:

AgNegativeCache.enabled = false -- false kills the ram caching of recently visited images in dev module.
Photo of AF

AF

  • 10 Posts
  • 0 Reply Likes
Its on disk: "C:\Users\USERNAME\AppData\Local\Adobe\CameraRaw\Cache\" They are too small to be any kind RAW/TIF. They must be a jpg variant.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
To be clear: that's the camera raw cache (which is indeed on disk), NOT the negative cache (which is, or was anyway, in ram).
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
Alberto Freire wrote:
|> "then builds it own kind of preview on the cache folder".

Camera raw cache entry is created one time, then never changes. It's created as a "side effect" when you create 1:1 library previews, or when you first load for develop.

So, you can pre-build ACR cache entries just by building 1:1 library previews.

That said, it only helps a little bit, since Lr still has to initialize each image anew for developing.

+1 vote for a way to pre-initialize for faster develop loading.
Photo of AF

AF

  • 10 Posts
  • 0 Reply Likes
No, every-time you load an image on the Develop the date changes on those cache files. It recreates them. Its not a one time thing.
Photo of AF

AF

  • 10 Posts
  • 0 Reply Likes
I take that back... It doesn't seem to update.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
FWIW, the DNG fast-load data is essentially (if not exactly) the ACR cache entry embedded in DNG file upon "conversion".
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2613 Posts
  • 333 Reply Likes
My understanding is that the camera raw cache is demosaicked data from the raw file for LR to apply it’s adjustments to, so LR doesn’t have to go back to the raw and demosaick the data, again, every time focus is switched to it in Develop. It may be a step or two further than demosaicking, like bad pixels interpolated around, but in any case, ready for LR to apply adjustments to.

FYI, demosaciking is the conversion/interpolation/filtering of the one-color-per-pixel raw data to 3-colors-per-pixel RGB data. It’s possible that it’s the missing color data from the raw file so that the raw file also needs to be accessed to get the original pixels, but this is just a guess.
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 4135 Posts
  • 1473 Reply Likes
From my book: ACR Cache, or Camera Raw Cache, temporarily holds partially processed fast load data (1024px long edge, lossy DNG compressed) for the most recently accessed raw files, and is used in Develop to speed up loading times.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
|> "partially processed fast load data"

Sounds like it's about the same as a tiny smart preview..

Now that I'm thinking about it, I seem to remember somebody saying that if a normal smart preview is available, the cache entry will not even be used.

Thanks V.
~R.
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 4135 Posts
  • 1473 Reply Likes
The fast load data in a DNG and the smart preview are basically identical, and the ACR cache is a smaller version of the same type of data. Same amount of processing applied.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2613 Posts
  • 333 Reply Likes
So fast-load data would help show a reduced-size preview in Develop for the second before Develop renders the full-size image from the raw file + settings, with a few of those full-res RGB versions of the image cached in memory so arrowing back and forth doesn't take very long. It sounds like the fast-load data in the CR-cache doesn't help with how long it takes to render the full-res version with all settings applied but it does give a reasonable resolution Fit image to view if you're arrowing through things quickly and don't have to wait for the full-res image to render before moving to the next image.

Or does fast-load data actually help with the full-res image rendering, not just a distraction while the rendering is occurring?

I guess the OP is asking for full-res TIF-sized previews be computed in the background for the working set of photos and recomputed whenever a new adjustment is done to an image.
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 4135 Posts
  • 1473 Reply Likes
Yes, it basically just makes the sliders available quickly so you can start working while the full res loads in the background.