Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: Rory on February 17, 2016, 03:18:38 pm
-
In general I'm a fan of lightroom, and I've been using it extensively since the first beta. One of my biggest frustrations is the general experience while moving through previews in the library module and the embedded jpegs in the import module (latest skylake PC with 32GB RAM and fast SSDs on 2560x1600 monitors). It is often slow, even with 1:1 previews generated, with lags and when you hold the forward key down on a PC when you lift the key the forward movement through images does not stop like most apps but keeps going and going. I'm thinking to myself, why can't a company like adobe do better?
Well, it is easy to blindly cry out about performance when you don't have any experience to back it up. So, last November I decided to see what is so difficult about something pretty simple - rapidly and smoothly viewing previews and embedded JPEGS. First I had to learn c++. Then I discovered the Qt framework, so I had to learn about it. I then tackled Raw and Jpeg file formats, figuring out where and how to read the embedded JPEGs and key metadata. Phew. Then I started to pull it all together in an image viewer that would build thumbnails and full size previews from the embedded JPEGs. Three months from a cold start I now have an app that will read the embedded JPEGs in D810 NEF files from a hard drive and cache ahead faster than you can flip through the images. In many cases it is as fast or faster than Photo Mechanic (but not as stable). Even when reading a card through a USB3 I can almost keep up, and no problem getting way ahead if you stop to check out an image.
Here is a screen shot of what I came up with - it works on PC/Mac/Linux. It is a proof of concept. I'll never have the energy or time to support the software. I can really appreciate the effort that takes, and just how good the stability of adobe products are - it is the performance I'm disappointed in.
(http://roryhill.zenfolio.com/img/s5/v118/p1650653723.png)
I know Photo Mechanic and Lightroom are doing more, and I doubt I could equal Photo Mechanic when I factor that extra stuff in, but I can now say with confidence that Lightroom performance is pathetic. With Adobe's resources and excellent engineers I simply cannot understand why they cannot speed up these two basic processes - where are their priorities? OTOH, the performance in the develop module is pretty good IMO.
Okay, I feel better. End of rant.
-
You wrote this in C++. right? I believe Lightroom is written in Lua, a VM with a JIT.
-
You wrote this in C++. right? I believe Lightroom is written in Lua, a VM with a JIT.
The UI is managed from Lua. The code that makes stuff happen is c or c++.
-
http://www.troygaul.com/LrExposedC4.html
Perhaps a bit dated but...
-
http://www.troygaul.com/LrExposedC4.html
Perhaps a bit dated but...
But what? I want LR to be fast. Surely that is what Adobe had in mind when they chose the tools and framework. I don't see anything in their design that precludes this. Lua was chosen for performance - it is primarily used in the gaming industry. There just does not seem to be a priority for previewing performance ...
-
The "but" was because that the presentation was from 2008 and I have no idea what changes Adobe may have made since then.
Like you I would like much better performance from Lightroom.
I'm afraid though it seems that Adobe's focus is on mobile these days rather than their desktop apps for photography.
-
I think you are right about the mobile.
-
Impressive..... Well done.
Do you mind me asking what tools / techniques you used to get the exif info. I am writing a small personal app as a pre-processor to Lightroom, which will allow me to copy and rename my images from my cards to disk, using my preferred file and folder naming structure. I would like to find a reliable way to get the Capture Time, so I can put the images in sub folders per year and also separate different images with different capture dates into possibly different destination folders. The Lightroom import features are lacking some basic selection criteria.
Any hints re Exif data extraction appreciated.
-
I know Photo Mechanic and Lightroom are doing more, and I doubt I could equal Photo Mechanic when I factor that extra stuff in, but I can now say with confidence that Lightroom performance is pathetic.
In Lr's case, the "more" is quite a bit more. It's processing the raw data, while you and PM are simply displaying the embedded JPEG. Let's compares apples with apples....
But what? I want LR to be fast. Surely that is what Adobe had in mind when they chose the tools and framework. I don't see anything in their design that precludes this. Lua was chosen for performance - it is primarily used in the gaming industry. There just does not seem to be a priority for previewing performance ...
The choice of Lua is not relevant. It was chosen as much because it was readily cross platform and because of Mark Hamburg's enthusiasm for the language.
A lot of us have asked Adobe many times for an embedded preview-browsing mode, which would seem a great use of the GPU. Aperture 3 had a preview mode, and I think there's one in Bridge, but one doesn't hear much about people using them. Read into that what you will.
John
-
The Lightroom import features are lacking some basic selection criteria.
Or rather, they are missing some you seem to want. You can already "separate different images with different capture dates into possibly different destination folders".
Any hints re Exif data extraction appreciated.
Embed Exiftools in your app. Depending on your needs, you can get values from it directly or by generating a text file.
-
Basic Selection Criteria.... Some I Want.
"Some I Want ...." True ... but I think there are options which would benefit many, including:
1. I do not always want to import my Jpgs, but have to and then delete inside Lr.
2. I may have a card with two different sets of shots on different dates. I only want to import a specific date range (usually a specific date) into a particular destination folder.
I will get my App to do a lot of extra stuff I would not expect Lightroom to do, such as tell me if I have Jpgs but no raw files, raw files but no jpgs, maintain a list of personal projects, so I can select rather than type, identify my own cameras by serial number, tell me if I have copied these files before and lots more. Etc.
Practical use for me. I do not want to delete my Jpgs before I know for sure I have the raw files.
Essentially a preview of what will end up on my disk and inside Lightroom.
Exif.
I am using Exiftool and have wonderful input by Phil Harvey (thanks again Phil), but generally interested in what tools are out there.
-
2. I may have a card with two different sets of shots on different dates. I only want to import a specific date range (usually a specific date) into a particular destination folder.
In the Import dialog, go to Destination Folder on the right hand side. It should show the import split into date folders with a checkbox against each date.
-
In the Import dialog, go to Destination Folder on the right hand side. It should show the import split into date folders with a checkbox against each date.
A long time ago I thought that was a good option, but I end up with a large number of sub folders with dates. I then have to drag and drop and delete the sub folders back to the main project folder. It may work for some but not for me. I just want the images selected to end up in the folder of my choice. I do like the way the user can tick off the dates required. It is a pity this date selection tool is not on the main import screen.
-
Do you mind me asking what tools / techniques you used to get the exif info. I am writing a small personal app as a pre-processor to Lightroom, which will allow me to copy and rename my images from my cards to disk, using my preferred file and folder naming structure. I would like to find a reliable way to get the Capture Time, so I can put the images in sub folders per year and also separate different images with different capture dates into possibly different destination folders. The Lightroom import features are lacking some basic selection criteria.
Any hints re Exif data extraction appreciated.
I wrote my own code as it runs faster. As John mentions below, you can use exiftools. If you want to do it yourself, my code is at https://github.com/towhee/Winnow64/. The metadata I pull is limited to what I need: embedded jpg locations, image dimensions, dates, shutter speed, aperture, ISO and focal length.
-
In Lr's case, the "more" is quite a bit more. It's processing the raw data, while you and PM are simply displaying the embedded JPEG. Let's compares apples with apples....
Lr is not processing raw data in the import module - it is showing the embedded JPEG. In the library, once the previews have been rendered, there is no raw processing. Extra stuff that is happening in the library module is the navigator pane update, histogram, keywords and metadata. If you are moving through images quickly Lr is smart enough not to try to generate this extra information, and just displays the preview. So John, it is actually pretty much apples to apples ...
-
I wrote my own code as it runs faster.
Thanks for the feedback and link. I am running ExifTool in Batch mode which allows me to pipe a list of files in a text file and get a single text file out with the Exif data I am interested in (mainly right now Camera Serial No, Make and Model). It is working fairly fast.
I am not sure I have what it takes to try and get the Exif data coding the extract process myself.
Thanks again.
-
Yes, you are quite right, Rory.
-
I am not sure I have what it takes to try and get the Exif data coding the extract process myself.
Thanks again.
I think you have to be a touch masochistic ;D
-
A lot of us have asked Adobe many times for an embedded preview-browsing mode, which would seem a great use of the GPU.
Maybe Tom Hogarty was serious when he said he would be listening more, "reigniting the type of dialog we started in 2006". Any sense that is happening John? I was sort of hoping someone influential would read this and take up the cause. ;D
-
Who knows? PM-speed preview browsing was the thing I most expected when I first heard GPU acceleration was being added....
-
Who knows? PM-speed preview browsing was the thing I most expected when I first heard GPU acceleration was being added....
I'm not too knowledgeable about GPU acceleration, but I'm not sure this is the solution. I think the main issue is that Adobe are not caching ahead. There is a fair amount of overhead moving memory from the CPU to the GPU. The time crunch is the amount of time to read the data from the storage medium. It is challenging to get the read time under 700ms for a 36MP file. Hence the need to cache ahead.
-
I'm not too knowledgeable about GPU acceleration, but I'm not sure this is the solution. I think the main issue is that Adobe are not caching ahead. There is a fair amount of overhead moving memory from the CPU to the GPU. The time crunch is the amount of time to read the data from the storage medium. It is challenging to get the read time under 700ms for a 36MP file. Hence the need to cache ahead.
Haven't PM always claimed that using the GPU allowed them that speed, and certainly it was said of Aperture. Providing it's PM-speed, I don't care how it's done in Library (I'm not worried about Import).
-
Haven't PM always claimed that using the GPU allowed them that speed, and certainly it was said of Aperture. Providing it's PM-speed, I don't care how it's done in Library (I'm not worried about Import).
Do you have a source for your assertion that PM uses the GPU?
-
No
-
I'm not too knowledgeable about GPU acceleration, but I'm not sure this is the solution. I think the main issue is that Adobe are not caching ahead. There is a fair amount of overhead moving memory from the CPU to the GPU. The time crunch is the amount of time to read the data from the storage medium. It is challenging to get the read time under 700ms for a 36MP file. Hence the need to cache ahead.
Very interesting thread I have to say. I can respect Rory for having to code his own app just to investigate this. That's hound dogging it. Good work, Rory.
Now some questions that aren't being asked concerning jpeg thumbnail generation in LR. For reference I just threw away an old LR catalog because it was titled "Lightroom Trail Catalog" and had to re-point LR to the "Licensed" version and now my new catalog is rebuilding all Raw thumbnails in Library module quite slowly for both xmp sidecar edited and untouched Raws.
Rory, I noticed your "Winnow" screen grab of the Nikon previews shows some very correct looking thumbnails and I'm wondering if those jpegs are color managed meaning they have an embedded profile either embedded by the camera or assigned to it by the OS/LR usually in sRGB if not tagged by the camera.
Is Winnow color managed? Maybe this is what's slowing things down in LR and not Winnow.
I have an old 2006 Pentax K100D set incamera to capture/render jpegs in AdobeRGB which will look less saturated on my sRGB display unless I embed Argb using an Apple script I can drag & drop the jpeg on the desktop because my camera does not embed the profile. I'm sure your more modern Nikon camera does this automatically to both jpeg and Raw formats.
-
Is Winnow color managed? Maybe this is what's slowing things down in LR and not Winnow.
Winnow renders based on the assigned color space. In this case, I have my Nikon set to Adobe RGB. However, I seriously doubt that has much impact on performance. By far, the most time intensive task is reading the file from the storage medium. Even on a fast SSD a 36MP file takes around 700ms to read the embedded JPEG. There are ways to speed this up if you are planning to scale the image down for a monitor size, but I want the full size image so I can zoom into 1:1. The way programs like Photo Mechanic and even Bridge speed things up is by caching ahead. I'm pretty sure Lr does not cache previews or the embedded JPEGs in the import module. In my program I run up to four separate threads: the main thread, one to read metadata, one to read and display thumbnails, and one to populate the image cache.
Running many threads is very complex in a program as complicated as Lightroom. Based on problems I have encountered where some images never fully render in the library and comments made by an adobe engineer it is likely Lr is running into a race condition. So, if Lr is already running into thread collisions that may explain why adobe has yet to turbocharge image previewing. More likely IMO, it just has not been a priority, with the performance of the develop module warranting early attention. Just my guess.
-
By far, the most time intensive task is reading the file from the storage medium.
And I'm assuming this storage medium (SSD) is internal and not off an external drive?
-
And I'm assuming this storage medium (SSD) is internal and not off an external drive?
Yes for the 700ms, which is a best case scenario. So caching becomes even more important for reading media from a camera card over USB3.
-
Rory, you know more about it than I do.
This slow thumbnail preview issue happens in Bridge as well but at least Bridge gives me the option of "Browse Quickly By Preferring Embedded Images" setting where they immediately show as low saturation, dim and fuzzy. Once I click on one of the newly transferred to HD from SD card images the ACR defaults kick in and the rest in the strip begin to slowly render the same.
In existing formerly worked on folder of images with their respective xmp edits, some are faster than others depending on Adjustment Brush, cropping, lens profile applied and spot removal. The fastest of course are those I hadn't gotten to which render with ACR defaults but even that is pretty slow and these are 6MP Raws viewed in CS5 Bridge.
I've actually located the directory that contains the jpeg previews of various sizes generated (cached) by Bridge and they all have sRGB embedded in them. They show the previews that reflect those that have been edited and those that have not. I wouldn't know how an app can keep track of that many thumbnails of various editing stages.
-
Have you tried the latest version of Bridge (6.2.0.179) Tim? I've noticed quite a boost in performance and rendering quality.
-
No, Rory, I haven't tried it.
I'm a bit burned out on upgrading image editing software. I've had to re-edit quite few of my thousands of Raws/jpegs for the third time, first with CS3, then CS5 and now LR4 with PV2012 so I'm a bit tired of it.
I can live with the thumbnail slowness. Editing is fast enough and that's what counts for me. The preview appearance at different zoom levels has been the most help in CS5. At least I can get a decent preview match between ACR 6.7 at 25% view and how it shows up in Photoshop at the same zoom level. Even my 6MP Raws viewed at 100% is difficult to get an overall look in how it downsizes for the web. And it certainly doesn't tell me how it will look on an 8x10 print.
-
I know what you mean. ;D
-
I recently built a new photo machine, also Skylake, 6700k with 32gb of RAM. 50k or so photos in my catalog, I've been pleased with Lightroom's speed upgrade with browsing now. However, I installed an M2 PCI SSD drive that has my OS on it. I moved my Lightroom catalog and previews to it as well, but the browsing was still faster than it had been when the catalog was still sitting on a standard hard drive.
-
I recently built a new photo machine, also Skylake, 6700k with 32gb of RAM. 50k or so photos in my catalog, I've been pleased with Lightroom's speed upgrade with browsing now. However, I installed an M2 PCI SSD drive that has my OS on it. I moved my Lightroom catalog and previews to it as well, but the browsing was still faster than it had been when the catalog was still sitting on a standard hard drive.
Sounds like a nice setup. What size monitor do you have and how big are your files? How about run-on, where if you hold down the forward key, the previews keep on paging after you lift the key. Try moving through images on a media card while in the import module. This is pretty basic stuff that almost every image viewer does with ease on quite moderately powered machines.
-
I'm a bit burned out on upgrading image editing software. I've had to re-edit quite few of my thousands of Raws/jpegs for the third time, first with CS3, then CS5 and now LR4 with PV2012 so I'm a bit tired of it.
Why is that? I mean: Lightroom still has PV2010 and PV2003, so photos you've finished editing still render the same as before. Why would you need to re-edit? You can still edit in those previous versions if you need further editing. I'm not sure what changed in CS3 and CS5, but again, if you've finished editing, why would you need to re-edit?
I think I'm missing something!
-
Exiv2 is the go-to library for image metadata in C++. It's not as fast as single-purpose highly tuned custom code, of course, but given how long it has been around it will surely cover far more edge cases, such as where manufacturers have encoded metadata in non-standard, surprising and short-sighted ways. Having said that Exiftool is of course the gold standard for metadata coverage and reliability.
I haven't looked at your code Rory, but based on you mentioning having 4 threads, have you considered making the exif and thumbnail extraction an asynchronous operation after the file read? In other words, one thread that simply reads from disk and pretty much nothing else, and a small pool of threads that load the metadata and render the preview image in parallel to each other. That way you max out disk io, and take advantage of multiple cores to do the heavy rendering work. That's the approach my code takes. If all you're doing is extracting the jpeg preview (and not rendering from the RAW data), you can read from only the portion of the RAW file you actually need, i.e. the metadata you want and the jpeg preview itself. Unfortunately RAW files are not necessarily consistent in where they store that information in the file (some manufacturers are worse than others), but it can be made to work. Again that's what I do with my code.
Also did you look at the FOSS code the folks behind FastRawViewer maintain? I'm not sure if their code to render actual RAW previews (not the preview) using the GPU is FOSS or not. It might be. They've certainly done a lot of work to take dcraw in new directions.
I do agree with John that we need to compare apples with apples. LR and other converters are doing much more than extracting a preview. They're also doing a lot of heavy processing work, e.g. adding sharpening.
-
Exiv2 is the go-to library for image metadata in C++
Thanks.
-
Thanks for your insight Damon. I was not aware of rapid photo downloader. Looks like a nice app and quite similar to mine in design goals. I also have a renaming feature, albeit quite rudimentary, which automatically creates a destination folder structure. I have a selection option, where you can filter the import to only the images you pick. I'm a wildlife photographer, and usually take many images of the same subject, hoping one or two will stand out. No point in importing all the loser shots.
Exiv2 is the go-to library for image metadata in C++. It's not as fast as single-purpose highly tuned custom code, of course, but given how long it has been around it will surely cover far more edge cases, such as where manufacturers have encoded metadata in non-standard, surprising and short-sighted ways. Having said that Exiftool is of course the gold standard for metadata coverage and reliability.
I tried Exiv2 but it had several problems. First, it was a royal pain getting the library to work on a PC. I never did get it to work with the 64 bit version of Qt. Second, it does not work with some unicode, and I have unicode in my metadata. Finally, this was an exercise for me to figure out how stuff works.
I haven't looked at your code Rory, but based on you mentioning having 4 threads, have you considered making the exif and thumbnail extraction an asynchronous operation after the file read? In other words, one thread that simply reads from disk and pretty much nothing else, and a small pool of threads that load the metadata and render the preview image in parallel to each other. That way you max out disk io, and take advantage of multiple cores to do the heavy rendering work. That's the approach my code takes. If all you're doing is extracting the jpeg preview (and not rendering from the RAW data), you can read from only the portion of the RAW file you actually need, i.e. the metadata you want and the jpeg preview itself. Unfortunately RAW files are not necessarily consistent in where they store that information in the file (some manufacturers are worse than others), but it can be made to work. Again that's what I do with my code.
Since reading the file is the most expensive operation, as you mention, I only read the parts I need: some metadata, the small thumbnail JPEG and the larger JPEG preview. I need to read the metadata first in order to find the small and larger JPEG data and their dimensions. I get thumbnails and the first couple of previews immediately, and then keep reading the rest to make the app as responsive as I can. Since all I am doing is displaying the JPEGs without any processing, that part goes pretty fast. I'll have to look at separating the read and the conversion to a bitmap - I had not thought about that. The only raw files I have worked on so far are NEF and CR2. If I get serious I'll likely have to go the third party route for metadata.
Also did you look at the FOSS code the folks behind FastRawViewer maintain? I'm not sure if their code to render actual RAW previews (not the preview) using the GPU is FOSS or not. It might be. They've certainly done a lot of work to take dcraw in new directions.
I'll check that out. To date I have not looked at other folks code for a couple of reasons. First I'm still learning and other code can be really hard to understand before you really know a language and the file structures - I've only been at this for 3 months and it has been one massive learning curve after another. Second, as I've mentioned, this has been a bit of a challenge for me to see if I can figure this stuff out for myself.
I do agree with John that we need to compare apples with apples. LR and other converters are doing much more than extracting a preview. They're also doing a lot of heavy processing work, e.g. adding sharpening.
Lets break this up into the import and the library preview functions.
At the import stage all they need to show is the embedded previews, which are presharpened based on your camera settings. It is pretty obvious to me that there is not any image precaching going on here. This appears to be completely apples to apples with what I am doing.
In the library I understand there is a lot of processing that occurs to create the previews. However, after the previews have been built it should be an apples to apples comparison. However, Lr is not very smart at generating the previews I want when I want them. It is not very good at fast sequential image review. It is not very good at stopping when I do.
-
Why is that? I mean: Lightroom still has PV2010 and PV2003, so photos you've finished editing still render the same as before. Why would you need to re-edit? You can still edit in those previous versions if you need further editing. I'm not sure what changed in CS3 and CS5, but again, if you've finished editing, why would you need to re-edit?
I think I'm missing something!
To be more clear the interface comprising previews and the way ALL sliders act on the preview are not intuitive and clear enough to know what to do on the next shot. I shoot under constantly changing available light, dynamic ranges and mixed color temps where each image requires changing exposure and thus different edits on an image by image basis.
Another fly in the ointment is when I've finished the image the second time in CS5 and decide to see if LR4's PV2012 can do it better, when I click the PV update button the entire image gets screwed up in both color, clarity and contrast that it's easier to just start from scratch under LR4 defaults. See image sample below. That's one of the better PV conversions, most are really bad.
Also some of the re-edits or re-visits ...(because Raw shooter proponents said to shoot Raw because Raw converter technology is constantly improving...remember that?)... are from spending more time getting more familiar with additional tools like the adjustment brush and the fact PV2010's linear exposure slider behavior by zeroing out all other sliders is something I didn't implement till later on. And that was a big improvement in getting more highlight detail.
LR4 PV2012 changed that so I had to re-learn where to get back the linearity in the other sliders. NOT SO INTUITIVE IS IT?!
-
Thanks for your insight Damon. I was not aware of rapid photo downloader. Looks like a nice app and quite similar to mine in design goals. I also have a renaming feature, albeit quite rudimentary, which automatically creates a destination folder structure. I have a selection option, where you can filter the import to only the images you pick. I'm a wildlife photographer, and usually take many images of the same subject, hoping one or two will stand out. No point in importing all the loser shots.
The only thing my app is meant to do is help you download, rename and backup. Nothing else. Users ask me for new features like adding metadata entry but I tend to say no 8)
I'm in the middle of the biggest rewrite to the code since it I first developed it, moving the code from Gtk to Qt, 0MQ for interprocess messaging, and to call libgphoto2 directly, among many other changes and feature additions. Qt does have a steep learning curve, as do 0MQ and gphoto2 (and interacting with the Linux udisks subsystem)!
Hopefully with the move to Qt and 0MQ, it will make it relatively easy for someone to port it to Mac and Windows (allowing for the fact that Windows doesn't have gphoto2). I don't use a Mac, but it seems Mac users don't have the equivalent of Rapid Photo Downloader or Breeze Systems Downloader Pro. Is that right?
I tried Exiv2 but it had several problems. First, it was a royal pain getting the library to work on a PC. I never did get it to work with the 64 bit version of Qt. Second, it does not work with some unicode, and I have unicode in my metadata. Finally, this was an exercise for me to figure out how stuff works.
The KDE folks have a package that makes exiv2 callable directly from Qt. Did you try that? I think it's called libkexiv2.
Since reading the file is the most expensive operation, as you mention, I only read the parts I need: some metadata, the small thumbnail JPEG and the larger JPEG preview. I need to read the metadata first in order to find the small and larger JPEG data and their dimensions. I get thumbnails and the first couple of previews immediately, and then keep reading the rest to make the app as responsive as I can. Since all I am doing is displaying the JPEGs without any processing, that part goes pretty fast. I'll have to look at separating the read and the conversion to a bitmap - I had not thought about that. The only raw files I have worked on so far are NEF and CR2. If I get serious I'll likely have to go the third party route for metadata.
The challenge about separating the read from the conversion is that you'd need some kind of simple load balancer to keep the workers correctly loaded. Another challenge is the shared memory. I'm not a C++ coder so I''ve no idea how it handles memory between threads, especially given you'd like to avoid expensive memory copy operations.
I wrote some code that analyzes what exiv2 reads when it loads metadata or metadata+previews from pretty much every RAW format I could get hold of. I'd have to say one or two manufacturers made some "interesting" choices regarding their format layout!
Lets break this up into the import and the library preview functions.
At the import stage all they need to show is the embedded previews, which are presharpened based on your camera settings. It is pretty obvious to me that there is not any image precaching going on here. This appears to be completely apples to apples with what I am doing.
It's interesting you should point that out, because that's the approach taken by Bibble 5 / Aftershot. Many folks here tend to look down upon that program as poor quality (and indeed its image conversion and feature set are absolutely subpar compared to LR) but I've long maintained that those guys got the performance side of things exactly right. It's simply very fast generating previews, and showing them as quickly as possible when you click on a folder full of thousands of images.
-
Sounds like a nice setup. What size monitor do you have and how big are your files? How about run-on, where if you hold down the forward key, the previews keep on paging after you lift the key. Try moving through images on a media card while in the import module. This is pretty basic stuff that almost every image viewer does with ease on quite moderately powered machines.
24 inch monitor, 14 mb files or so. And there certainly is run-on to beat the band. Haven't imported anything recently, will try it.
What I can say is the speed to sharpness of my preview image as I move through the filmstrip, even in directories I haven't been in recently, is now much faster than it was on my 7 year old Core i7, so it is somewhat tough for me commenting on the differences between modern computers.
-
One thing I can see is why Adobe chose a pyramid scheme with different preview sizes in the library. When I select a folder with 2880x1800 px jpegs my program really flies at about 30 images per second. However, when I pick 7360x4912 NEF files I'm lucky to get 8-10 frames per second and I run out of cache pretty quickly. As they say, size matters.