Lightroom: standard previews won't be rebuilt, even after changing standard preview settings.

  • 2
  • Problem
  • Updated 5 years ago
If one changes standard preview settings, then invokes the "Build Standard Previews" function, standard previews should be re-built with the new settings.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes

Posted 5 years ago

  • 2
Photo of Robert Frost

Robert Frost

  • 396 Posts
  • 53 Reply Likes
Hi Rob,

Yes I noticed that a while ago. Win8x64

Bob Frost
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Perhaps not a "bug" per-se, but yeah... - just an option "force rebuilding" (instead of always "intelligent rebuilding") would do it.
Photo of Robert Frost

Robert Frost

  • 396 Posts
  • 53 Reply Likes
Hi Rob,

Do they need to be rebuilt if one has 1:1s built? Does building 1:1s include all intermediate previews? Don't know.

Bob Frost
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Building 1:1 previews will (always, I think) re-build standard previews too, even if they would not be built by the 'Build Standard Previews' function. So, if the "discard 1:1's" feature were not broken in Lr5, it would be a way to recreate standard previews with the new settings (i.e. discard and rebuild 1:1's). - good idea Bob ;-).

PS - I tested the hypothesis by using Lr4, and am extrapolating to Lr5. Here is what I did:

1. Created a 1 photo catalog.
2. Built 1:1 previews with large standard previews.
3. Checked steady-state preview folder size (you have to wait a while for Lr to consolidate files and database entries...).
4. Discarded 1:1 previews, changed standard settings to small, and rebuilt 1:1 previews.
5. Again, after waiting for steady-state to be reached, the folder size of previews was notably smaller.

R
Photo of Robert Frost

Robert Frost

  • 396 Posts
  • 53 Reply Likes
It would be a good idea if building 1:1 previews didn't take forever! I wish they could speed it up by using more cpu power, as they seem to have done with smart previews.

Bob frost
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Is only one cpu going, or are all going but not at 100%?

In my case (for regular previews), all (4) cpus are going, but are only utilized at 100% for part of the time, so total average cpu activity is like 2/3 (67%) - about like an export... - i.e. 3-6 seconds per photo for 12MP raws (D300), depending on editing.

Granted cpu utilization for smart previews is closer to 95%, and take about 2/3 of a second, so yeah - a lot faster. Still, *way* more needs to be done to render regular (baked) previews than to create smart (unbaked) previews.

PS - I have no idea whatsoever why Lr can't render regular previews using 95% cpu too, but even so that would make it 2-4 seconds instead, but not .7 seconds like smarts.

win7/64 AMD Phenom II X4 965

Is your performance about like mine, or is it worse? (better?).

Cheers,
Rob
Photo of Robert Frost

Robert Frost

  • 396 Posts
  • 53 Reply Likes
All 12 are going (6x2), but the average use is only about 20% and it takes about 5 secs to render a D800 nef. With the smart previews, all 12 hit max for quite long periods; I haven't seen my cpu get so hot!

Bob frost
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Sounds normal. There is obviously something going on that prevents max cpu utilization but I dunno what the bottleneck is. I've heard claim that it's on purpose, so Lr UI operates smoothly whilst rendering, but I never bought that for a second.

It took a long time for the resolution war to reach DSLRs, but I bet a lot of folks (e.g. Lr users) long for the good ol' days when DSLR manufacturers were striving for fewer but better pixels ;-}.

I think, unless you are shooting with a very sharp lens, with flawless technique, and at low ISO, a lot of those hi-rez pixels are wasted.

But conversely, if you are shooting with a very sharp lens, flawless technique, and low ISO, a lower rez camera may not be taking full advantage of your lens sharpness.

R
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Maybe worth noting: Much of Lr (can be roughly thought of as the VC part of MVC, if that means anything to ya), is written in Lua, and taps into dev code of ACR, written originally for Ps, for rendering. The integration is looser than optimal for Lr. Not sure what that means exactly, except it's different than most raw softwares where all pieces were written together... But when rendering smart previews, ACR is not in the loop.
Photo of Robert Frost

Robert Frost

  • 396 Posts
  • 53 Reply Likes
Rob Cole 7 hours ago

>I think, unless you are shooting with a very sharp lens, with flawless technique, and at low ISO, a lot of those hi-rez pixels are wasted.

Having a D800 with 36 MP means that I can throw away 2/3rds of an image by cropping down, and still have 12 MP left for a decent A3 print. Far cheaper than buying a 600 mm lens!

Bob frost
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Point taken.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Summary:
========
Although it seems standard previews should be re-built if standard preview building is invoked manually, after standard preview settings have changed, just fixing the "discard 1:1 previews" feature would provide an adequate work-around, i.e. to rebuild standard previews:

* discard 1:1 previews (feature currently broken in Lr5.2RC).
* build 1:1 previews (which will get standard previews again too).
* optional: discard 1:1 previews again.

UPDATE:
-----------
Work-around for the mean time:

PreviewExporter @v4.9 has a new feature "Discard Previews".
-----------

Rob