Previews not updating when a RAW image is replaced

  • 1
  • Problem
  • Updated 5 months ago
I'm having an issue with previews not updating when a RAW image is replaced by an image with the same name. Firstly, in Preferences/Performance I have the Use Smart Previews ... option turned off.

These are the steps I have taken (using Windows 10 and Lr Classic 8.2.1):

Take a photo in RAW on my Nikon D750 and copy it to a folder on my computer.

In Library, right click the Folder where my new photo is located and select Synchronize Folder...

Import the image with Build Previews set to Standard.

Create a virtual copy of the new image, switch to Develop and make some adjustments on the virtual copy.

Switch back to the Library. Leave Lr running.

On my camera, delete the new image and reset the numbering so that the next image I take is assigned the same number and therefore filename. I then take another photo, copy it to my computer using the File Explorer, replacing the first RAW image with this new one.

Go back to Lr. Both thumbnails are updated to the new image.

With the virtual copy selected, switch to Develop. The image preview shows the new image briefly, then loads the first image! The original RAW and virtual copy thumbs in the film strip are now different.

Switch back to Library. The virtual copy momentarily shows the old preview, then refreshes so that the thumbnails are now the same again on the grid and in the film strip.

Switching back and forth between Library and Develop with the virtual copy selected, switches the preview between the new and old image. The Develop preview doesn't seem to refresh.

If I close Lr, then start it, switch to Develop with the virtual copy selected, the correct new preview image is shown.

This behaviour changes if on the original import, Build Previews is set to Embedded & Sidecar. In this scenario, the original image preview gets stuck on the old preview when the first image is replaced by the second, so in the Library the two thumbnails are different, while in Develop, they are the same, but both the old previews. However, this time restarting Lr does not make the previews correct - the original remains stuck on the old preview.



Photo of Anthony Blackett

Anthony Blackett

  • 180 Posts
  • 54 Reply Likes

Posted 5 months ago

  • 1
Photo of Robert Somrak

Robert Somrak, Champion

  • 406 Posts
  • 138 Reply Likes
Lr is probably using the Develop RAW cache and is not updating the photo.  I can't imagine where the scenario you describe would (or even should)  be a considered a standard workflow that the programmers would design for.  
Photo of Todd Shaner

Todd Shaner, Champion

  • 1567 Posts
  • 528 Reply Likes
I could not duplicate the issue following your procedure, but I removed the raw file and simply renamed  a copy of different file in the same folder to the original raw file's name. If you use that procedure do you still see the issue? I'm also on Windows 10 with LR 8.2.1.

In any normal workflow you would never encounter this scenario. As Robert Somrak said why do you need this capability and how did you discover it? This may help to uncover something else you're doing to trigger the issue. Thank you.


Photo of Anthony Blackett

Anthony Blackett

  • 180 Posts
  • 54 Reply Likes
Robert and Todd, I agree that my procedure is out of the ordinary, but not everyone does what the programmers expect them to do. One of the problems with software development is trying to predict and cover every possibility that a user might try.

I actually do this occasionally - take a shot, copy to the computer and import into LR, decide I'm not happy with it, delete from the camera and reset my camera numbering, In this casethen take a second shot and copy it over the original on my computer.

Of course, I can simply remove the first import and re-import the new image and everything will be fine. What my procedure has shown to me is that LR isn't always reliably updating previews and there isn't a simply way to initiate a preview rebuild for a selected image.

Todd, deleting (or renaming) the originally imported file (using the OS) and then renaming another file in the folder to the same name as the original doesn't do the same as replacing the original file with a new one shot from the camera when imported with Build Previews set to Standard. Your test by renaming the file seems to rebuild the previews as expected.

However, if I initially import with the Build Previews option set to Embedded & Sidecar, then using the renaming method doesn't update the original preview in the Library. The virtul copy will update, but only if an adjustment is made to it in Develop. In this case, restarting Lr doesn't fix it either.

Here's a snap shot of the Library grid - the original on the left shows the original preview while the virtual copy shows the adjusted new image preview.



Photo of Todd Shaner

Todd Shaner, Champion

  • 1567 Posts
  • 528 Reply Likes
I was able to duplicate the issue by following the first part of your procedure, then in a different folder create a file copy, rename it to the original filename, paste it into the original folder using File Explorer, and choose to overwrite the file in the destination folder.

It appears the camera raw cache isn't being updated as Robert mentioned. What I discovered is that switching to the Develop module, selecting a different image file that was not overwritten, and then back to the virtual copy updated the camera raw cache with the the same image as the overwritten raw file. I've seen similar  "transitional" editing issues like this that can cause both the Library module or Develop module previews to get out of sync. In all these cases simply selecting another image file and then back to the erring file or updating the Library preview corrects the issue. Please let us know if following the above procedure also corrects the virtual copies on your system.
(Edited)
Photo of Robert Somrak

Robert Somrak, Champion

  • 406 Posts
  • 138 Reply Likes
I don't think this should be considered an issue in Lightroom.  This is similar to moving a file using the OS outside of Lightroom and Lightroom not knowing where it is.  In this case you did not import the file but replaced an already imported file using the OS outside of Lightroom. Lightroom should not need to account for this as the standard workflow should be remove the file from Lightroom and then import the new one.
Photo of john beardsworth

john beardsworth

  • 1230 Posts
  • 319 Reply Likes
I agree. I'd suggest abandoning this practice, even if one could probably force LR to rebuild the previews by making adjustments or using the menu commands to delete and rebuild previews.
Photo of Anthony Blackett

Anthony Blackett

  • 180 Posts
  • 54 Reply Likes
Looks like I'll just have to remove the original image and reimport the new one. Thanks to those who replied.
Photo of Todd Shaner

Todd Shaner, Champion

  • 1561 Posts
  • 524 Reply Likes
Anthony, if you could give us a detailed description as to WHY you're using this workflow method and WHAT benefits you feel it provides we can probably suggest alternatives that won't have this issue. The devil is in the details!
Photo of Anthony Blackett

Anthony Blackett

  • 180 Posts
  • 54 Reply Likes
Hi Todd,

I think I can live without doing this 'out of the ordinary' workflow and just remove from Lr, then reimport.

I was really just trying to shortcut reimporting and if I had a virtual copy with adjustments that I wanted to keep, I thought Lr might be smart enough to update the previews. Obviously not, but it dosn't really matter.

Thanks again for your help and advice.