Lightroom: Better Develop Module Performance

45 Votes
LEGEND ,
May 22, 2011 May 22, 2011

Copy link to clipboard

Copied

On my machine (DELL E6400) adjusting the exposure of an image in the Develop module is more difficult than it should be because of the time lag between moving the slider and the image update.

I suggest a different strategy for generating visual feedback that yields better immediate performance, possibly trading in slight inaccuracies at first, but within a scheme that resolves the latter as soon as possible. Please see the end of this FR for the actual suggestion; I'd like to motivate it first.

It appears that the fixed order in which image operations are applied in the LR pipeline causes some adjustments to result in worse interactivity than necessary. Adjusting the exposure with no other (not even default) image adjustment settings is quick.

With some other image adjustments in place, however -- in particular when using the "Details" panel -- adjusting exposure results in jerky image updates that make it hard to find the correct level accurately and quickly.

I'm assuming that the LR image pipeline mandates that exposure updates happen relatively early, so that sharpening etc. always has to be recomputed after an exposure update. This is why updating the exposure is quick when no other adjustments have to be performed but slow otherwise.

Just to make sure that I'm making the correct assumptions, here's how I arrived at my conclusions:

My initial issue was that updates to the image in the Develop modules seemed to be slow and jerky in full screen mode whereas they were quick and led to smooth updates when I used LR in window mode. It turned out that the deciding factor is the size of the image. Images in portrait orientation are naturally displayed smaller and are less affected by the performance problems. Even images in landscape orientation can show smooth updates in full screen mode, if one artificially decreases their size by making the left hand side panels as wide as possible.

So it seems to me that:
a) LR struggles to deliver a decent image update frequency in the Develop module when the image is above a certain size (at least on my hardware).
b) This performance issue is a problem not only for computation intensive operations, like lens correction, but for simple ones like "exposure" because apparently potentially computation intensive operations, e.g., sharpening/noise reduction, come after exposure in the pipeline and have to be redone after each exposure update.
c) This is a big problem since I'd like to be able to apply some default sharpening on import (or even lens correction for some lenses) and not delay such settings after I have done other image adjustments in the Develop module.

It is clear to me that the user should not be forced to perform edits in a certain order (in addition to the aforementioned problems there is also a common advice to put off spot removals or lens corrections till the end) in order to address LR performance issues.

Here's the actual suggestion:

Could LR not cache all previous adjustments and apply the current image adjustment (e.g., exposure) as the last update in a relative manner?

I realise that this goes against the fixed ordering of the pipeline, but the latter is the problem causing the performance issues. When image operations are commutative they should be applied in the order which provides the best performance (with the use of caching, of course).

I also realise that some image operations (e.g., sharpening and exposure) only seem commutative but may not be completely commutative. It may matter (slightly) whether sharpening or exposure adjustments is performed first. Nevertheless, for the initial visual feedback, it should suffice in most cases to perform the current adjustment as the last and thus be able to capitalise on prior image caching.

Once the user stopped doing the adjustment, i.e., once there is no need to provide immediate visual feedback anymore, LR could recompute the current image using the standard image pipeline ordering. This may in some cases cause a subsequent, subtle change to the image after a short while, but I strongly believe I would prefer that if it meant that my current adjustments would just be a small delta to previous adjustments causing smooth updates rather than causing (almost?) the whole pipeline to be re-triggered.

Note that the proposed scheme would address the concerns regarding inaccurate image renderings in the Develop module. Noise reduction could always be performed, at all magnification levels, if it only impeded the speed of the final rendering -- after direct interactivity is no longer needed -- but would not impact on the interactivity of image adjustments that become before noise reduction in the image pipeline.

The proposed approach may even mean that using the adjustment brush on images with a high number of edits (including a multitude of previous brush strokes) may become more interactive. Currently, the lag between moving the mouse cursor and seeing the effect of the brush, becomes larger the more edits an image has. This may just point to caching potential regarding brushes (I hope not all strokes are always redrawn), but may also be related to the pipeline issue.
Idea Released

Views

31

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
45 Comments
Mentor ,
May 22, 2011 May 22, 2011

Copy link to clipboard

Copied

Since I liked the idea from another of your threads, and since it's related, I'm quoting that section (from Rob Cole) here:

"the dev module (or any other module) simply shows the best it can, until it computes something better, with an indicator, so the user knows if max quality has been achieved yet... In other other words, I want it as fast as possible at first, but as good as possible as soon as possible afterward, and to know what I'm looking at as this happens. "

Votes

Translate

Translate

Report

Report
LEGEND ,
May 22, 2011 May 22, 2011

Copy link to clipboard

Copied

Thanks, Lee Jay. I was just contemplating whether I should add that part. Rob's suggestion to always display a "best effort" until a better effort has become available is a very good approach that extends to interactive updates to an image in the Develop module.

Votes

Translate

Translate

Report

Report
Contributor ,
May 22, 2011 May 22, 2011

Copy link to clipboard

Copied

I won't speak to the specific details around how hard it would (or wouldn't) be to achieve this goal or the best approach, I am 100% in favor of the general thrust of the request.

Votes

Translate

Translate

Report

Report
LEGEND ,
May 22, 2011 May 22, 2011

Copy link to clipboard

Copied

Thanks, Dan!

Votes

Translate

Translate

Report

Report
Mentor ,
May 22, 2011 May 22, 2011

Copy link to clipboard

Copied

I have a suggestion on an indicator:

Red: Change to metadata, no re-render yet available.
Yellow: A new render has been made, but it's not the best possible render (i.e. all intermediate steps between red and green).
Green: The best possible render.

Votes

Translate

Translate

Report

Report
LEGEND ,
May 23, 2011 May 23, 2011

Copy link to clipboard

Copied

I guess the indicator could also be a progress bar. It would have a more positive connotation (things are in progress) compared to a signal going through colour states (which has more a touch of a warning).

Whatever the indicator might take, I think it should be visually insignificant. It should provide information for those who want to check, but shouldn't distract for those who are focusing on the image. I therefore think that colours should probably be avoided; I like that the LR UI provides very little distractions and any colours are very subdued.

AFAIC, the indicator part is optional, i.e., I don't think it is essential and if it is provided, it should be possible to turn off, just like the "Image Loading..." messages. It has more value than the "Image Loading..." message so ideally it would be possible to choose between "off" and "visually insignificant" (e.g., a very thin progress bar), but on the whole I wouldn't terribly mind if it weren't provided at all.

I work on a laptop so often the harddisk LED is an ever present "work in progress" indicator. 🙂

Votes

Translate

Translate

Report

Report
LEGEND ,
May 23, 2011 May 23, 2011

Copy link to clipboard

Copied

I tend to agree that colors might be a bit distracting. Whatever the indicator is, I hope it's not put on the image itself.

Votes

Translate

Translate

Report

Report
LEGEND ,
May 26, 2011 May 26, 2011

Copy link to clipboard

Copied

Yes, at least there should be an option not to have it on the image.

Votes

Translate

Translate

Report

Report
Participant ,
Jan 16, 2012 Jan 16, 2012

Copy link to clipboard

Copied

+1 for (perceived) performance optimizing the Develop module

Votes

Translate

Translate

Report

Report
Participant ,
Jan 16, 2012 Jan 16, 2012

Copy link to clipboard

Copied

Any news for us regarding performance optimizing the Develop and/or Library modules, Dan? 🙂

Votes

Translate

Translate

Report

Report
Contributor ,
Jan 17, 2012 Jan 17, 2012

Copy link to clipboard

Copied

Unfortunately, no. This release was eaten by a pack of hungry features. I think there were a couple of performance tweaks put into 4.0 that weren't also put into 3.x to tune things up, but nothing that'd be easy to call out.

Also, the 2012 process version still has some kinks to work out and overall will probably be a little more CPU hungry in order to do its magic on photos.

Votes

Translate

Translate

Report

Report
Participant ,
Jan 17, 2012 Jan 17, 2012

Copy link to clipboard

Copied

Thanks for your reply Dan, the focus on new stuff is understandable but of course it's rather disappointing that LR4 is likely to end up slower overall rather than faster... is there any chance you could make a case internally for devoting significant attention to performance optimizing the LR4.1/4.2 releases?

Votes

Translate

Translate

Report

Report
Contributor ,
Jan 17, 2012 Jan 17, 2012

Copy link to clipboard

Copied

I'll do what I can. In the meantime, encourage those of like minds to cast their votes to push this topic higher on the leaderboard. :o)

Votes

Translate

Translate

Report

Report
Participant ,
Jan 17, 2012 Jan 17, 2012

Copy link to clipboard

Copied

Thanks! And I shall try!

Votes

Translate

Translate

Report

Report
Contributor ,
Oct 08, 2012 Oct 08, 2012

Copy link to clipboard

Copied

Along the same lines, Dan, is it possible to speed up the initial view in the Development Module? In the Library module, I can step through 1:1 prerendered images quite fast, yet when you move to the Dev module, there's a severe reload/rerender penalty. (3-5 seconds on my 6-core 3.33 xeon, SSD, 24GB ram). Extrapolate that delay over tens of thousands of images per year and you can see how this very point is the bottleneck in my image processing workflow. Is there a reason the 1:1 isn't pulled up for the initial view in the Development module prior to any slider adjustments? Why aren't the sliders immediately available?

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 08, 2012 Oct 08, 2012

Copy link to clipboard

Copied

One option for the meantime, use:

EditInLightroom - allows one to edit lo-rez (pre-rendered) version of hi-rez raw files, much more quickly. (Settings to be applied to hi-rez version too, except you don't have to wait for reload/raw-rendering in dev module).

Rob

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 08, 2012 Oct 08, 2012

Copy link to clipboard

Copied

Related to Sean's comment, I'm frustrated by LR 3.6's failure to properly manage previews in the Develop module.

When I edit a series of images in the Develop module and then navigate back and forth between them, the preview always shows the unedited versions first. Very annoying! It makes a quick comparison between two edit images impossible because the display of the final versions is always interrupted by displays of the original versions.

In order to fix the above, I have to go to the Library module and flick through the respective images. After I've done that, previews in the Develop module will be shown correctly immediately.

I cannot say whether the annoying behaviour still exists in LR4. I haven't upgraded because I do not appreciate the philosophy behind the LR 4 basic panel controls and there was not sufficient added value overall. Maybe I'll upgrade to LR 5 but I'm currently planning to give LR4 a miss unless it is suddenly reported to have become a performance miracle.

Votes

Translate

Translate

Report

Report
Contributor ,
Oct 08, 2012 Oct 08, 2012

Copy link to clipboard

Copied

So I'm editing a jpg render or am I rendered a subsampled RAW?

Votes

Translate

Translate

Report

Report
Contributor ,
Oct 08, 2012 Oct 08, 2012

Copy link to clipboard

Copied

I don't experience this issue nor can I remember ever having this issue in versions 2,3,4... I upgraded to LR4 and find the highlight recovery worth it by itself.

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 08, 2012 Oct 08, 2012

Copy link to clipboard

Copied

You are editing a lossy-compressed reduced-rez DNG.

You can learn more about that be reading the newly released DNG 1.4 spec.

In a nutshell, raw data is demosaiced, subsampled, and then compressed using jpeg compression, and packaged in a DNG that maintains all of the editing characteristics of the original raw, except loads & renders faster...

So the answer to your question is: "both", and/or "neither", depending on how you look at it... Perhaps somebody who understands the underlying technology better, could give you a better answer. But bottom line is, unless you zoom in and/or check resolution, you can't tell which one you are editing.

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 08, 2012 Oct 08, 2012

Copy link to clipboard

Copied

In my opinion, Lr4 was as big a leap over Lr3, as Lr3 was over Lr2, image-quality-wise, maybe even more-so, since Lr3 improvement was mostly in the finer details (e.g. mostly evident at 100% zoom), whereas Lr4 improvement is more evident across the board, even in condensed views. YMMV... - it has a definite personality which took me a long time to get used to - I'm talking about end-result as well as what it takes to get there.

Votes

Translate

Translate

Report

Report
Contributor ,
Oct 08, 2012 Oct 08, 2012

Copy link to clipboard

Copied

Something like this MUST be integrated. I feel like so much time in LR is me instantly seeing the need for an image fix (5,10,15 things) and waiting around for the UI to let me do it. It's 2012. It's time for some minority report like image editing if you know what I mean. LR5 should be a pure performance upgrade. Take out Maps, take out Books and let my 6-cores chew this software up.

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 09, 2012 Oct 09, 2012

Copy link to clipboard

Copied

Sean,

I couldn't agree more. The data that persists in honor of develop edit needs, is, lacking (ACR cache entries, (aka fast-load data if you're a DNG'r), are only marginally helpful). I'm not sure why, with the ingenious invention of the lossy-compressed reduced-rez DNG technology, Adobe didn't just gut the existing ACR cache technology and replace it with the jpeg-compressed raw data, maybe an option for how much reduced-rez. That way, one could always edit raws quickly. Follow-up with rendering the full-size/quality raw in the background, and caching that in RAM, (or temp-storage on disk) for instant access, and you'd be able to prepare for edit in subsecond times, instead of multi-second times. And that's just what this outsider can see. Probably Adobe could come up with something better - e.g. instant editing, always. - if they set their mind to it.

I like to think Adobe did what they could, and the reason there were virtually no changes to lib module, or dev performance, is because Adobe has some extensive redesign in store for Lr5, and so they didn't want to invest a bunch in code that was just going to be redone anyway. But don't start any rumours - I know nuthing...

Cheers,
Rob

Votes

Translate

Translate

Report

Report
Contributor ,
Oct 09, 2012 Oct 09, 2012

Copy link to clipboard

Copied

In answer to the original question, I'm sure there are ways to speed up the loading time. I don't remember off hand the original reasons for the hard line drawn between previews used in Library and Develop adjustment view. Most likely it is grounded in a (somewhat puritanical) mindset of ensuring Develop view only shows 100% genuine pixels or somesuch. I do know that DNG files created with more recent versions of Lightroom embed a proxy preview (I don't recall the name) that can accelerate Develop view loading significantly. The times you're describing (in combination with your high powered hardware) make me think there's some additional issue making the render time abnormally bad. Do you apply a default preset with dust spot corrections or extra sharpening that might take a long time to render? Also, do you have a multi-monitor or high resolution setup that might be causing it to do 1:1 or multiple renders when it loads? Just curious.

Votes

Translate

Translate

Report

Report
Contributor ,
Oct 09, 2012 Oct 09, 2012

Copy link to clipboard

Copied

I do have a preset applied at ingestion. It boosts contrast a bit and adds shadow, reduces highlights, bumps sharpening. I do this so that the 1:1s are somewhat close when I do my first pass purging in the Library module. I'm working off of a 27" 2560x1440 monitor. I'll give the DNG a try. I had tried it in prior versions but found a ton of DNG corruption across a year's worth of work files so I reverted to using the native NEF. Maybe there could be an option for purity versus performance?

Votes

Translate

Translate

Report

Report