Topic: Lightroom preview performance mini-rant (Read 9421 times)

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.

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.

rdonson · « **Reply #1 on:** February 17, 2016, 03:34:50 pm »

You wrote this in C++. right? I believe Lightroom is written in Lua, a VM with a JIT.

Rory · « **Reply #2 on:** February 17, 2016, 03:36:36 pm »

Quote from: rdonson on February 17, 2016, 03:34:50 pm

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++.

rdonson · « **Reply #3 on:** February 17, 2016, 04:01:34 pm »

http://www.troygaul.com/LrExposedC4.html

Perhaps a bit dated but...

Rory · « **Reply #4 on:** February 17, 2016, 04:58:51 pm »

Quote from: rdonson on February 17, 2016, 04:01:34 pm

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 ...

rdonson · « **Reply #5 on:** February 17, 2016, 08:01:21 pm »

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.

Rory · « **Reply #6 on:** February 17, 2016, 10:15:58 pm »

I think you are right about the mobile.

stingray · « **Reply #7 on:** February 18, 2016, 04:01:05 am »

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.

john beardsworth · « **Reply #8 on:** February 18, 2016, 04:29:44 am »

Quote from: Rory on February 17, 2016, 03:18:38 pm

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....

Quote from: Rory on February 17, 2016, 04:58:51 pm

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

john beardsworth · « **Reply #9 on:** February 18, 2016, 04:37:01 am »

Quote from: stingray on February 18, 2016, 04:01:05 am

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".

Quote from: stingray on February 18, 2016, 04:01:05 am

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.

stingray · « **Reply #10 on:** February 18, 2016, 04:51:53 am »

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.

john beardsworth · « **Reply #11 on:** February 18, 2016, 05:16:37 am »

Quote from: stingray on February 18, 2016, 04:51:53 am

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.

stingray · « **Reply #12 on:** February 18, 2016, 06:29:03 am »

Quote

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.

Rory · « **Reply #13 on:** February 18, 2016, 09:51:23 am »

Quote from: stingray on February 18, 2016, 04:01:05 am

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.

Rory · « **Reply #14 on:** February 18, 2016, 10:02:23 am »

Quote from: john beardsworth on February 18, 2016, 04:29:44 am

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 ...

stingray · « **Reply #15 on:** February 18, 2016, 10:05:38 am »

Quote

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.

john beardsworth · « **Reply #16 on:** February 18, 2016, 10:10:04 am »

Yes, you are quite right, Rory.

Rory · « **Reply #17 on:** February 18, 2016, 10:10:28 am »

Quote from: stingray on February 18, 2016, 10:05:38 am

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

Rory · « **Reply #18 on:** February 18, 2016, 10:17:17 am »

Quote from: john beardsworth on February 18, 2016, 04:29:44 am

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.

john beardsworth · « **Reply #19 on:** February 18, 2016, 10:28:45 am »

Who knows? PM-speed preview browsing was the thing I most expected when I first heard GPU acceleration was being added....

Author Topic: Lightroom preview performance mini-rant (Read 9421 times)