# Why thumbnail rendering only happens the thumbnails are on the screen?



## Lunatique (Jul 29, 2015)

One issue with Lightroom that's bothered me for a long time, but I couldn't find any answers on the web for, is the way the thumbnails are rendered. I was hoping LR6 would fix this issue, but it didn't.

Whenever I import a new session, I notice that the thumbnails are first all blurry, and then will start to render the clear/detailed versions, but only the thumbnails that are currently on the screen will get rendered with detail, and as soon as I scroll down, all the other thumbnails are still blurry. This is really frustrating because I would have to "babysit" the thumbnail rendering by scrolling the screen periodically so the remaining thumbnails can get rendered too. If I don't scroll down, the remaining thumbnails will remain blurry for as long as I don't scroll to them. But as soon as I scroll to them, LR will start to render those clearly. The speed of the rendering is also quite slow--it takes about a second to render each thumbnail.

How can I get LR to automatically render the thumbnails with clarity without me having to babysit the process? 

The settings I current have are as follows:
Import file handling/Build Previews: Standard
Build Smart Previews
Thumbnails size - Set to about 1/3 from the right on the size slider
RAW files are stored on SSD
Catalog stored on HHD (I used to have it also stored on SSD but saw no significant difference in speed/responsiveness)


----------



## Lunatique (Jul 30, 2015)

I forgot to mention another thing related to this problem. 

With sessions I had previously already worked on, and the thumbnails have already been rendered clearly. If I at a later date return to that session, the thumbnails are now blurry again and must be rendered again. Also, the edits I made previously would be applied to the thumbnails while they are being rendered, and the speed is also about one thumbnail per second. Why does this happen?

BTW, I have set very high maximum size for the Camera Raw Cache Settings (200 GB), just to be sure that wasn't the cause.


----------



## Jim Wilde (Jul 30, 2015)

Hi, welcome to the forum.

Reading your first post, and trying to explain what I think is happening, I've made the assumption that you are attempting to browse through the grid of imported photos *before* the import has finished. Is that correct?

If you are requesting Standard Previews to be created as part of the import process, then the behaviour you see should not occur *provided* that the full process has completed, i.e. the standard previews have been generated. The first stage of the import, assuming you are importing from a memory card, is that the selected files are copied to the new hard drive location, and once all files have been copied the second stage (rendering Standard and Smart previews) will begin. So at the end of the first stage small thumbnails of all the imported files now exist in the grid, and you can scroll through that grid....but if you do that and bring images into the grid *before* the standard preview has been built then you will see the behaviour you describe. Lightroom does indeed, in normal circumstances, automatically generate standard previews for any image brought into the grid or the filmstrip if the standard preview doesn't yet exist. The only exception to this "rule" is the issue you describe in your second post, see below.

Adding to the "problem" is the fact that you are also having Smart Previews built during import as well.....that means that the building of both Standard and Smart previews runs in parallel, which naturally extends the amount of time that it takes to complete the Standard preview build, which is the bit of the import that you need if you want to start working through the images. Personally, I tend to wait until the full import process has completed, i.e. files are copied to hard drives, then 1:1 previews and Smart previews are built.

Regarding the issue which you describe in your second post, what I think happens when you edit a photo is that the existing library preview (Standard or 1:1) is discarded (obviously because it's now out-of-date) but only a thumbnail preview is automatically created so that you can see the adjustments in the Filmstrip and navigator. A new standard preview is not created until the photo is opened in the Library Loupe....so yes if you edit a series of pictures then move to Library and start to review them in the Loupe you should expect to see a brief "loading" indicator while the standard preview is re-built. Oddly, if you bring all those edited photos into the Grid, standard previews are not automatically built (which is the exception to the "rule" that I mentioned above).

Hope that helps to explain what you might be seeing. Let me know if my assumptions are wrong.


----------



## Johan Elzenga (Jul 30, 2015)

Jim, I don't think you understand the problem. It's not that the 'loading' indicator comes up when you open an image in Zoom mode, it's that thumbnails don't get updated if they are 'out of sight' in the grid and the filmstrip. I see this too and it's not just something that happens during import. It can also happen if you adjust a very large number of images through synchronization or using Quick Develop. It even happens if you increase the size of the grid enough for Lightroom to have to generate new thumbnails. _Apparently, previews and thumbnails are not the same thing!_ I tested this by letting Lightroom generate 1000 smart previews for a series of images. Lightroom will generate all the previews allright, but will still not update those thumbnails that are 'out of sight' in the grid. After Lightroom tells me it is finished generating the previews, the 'out of sight' thumbnails are still not updated. If I scroll to get them into view, I first see the old and blurry thumbnails and then I see them getting updated. Very annoying indeed.

BTW: I don't use the filmstrip, I keep it hidden. That's because I use two screens, so I can put thumbnails on the second screen when I'm in the Develop module. I'm not sure if this has something to do with it, but it might be that all thumbnails do get updated if you do have the filmstrip in sight. I'll have to check that.


----------



## Lunatique (Jul 30, 2015)

Thanks for helping, Jim.

Yes, I was talking about the grid view thumbnails, and no, I did not mean when the photos are still being imported/copied to the hard drive from the memory card. The problem I described occurs after all the previews have already finished building. It's as if LR does not render the thumbnails into clear/detailed versions unless the thumbnails are actually visible on the grid at that moment. Only the thumbnails that can be seen on th grid will "activate" the thumbnail rendering process. Any thumbnails that are above or below the currenly displayed thumbnails on the screen will remain blurry, until I scroll the screen to show them. This is why I said I'd have to "babysit" the process since it is not automatic. There's no way for me to force LR to automatically render all the thumbnails in the current folder I'm working on regardless if the thumbnails of the photos are shown on the grid at the moment or not. 

So let's say photos 1-12 are currenly showing on the screen in the thumbnails grid, while 13-100 are not shown on the screen. What I'll see is 1-12's blurry thumbnails rendered into sharp/detailed thumbnails at about the speed of one thumbnail per second. Once all thumbnails on the screen are done rendering into sharp detail, if I don't scroll the screen to show the rest of the thumbnails (13-100), they will remain blurry. So if I don't scroll the screen for an hour ( or ten hours), they will stay blurry for as long as I don't scroll to them. But the instant I do scroll down-- let's say I scroll only one line down and 13-16 now are have come into view on the screen. That means 13-16's blurry thumbnails will start rendering the sharp/detailed version (always at about one thumbnail per second). But if I don't scroll to reveal 17-20, they again will not start rendering the detailed thumbnails until I do scroll down to reveal them on the screen. If I scroll quickly and jump to 70-82, then only those will start rendering. But if I scroll away after only 70-72 have been rendered, then the rest of the thumbnails that were displayed on the screen will not be rendered. They would have to stay visible on the screen in order to be "àctivated" for rendering. If I scroll away before a thumbnail is rendered, then it will not get rendered and will remain blury, until I do   give it enough time to remain on the screen and get its turn to be rendered.

So basically, whether a thumbnail is currently displayed on the screen is what determines if it'll be rendered. This is why I said I have to "babysit" the process. As you can imagine, if I have hundred of photos in that folder, it gets really annoying to have to make sure all thumbnails get rendered.


----------



## Jim Wilde (Jul 30, 2015)

Johan, I really do understand the problem. The initial post related to the problem during import, and I explained what happens. If you leave the import to complete, then all thumbnails/previews are created, and the problem as described should not occur. Start scrolling through the grid before the previews have been generated and yes you will see the problem.

The second post described the problem after edits have been applied, and I explained that for some reason (which may be a bug or as designed) previews are not automatically updated until the images are brought into view either in the Grid or the Filmstrip (so yes, any "out of sight" images remain not updated until brought into view). This is the same process as happens should you delete the previews cache....Lightroom will only start to generate previews when an image appears in the Grid/Filmstrip. That's the way it has always worked, and probably with good reason.

Thumbnails are part of the preview "pyramid", so when we refer to "previews" we really ought to clarify which part of the preview pyramid we mean.

And rendering Smart Previews has no impact on that preview "pyramid", the Smart Previews cache is a totally different thing entirely and not at all relevant to the issue being described here. Rendering Standard previews, however, should eliminate the issue, i.e. all parts of the preview "pyramid", including the thumbnails, would be updated when a Standard Preview is rendered.


----------



## Jim Wilde (Jul 30, 2015)

Lunatique said:


> Thanks for helping, Jim.
> 
> Yes, I was talking about the grid view thumbnails, and no, I did not mean when the photos are still being imported/copied to the hard drive from the memory card. The problem I described occurs after all the previews have already finished building. It's as if LR does not render the thumbnails into clear/detailed versions unless the thumbnails are actually visible on the grid at that moment. Only the thumbnails that can be seen on th grid will "activate" the thumbnail rendering process. Any thumbnails that are above or below the currenly displayed thumbnails on the screen will remain blurry, until I scroll the screen to show them. This is why I said I'd have to "babysit" the process since it is not automatic. There's no way for me to force LR to automatically render all the thumbnails in the current folder I'm working on regardless if the thumbnails of the photos are shown on the grid at the moment or not.



That really shouldn't happen if you are rendering Standard Previews during import, and you wait for that process to complete. After that you should be able to scroll up and down in the Grid with no delay and see no thumbnail updating going on. So it's a bit of a mystery. Can you confirm that you are definitely rendering Standard Previews during import? Are you applying any develop presets during import? Do you have "apply auto-tone" selected in your preferences?


----------



## Johan Elzenga (Jul 30, 2015)

Hi Jim, 
I realize it's difficult to have a conversation with two people at the same time, but do read my comments as well. I see this too, and it's not just an issue when you import images. I also see it when I update the WB of a large number of existing images, for example. Even several days (and starts and stops of Lightroom) later, I may find that there are still thumbnails that have not been updated because I had not scrolled to them yet. Even forcing Lightroom to render smart previews (after the WB change, of cause) doesn't change this behavior.


----------



## davidedric (Jul 30, 2015)

+1. I see the same behaviour as Johan, when viewing the grid NOT during import.  It's certainly irritating, but I suppose I have just accepted it as the way things are, so I haven't done any testing.  I'll watch the thread with interest.

Dave


----------



## Jim Wilde (Jul 30, 2015)

JohanElzenga said:


> Hi Jim,
> I realize it's difficult to have a conversation with two people at the same time, but do read my comments as well. I see this too, and it's not just an issue when you import images. I also see it when I update the WB of a large number of existing images, for example. Even several days (and starts and stops of Lightroom) later, I may find that there are still thumbnails that have not been updated because I had not scrolled to them yet. Even forcing Lightroom to render smart previews (after the WB change, of cause) doesn't change this behavior.



I did read your comments, Johan...but there are two different issues being discussed here. In his first post the OP was discussing the problem he was experiencing after importing a bunch of images, and I have asked some questions about that in my post #7.

You, OTOH, are talking about a problem that you experience after applying a develop edit, i.e. the previews are not updated, which I tried to address in my post #6. That problem occurs because as soon as an edit is applied the existing library preview becomes out-of-date and is discarded. A new preview "pyramid" is created for tho edited image(s), but only some of the smaller thumbnails are in fact created. When you move on to another image, no further part of the "pyramid" (i.e. the standard-sized preview) is created, except when/if the image is opened in the Library module in the Loupe. When I tested the preview-creation process, the "normal" behaviour of updating the preview when the image appears anywhere in the Grid or Filmstrip (as is the case if you delete the previews cache) did not apply to a recently edited image, though my testing didn't go so far as checking what happened after several days and several restarts.

As I also said in post #6, you need to render *Standard* previews, not *Smart* previews, if you want to fix the "problem".


----------



## Lunatique (Jul 30, 2015)

It's good to know that I'm not the only one with this problem, because it means the problem isn't unique to my setup, but a more universal problem that has a chance to get fixed by Adobe (assuming this is a problem they know about and deem important to fix). 

@Jim - Yes, I definitely have standard preview chosen in the "Build Previews" dropdown selection, and "Build Smart Previews" checked. 

I do have develop presets I apply to the imported photos depending on which camera it is (it's only the camera calibration profile. I set it to "Camera Faithful" for the 5D Mark III, and "Camera Portrait" for the E-M1). And no, I don't apply auto-tone to the photos in the preferences. 

But like I said, even if I import the photos and then just go do something else for an hour to make sure all previews and settings have been generated/applied to the photos, it doesn't change how the thumbnails will only get rendered into clear/detailed versions when they are shown on the screen in the grid view. Any thumbnail not shown on the screen at the time will remain blurry, until they are scrolled to and shown on the screen.

As for the second issue, it seems to me that all the folders I've worked on in the past but haven't worked on for a while (a few weeks, months), will have all the thumbnails show up as gray blanks (on both the grid and the filmstrip), and they'll only get rendered if they are seen on the screen. Any thumbnail that haven't been scrolled to will remain gray blanks. I had assumed this might have something to do with how big I've set the maximum size for the Camera Raw Cache Settings, but I've since set it to 200 GB and I still see the same behavior, including recent photo sessions I've since shot after I've set the size to 200 GB. Now I'm wondering if LR somehow only keeps the very recent (a few days) thumbnails stored, but older ones are deleted to keep the library/catalog size small, which is why when you visit slightly older sessions, LR will have to regenerate the thumbnails.


----------



## Jim Wilde (Jul 30, 2015)

Lunatique said:


> It's good to know that I'm not the only one with this problem, because it means the problem isn't unique to my setup, but a more universal problem that has a chance to get fixed by Adobe (assuming this is a problem they know about and deem important to fix).



I don't believe this is a "problem" in the sense of being a bug, it's just the way it works, and once you understand how it works it's easy enough to work around.



> @Jim - Yes, I definitely have standard preview chosen in the "Build Previews" dropdown selection, and "Build Smart Previews" checked.
> 
> I do have develop presets I apply to the imported photos depending on which camera it is (it's only the camera calibration profile. I set it to "Camera Faithful" for the 5D Mark III, and "Camera Portrait" for the E-M1). And no, I don't apply auto-tone to the photos in the preferences.



As I said, this is unexpected import behaviour, which I'm trying to understand. The develop presets that you apply, is that via the Import screen or after the import has finished?




> As for the second issue, it seems to me that all the folders I've worked on in the past but haven't worked on for a while (a few weeks, months), will have all the thumbnails show up as gray blanks (on both the grid and the filmstrip), and they'll only get rendered if they are seen on the screen. Any thumbnail that haven't been scrolled to will remain gray blanks. I had assumed this might have something to do with how big I've set the maximum size for the Camera Raw Cache Settings, but I've since set it to 200 GB and I still see the same behavior, including recent photo sessions I've since shot after I've set the size to 200 GB. Now I'm wondering if LR somehow only keeps the very recent (a few days) thumbnails stored, but older ones are deleted to keep the library/catalog size small, which is why when you visit slightly older sessions, LR will have to regenerate the thumbnails.



Grey blank thumbnails are a symptom of there being no preview file for the image(s) in question. Because Lightroom does not delete library previews at all, this problem is usually the result of a preview cache problem in the past, and there are many scenarios to explain how that could happen. If you have lots of those blanks in your catalog, and it's a nuisance, the best thing to do is have Lightroom render standard-sized previews for the entire catalog (it will in fact only render them for those files that don't have one).

The Camera Raw Cache has no influence whatsoever on the subject being discussed.


----------



## Lunatique (Jul 30, 2015)

Jim Wilde said:


> As I said, this is unexpected import behaviour, which I'm trying to understand. The develop presets that you apply, is that via the Import screen or after the import has finished?



Applied during the import on the import screen. I have the develop presets saved with my import preset, along with destination folder and other settings.


----------



## Jim Wilde (Jul 30, 2015)

Lunatique said:


> Applied during the import on the import screen. I have the develop presets saved with my import preset, along with destination folder and other settings.



OK, thanks. I'll do some testing over the next day or two to see if I can figure out what might be happening. The develop presets might be the clue, so next import don't include any of them and see if the problem goes away.


----------



## Lunatique (Jul 30, 2015)

I just did an experiment taking Jim's replies as reference. I chose a folder with a relatively large number of photos (161), and then made sure that the thumbnails were all gray blanks, and then as the blurry versions started popping in, I scrolled to make sure all the other thumbnails not on the grid were still gray blanks or blurry. I then went to the menu and chose Library/Previews/Build Standard-Sized Previews and then chose to build all. Then after the process finished, I checked, and voila! All the thumbnails were clear/detailed and there was no problem. 

What this tells me, is that somehow in the past the standard previews got corrupted/deleted somehow. So I guess what I should do from now on it to simply take a moment to rebuild the standard previews for a session before starting to work on it, so I don't have to babysit the thumbnail renderings. 

Thanks for help, Jim!


----------



## Johan Elzenga (Jul 30, 2015)

Jim Wilde said:


> I did read your comments, Johan...but there are two different issues being discussed here. In his first post the OP was discussing the problem he was experiencing after importing a bunch of images, and I have asked some questions about that in my post #7.
> 
> You, OTOH, are talking about a problem that you experience after applying a develop edit, i.e. the previews are not updated, which I tried to address in my post #6. That problem occurs because as soon as an edit is applied the existing library preview becomes out-of-date and is discarded. A new preview "pyramid" is created for tho edited image(s), but only some of the smaller thumbnails are in fact created. When you move on to another image, no further part of the "pyramid" (i.e. the standard-sized preview) is created, except when/if the image is opened in the Library module in the Loupe. When I tested the preview-creation process, the "normal" behaviour of updating the preview when the image appears anywhere in the Grid or Filmstrip (as is the case if you delete the previews cache) did not apply to a recently edited image, though my testing didn't go so far as checking what happened after several days and several restarts.
> 
> As I also said in post #6, you need to render *Standard* previews, not *Smart* previews, if you want to fix the "problem".



I only rendered smart previews as a test. Normally I do use standard previews. The kind of preview doesn't make any difference. It's also not the problem. Lightroom renders *previews* in the background just fine, but it doesn't render *thumbnails* that are not visible. I will check if forcing re-rendering of standard previews fixes it.


----------



## Johan Elzenga (Jul 30, 2015)

Well, I did a little test. I selected 140 photos and re-rendered standard previews. That does indeed update the thumbnails, also the ones that are invisible from the grid. So far so good. 

Next I applied a crazy preset to those images, by choosing 'Fluorescent' white balance (from the Quick Develop menu). Obviously all the visible thumbnails turned blue. I waited quite some more time, so that Lightroom had enough time to also update the invisible thumbnails if it chose to do so. Then I scrolled down to check if it had actually done that. *Nope, all the previously invisible thumbnails were still normal*, they started to turn blue only after I left them on screen for a while.

Conclusion. Yes, you can solve the problem by forcing a re-rendering of standard previews each time you've applied a preset to a whole bunch of images. That is correct. But Lightroom should re-render them automatically, so I do consider this a bug.


----------



## tspear (Jul 31, 2015)

Johan,

You may consider it a bug, but it is working as designed. So I would suggest you provide feedback to Adobe.
I can see why they do not redo the previews, for many people it would slow down the system and also those with larger libraries will have the images fall off the preview cache anyway. So it would be wasted processing, and likely slowing down the computer when the user is trying to do something else.

Tim


----------



## Johan Elzenga (Jul 31, 2015)

I doubt this is as designed, but if it is, it's a design flaw. I understand that Lightroom needs to be responsive, so updating thumbnails in the background should be something that has low priority. Any other activity must come first. However, it is ridiculous that Lightroom can sit idle for many hours, and then will still not update those thumbnails. If I let it sit overnight, why doesn't it update those thumbnails during that time? This doesn't make any sense at all. I think the design was to give other processes priority, but the developers forgot to turn on rendering again when Lightroom is idle. 

It's also unacceptable from a workflow perspective. If I scroll down in the Library module to find a certain image, I must be certain that the thumbnails I'm seeing are up-to-date. How can I find the most suitable image if what I see may not be what I get? I always have to wait a little to make sure that the thumbnails are up to date. That is what slows down my workflow! 

Finally, I don't think it has anything to do with the preview cache. Previews are small JPEG's, stored in the library. They can be made up to date no matter how many you've got. The preview cache may make loading faster, but Lightroom will never run out of space to store previews on disk as long as the library itself fits on the disk. The way I understand it, the preview cache is used to store 1:1 previews, used when you zoom in 100%. Without it, you would see a rendering delay each time you zoom in 100%, even if you already did that just a few minutes ago. It's not used for the standard previews we are talking about, because they are already stored individually. But perhaps I understand that wrong.


----------



## Jim Wilde (Jul 31, 2015)

JohanElzenga said:


> Finally, I don't think it has anything to do with the preview cache. Previews are small JPEG's, stored in the library. They can be made up to date no matter how many you've got. The preview cache may make loading faster, but Lightroom will never run out of space to store previews on disk as long as the library itself fits on the disk. The way I understand it, the preview cache is used to store 1:1 previews, used when you zoom in 100%. Without it, you would see a rendering delay each time you zoom in 100%, even if you already did that just a few minutes ago. It's not used for the standard previews we are talking about, because they are already stored individually. But perhaps I understand that wrong.



Yes, I think you do understand that wrong. Let me try to explain what the "preview cache" actually is, then the behaviour you are seeing may make more sense to you (though I suspect you'll still think its a design flaw):

When we talk about the preview cache, we are generally referring to "yourcatalog Previews.lrdata", which is a "package" on OSX and a folder on Windows, and sits adjacent to the corresponding catalog. This folder/package contains a somewhat convoluted sub-folder structure, but at the bottom level you will see a series of files with the .lrprev file extension. Each .lrprev file corresponds to one image in the catalog, and there is a small database file at the root level of the previews cache which controls the linkage between image and preview file.

If you examine a .lrprev file (and there are probably various utilities which enable you to do that) you will find a set of jpegs of varying sizes. Ignoring 1:1 previews for the moment, the largest of these jpegs will typically be the "standard-sized" preview, the size of which is determined by the catalog settings, then below that will be one at half the size, then one at a quarter of the size, and so on. As an example, the "standard-sized" preview on my Windows system is 1920 pixels, and below that are jpegs sized at 960, 480, 240, 120, 60. These are all contained within that one .lrprev file, and is the "preview pyramid" that I referred to in my previous posts.

The purpose of these multiple jpegs is to enable Lightroom to use the most appropriately sized preview in the various display modes (Filmstrip, Grid, Navigator, Loupe, etc.), so you see that "Thumbnails" and "Previews" are one and the same thing, i.e. "Thumbnails" are just part of the "preview pyramid" in the same way that "standard" previews are.

If you render 1:1 previews, the existing preview file is discarded and a new preview "pyramid" is built, the topmost jpeg will obviously be the size of the full image, and below that will be the same 1/2, 1/4, 1/8 etc. sized jpegs. So for example, rendering 1:1 previews from my 5D3 camera would result in a preview pyramid of 5760, 2880, 1440, 720, 360, 180, and 90 pixels. So again, note that there is no separate cache for 1:1 previews, they all form part of the one and only Library preview cache. The Smart Preview cache is a totally separate entity, used for a different purpose, nothing whatsoever to do with the display of images in the various Library module windows.

Now, let's try to apply that knowledge into the scenario that you are describing, i.e. syncing edits (using either Quick Develop or the Develop module) to a set of images. First of all, consider what happens when you apply edits to a single image in the Develop module. In the main Loupe window you are viewing a freshly rendered special preview (not part of the library previews cache) which is capable of being updated in real-time as you move sliders or apply presets, and I think the thumbnail that you see in the Navigator window is also rendered anew at the same time. But also on the screen you may well have the Filmstrip open, and all the thumbnails that you see there are the most appropriately-sized thumbnail from the library preview cache. So as you move the sliders, not only does the main Loupe window update, but there's also the need to reflect that change in the Filmstrip thumbnail. The existing preview file for that image is discarded (but not deleted immediately to allow for 'undo'), and a new one is started.....but because of the performance hit that would occur should the full preview pyramid be rendered every time a slider was moved, only a subset of the full pyramid is created, containing some of the smaller-sized thumbnails.

So in "normal" circumstances, moving back to Grid view in the Library module should be OK, as the thumbnail for the edited image should already have been created. Opening that image then into Loupe mode could see a small "loading" delay as the standard-sized preview is then rendered automatically.

The complications arise when a large number of images (i.e. more than can be displayed in the Filmstrip or Grid) have had edits synced to them. In that situation, assuming that the effect of the edit is noticeable on the Filmstrip thumbnails, you will see a slow progression of the edits through the Filmstrip as the new preview files start to be rendered. The problem is that Lightroom does not appear to update the previews of all the selected images which are "off screen" until they are brought "on screen" by scrolling through the Filmstrip or the Grid. I agree that behaviour is odd, and well worth asking Adobe to explain the thinking behind that design choice (assuming it's by design, not a bug). 

Hope the explanation helps.


----------



## Johan Elzenga (Jul 31, 2015)

Thanks for clarifying that point Jim, but I think you actually confirmed what I concluded. Tspear suggested that rendering lots of previews would be useless, because the images would 'fall off the preview cache' again. That suggests there is a limited cache size, but there is not. My lrpreview file is over 100 GB. Lightroom will simply store as many previews as neccessary in that file, there is no size limit. I stand corrected about the 1:1 previews. I thought that 1:1 previews might not be stored in there, unless you generate them yourself. I was thinking about the ACR cache, that does indeed have a size limit. You can set the size in the Lightroom Preferences, under File Handling. I realize that cache is probably only used for images that are sent from Lightroom to Photoshop.

My conclusion still stands. It makes sense that Lightoom does not use processor time to render 'out of sight' previews, _while you are working with it_. You don't want that process to slow you down. It does not make sense however that Lightroom doesn't start the rendering process again when it is idle. Right now it can sit idle the whole night, and then slow me down when I scroll through the grid the next morning. That is poor design if it was designed that way, or a bug if it simply was forgotten.


----------



## Johan Elzenga (Jul 31, 2015)

BTW, I use a Macintosh. On a Macintosh that .lrpreview 'file' is a so-called 'package', a folder that looks like a file in the Finder and can be double clicked to start the application it belongs to. You can simply look inside it by Ctrl-clicking on it and choosing 'Show package contents'. The only thing is that you cannot easily look at the jpeg previews themselves, because they don't have the correct extension.


----------



## Jim Wilde (Jul 31, 2015)

I think that if you feel that strongly about the issue, Johan, you should put in an official feature request to sweep up all such outstanding preview updates after a certain amount of inactivity.


----------



## Jim Wilde (Jul 31, 2015)

JohanElzenga said:


> BTW, I use a Macintosh. On a Macintosh that .lrpreview 'file' is a so-called 'package', a folder that looks like a file in the Finder and can be double clicked to start the application it belongs to. You can simply look inside it by Ctrl-clicking on it and choosing 'Show package contents'. The only thing is that you cannot easily look at the jpeg previews themselves, because they don't have the correct extension.



I've used File Juicer in the past to look inside the preview files and extract the various jpeg previews.


----------



## Johan Elzenga (Jul 31, 2015)

Jim Wilde said:


> I think that if you feel that strongly about the issue, Johan, you should put in an official feature request to sweep up all such outstanding preview updates after a certain amount of inactivity.



Maybe I should, but I don't have a good experience with that kind of requests. It's usually a waste of time. I can give you quite a list of smaller and bigger annoyances that should be fixed (and Adobe knows about them), but nothing ever happens. The only bugs that tend to be addressed are the ones that really cause unacceptable problems.


----------



## Lunatique (Jul 29, 2015)

One issue with Lightroom that's bothered me for a long time, but I couldn't find any answers on the web for, is the way the thumbnails are rendered. I was hoping LR6 would fix this issue, but it didn't.

Whenever I import a new session, I notice that the thumbnails are first all blurry, and then will start to render the clear/detailed versions, but only the thumbnails that are currently on the screen will get rendered with detail, and as soon as I scroll down, all the other thumbnails are still blurry. This is really frustrating because I would have to "babysit" the thumbnail rendering by scrolling the screen periodically so the remaining thumbnails can get rendered too. If I don't scroll down, the remaining thumbnails will remain blurry for as long as I don't scroll to them. But as soon as I scroll to them, LR will start to render those clearly. The speed of the rendering is also quite slow--it takes about a second to render each thumbnail.

How can I get LR to automatically render the thumbnails with clarity without me having to babysit the process? 

The settings I current have are as follows:
Import file handling/Build Previews: Standard
Build Smart Previews
Thumbnails size - Set to about 1/3 from the right on the size slider
RAW files are stored on SSD
Catalog stored on HHD (I used to have it also stored on SSD but saw no significant difference in speed/responsiveness)


----------



## Michael D. (Jul 31, 2015)

davidedric said:


> +1. I see the same behaviour as Johan, when viewing the grid NOT during import.  It's certainly irritating, but I suppose I have just accepted it as the way things are, so I haven't done any testing.  I'll watch the thread with interest.
> 
> Dave



Me too... I have just accepted that is how it is...  My computer is pretty zippy, so the waiting time for the thumbnails to 'develop' is not terribly bothersome.   Ideally they would all be done as I scroll through the grid.


----------



## Mark tucker (May 2, 2016)

Let me ask a related question:

Same deal-- if I am in library mode and I'm making color corrections on many images at once using Sync, if I come back to Library page, only the Visible images are corrected. If I scroll up or down to reveal other images that i synced with corrections, the "slide mount" around the images shows three DOTS to indicated that it's an outdated preview. I am then forced to babysit the computer and manually scroll down to REVEAL all the images in that set that have been altered. I have no idea why Lightroom can't simply KEEP WORKING. And continue to recorrect all the altered images. Why does it force you to Reveal them in order for them to be altered and corrected to most recent settings. ?

Thanks

Mark Tucker
Marktucker.com


----------



## Jim Wilde (May 2, 2016)

I asked that same question myself a few years ago. IIRC, the answer was that rendering previews of "hidden" images would be a waste of resources if further changes were synced to them even before the first changes had been "viewed" on all the selected images.


----------



## Johan Elzenga (May 2, 2016)

Jim Wilde said:


> I asked that same question myself a few years ago. IIRC, the answer was that rendering previews of "hidden" images would be a waste of resources if further changes were synced to them even before the first changes had been "viewed" on all the selected images.



It's the way it is, but I find that a poor choice. The chance of that happening is smaller than the chance that the user will start scrolling to see the images. Besides, Lightroom could easily be designed in such a way that these recourses are only used when Lightroom is idle anyway. Right now, Lightroom can sit idle all night, and then the next morning it has to start updating the thumbnails frantically when you start scrolling through the grid of images. It's one of those 'Adobe things', I guess.


----------



## tspear (May 2, 2016)

At some point, I thought Lr had limited cache space. As such, it has no way to predict which images need to be cached.
Further, the kind of run time programming you guys are talking about provides very little return since it is complex to implement, with many failure modes, and does little to enhance the user experience. What do you think the majority of users want? A dehaze function, or such a predictive scroll for when massive presets are applied? There is a finite team and resources. Pick your functions....


----------



## Johan Elzenga (May 2, 2016)

tspear said:


> At some point, I thought Lr had limited cache space. As such, it has no way to predict which images need to be cached.
> Further, the kind of run time programming you guys are talking about provides very little return since it is complex to implement, with many failure modes, and does little to enhance the user experience. What do you think the majority of users want? A dehaze function, or such a predictive scroll for when massive presets are applied? There is a finite team and resources. Pick your functions....



I'm not sure you understand what we're talking about... We are not talking about 'predictive scroll', or anything like that. What we are talking about is that thumbnails should be updated to reflect the current state of the image, also if those thumbnails are not visible right now. The reason is that if they are not updated, you will see incorrect thumbnails as soon as you start to scroll through the grid view. That is extremely annoying and causes significant delays (you have to wait until they are updated before you can judge anything), so it does indeed enhance the user experience if this problem was solved one day. And if I could choose between this and the totally useless 'Ken Burns effects' in the slide show, I'd pick this every day...


----------



## tspear (May 2, 2016)

Actually I do follow. But in order to know which images and the order the images should be built, requires that the engineers predict the scrolling. Otherwise, they may start building images which are not being viewed, or will not be viewed, or viewed later, and then you need to handle dynamic reordering of the processing of the thumbnails, and deal with prioritization flags and queue management. Further, the system has to be interruptible or have the ability to throttle or ability to monitor the system as a whole to determine if such generation is feasible. Do you really want Lr sucking up resources because it is idel, but you are streaming Netflix? Or working in Photoshop?
As for the Ken Burns effect, I have no idea what that is, mostly because I have never used the slideshow 
But either marketing, sales, or enough customers demanded such a feature. At a company like Adobe, polling and testing drive a lot of the features which come from sales and marketing. (I used to interact with Adobe a lot on the Adobe Connect application which they bought, so I assume the culture is the same across the company).


----------



## Johan Elzenga (May 2, 2016)

No, you don't need to predict scrolling. Lightroom should simply update the previews of *all* the selected images in 'Previews.lrdata'. There is no compelling reason for not updating previews for images because they might not be viewed. Who cares if a preview is updated but never actually viewed? Big deal! And if you don't want to spend processor cycles on it _right_ _now_, why wouldn't you want to do that when Lightroom is idle anyway? 

We're not talking about anything that would take a lot of time to implement either. All the subroutines are already there. When you import hundreds of images, Lightroom will generate previews for *all* of them, not just for the ones that are visible in the grid at this point in time. That is *exactly* the same situation, so Lightroom could simply call the same subroutine. If Lightroom can and will do it when you _import_ hundreds of images, why would it suddenly be a problem when you _apply a preset_ to a similar number of images? Sorry, but that doesn't make any sense at all. 

I rest my case, because I think this thread is just repeating itself.


----------



## Mark tucker (May 8, 2016)

We are not talking about the year 1985, and sitting here in front of a 512k Mac. We are talking about 2016, with either a MacBook Pro Retina or the newest imac. Absolutely plenty of background power to build some stupid Previews in the background. Argument holds no water. Test it -- just scroll up to unveil the out of date Previews, and they begin to update quickly. No smoke coming out of the USB port. Done with ease. So why not just do it in the background?

It's beyond frustrating when your trying to tweak a bunch of Raws after a job, and you scroll up and have to babysit it. Watching the three little "dots" update on the slide mount and disappear. 

Makes no sense at all. It's not like Lightroom is some obscure product that adobe doesn't care about. 

Just my view. Adobe, please fix this. It makes you look bad. 










JohanElzenga said:


> No, you don't need to predict scrolling. Lightroom should simply update the previews of *all* the selected images in 'Previews.lrdata'. There is no compelling reason for not updating previews for images because they might not be viewed. Who cares if a preview is updated but never actually viewed? Big deal! And if you don't want to spend processor cycles on it _right_ _now_, why wouldn't you want to do that when Lightroom is idle anyway?
> 
> We're not talking about anything that would take a lot of time to implement either. All the subroutines are already there. When you import hundreds of images, Lightroom will generate previews for *all* of them, not just for the ones that are visible in the grid at this point in time. That is *exactly* the same situation, so Lightroom could simply call the same subroutine. If Lightroom can and will do it when you _import_ hundreds of images, why would it suddenly be a problem when you _apply a preset_ to a similar number of images? Sorry, but that doesn't make any sense at all.
> 
> I rest my case, because I think this thread is just repeating itself.


----------



## Johan Elzenga (May 9, 2016)

Just as a reminder: you can force Lightroom to (re)build all previews, including the 'out of sight' previews by selecting 'Library - Previews - Build Standard-sized Previews' after you've applied adjustments on a large selection of images (as long as the selection is still active). I completely agree that it shouldn't be necessary to do this, but at least it's possible and easier than scrolling up and down just to make Lightroom start (re)building previews.


----------



## cmphoto (May 9, 2016)

How did we go from talking about thumbnails that are not showing on the screen to talking about previews?
I have the exact same problem as the OP when importing images.  No adjustments, no "apply on imports", no nothing but simply importing.  Makes no difference if it is importing, or simply adding images already on the drive.  No THUMBNAILS will be updated until you scroll down to them and then it is about 1 second each. Five rows of six images = 30 seconds per screen, 480 images = 16 screens, 16 screens = 8 minutes.  Just to see the thumbnails!
And it makes no difference how long the computer has set there with Lightroom running.
This, to me, has always been one of the most frustrating things about Lightroom.

Cliff


----------



## tspear (May 9, 2016)

Cliff,

I have never seen that issue. Or maybe I never noticed it, but I go through the images as they are imported and never noticed anything. I will import my weekend pictures later this week (only a few though) and see if I have such a problem.


----------



## Johan Elzenga (May 9, 2016)

cmphoto said:


> How did we go from talking about thumbnails that are not showing on the screen to talking about previews?



Thumbnails are just the smallest version of the previews. When Lightroom builds a preview, it actually builds more than one size.


----------



## turtlez (Aug 10, 2016)

JohanElzenga said:


> Thumbnails are just the smallest version of the previews. When Lightroom builds a preview, it actually builds more than one size.



Hi Johan! saw that you updated to 6.6 now, but I had the BSOD issue with it, so after scrolling through a few other forums, I decided to go back to 5.7 (at least there's no BSOD), but am back with the same issue of it not rendering a preview.... had to do these to see the preview of the photos, 1 at a time to see what is actually done onto the photo....

1) Going into the develop module, scrolling thru the photos 1 at a time. (but when I go back to the "library view", everything shows back the same outdated preview colours...., or till when I execute the 2nd step)
2) Zooming into the photo viewing it at 1:1, or click "render 1:1", which will take too long a time

Did you manage to solve this? Or does version 5.7.1 solves this? (if anyone knows)

Thanks for the time to reply


----------



## Johan Elzenga (Aug 10, 2016)

I'm sorry, but I don't follow you. I don't need to solve anything, because Lightroom works exactly as it is designed to work. It's just that Lightroom is programmed in a rather sloppy way, and that causes the problem of previews not updating if they are not visible in the grid. In message 35 I already explained how you can force Lightroom to do it anyway, but that shouldn't be necessary.


----------



## turtlez (Aug 11, 2016)

JohanElzenga said:


> I'm sorry, but I don't follow you. I don't need to solve anything, because Lightroom works exactly as it is designed to work. It's just that Lightroom is programmed in a rather sloppy way, and that causes the problem of previews not updating if they are not visible in the grid. In message 35 I already explained how you can force Lightroom to do it anyway, but that shouldn't be necessary.



I did that, but it doesn't seems to work too, unless I choose the "render 1:1" preview, which will take too long. I guess only a video screengrab is the only best way the show this "bug". Anyway, for the BSOD, I got a sudden realization....  it may be due to overheating that's causing it! Looking back, seems like the BSOD pops out the most often the more I try to restart it, because it's getting more and more hot! Shall try to use fans to cool it down, and I got a feeling 6.6 really renders faster (ability to use more processing power), that's why the higher heat, and higher rate of BSOD, to prevent laptop overheating to danger levels.

Will install back 6.6 and see if it works again. Just a note to all: TRY COOLING DOWN YOUR LAPTOP.


----------



## Mark tucker (Aug 30, 2016)

QUOTE BELOW THIS:

From Message 35, I am trying this one just one folder of a VERY large job from Canon 5DMarkIII RAW. I am on iMac 27 filled with RAM. It seems will take hours to rebuild just one folder of Previews. Truly, how can Lightroom 6 be designed in this sluggish way?

----


Just as a reminder: you can force Lightroom to (re)build all previews, including the 'out of sight' previews by selecting 'Library - Previews - Build Standard-sized Previews' after you've applied adjustments on a large selection of images (as long as the selection is still active). I completely agree that it shouldn't be necessary to do this, but at least it's possible and easier than scrolling up and down just to make Lightroom start (re)building previews.

http://www.johanfoto.com


----------



## Mark tucker (Aug 30, 2016)

Or.... let me ask it this way: Say you did Exposure and Color Correction adjustments to a folder full of RAWs, that were being generated into JPGs for editing to the client. (Advertising). Say that you made corrections, but most of the images were still not "scrolled up and visible yet" after the adjustments. Therefore, the "slide mount" on the file would show those three Dot Dot Dots in upper right, signifying that they were out of date, and that the new Preview had not been built. So say you just said Screw It, and started batching all those RAWS into JPGs anyway. So the Preview is out of date still. Once the RAW was processed into a JPG, would this newly created JPG show these corrections, or would the JPG be out of date as well, and not factor in the corrections you did to all those RAWs?

Thanks.


----------



## tspear (Aug 30, 2016)

The export includes the adjustments. No idea if it updates the previews at the same time though.


----------



## Johan Elzenga (Aug 30, 2016)

Yep, the exports will include the adjustments. It's not that adjustments are not applied, it's just that the previews aren't updated if they aren't visible (unless you used a 'force update').


----------

