Lightroom: Better Develop Module Performance

  • 45
  • Idea
  • Updated 6 years ago
  • Implemented
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.
Photo of TK

TK

  • 531 Posts
  • 110 Reply Likes
  • confident that the team can get better Develop module editing performance if they set their mind to it and are allowed to make this a priority. Until then, the jerky updates in full screen mode are frustrating.

Posted 7 years ago

  • 45
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
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. "
Photo of TK

TK

  • 531 Posts
  • 110 Reply Likes
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.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
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.
Photo of TK

TK

  • 531 Posts
  • 110 Reply Likes
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. :)
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
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.
Photo of TK

TK

  • 531 Posts
  • 110 Reply Likes
Yes, at least there should be an option not to have it on the image.
Photo of Dan Tull

Dan Tull, Employee

  • 172 Posts
  • 38 Reply Likes
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.
Photo of MarcusT

MarcusT

  • 33 Posts
  • 6 Reply Likes
Any news for us regarding performance optimizing the Develop and/or Library modules, Dan? :)
Photo of Dan Tull

Dan Tull, Employee

  • 172 Posts
  • 38 Reply Likes
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.
Photo of MarcusT

MarcusT

  • 33 Posts
  • 6 Reply Likes
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?
Photo of Dan Tull

Dan Tull, Employee

  • 172 Posts
  • 38 Reply Likes
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)
Photo of MarcusT

MarcusT

  • 33 Posts
  • 6 Reply Likes
Thanks! And I shall try!
Photo of MarcusT

MarcusT

  • 33 Posts
  • 6 Reply Likes
+1 for (perceived) performance optimizing the Develop module
Photo of sean

sean

  • 266 Posts
  • 44 Reply Likes
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?
Photo of sean

sean

  • 266 Posts
  • 44 Reply Likes
It's Seattle, I'd bring coffee and Top Pot Donuts for the whole office.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
Those must be some killer donuts ;-}.

I'd still like to talk with you about your experience using EditInLightroom. Even if you've given up already, it may help to improve it so others can use it successfully.

http://forums.adobe.com/people/areohbee

Cheers,
Rob
Photo of Dan Tull

Dan Tull, Employee

  • 172 Posts
  • 38 Reply Likes
Almost lost the other question in all the noise (though I will note there aren't many folks in Seattle in a position to affect Lightroom Develop module performance regardless of bribery or threats ;o).

Anyway, getting back to the question for me before this thread ran off: "What's the difference between the ACR cache version of the raw file that I made in the Library module and the render version that gets made when I choose the raw file in the Develop module?" The difference is that the Library module is loading a fully rendered JPEG of the raw with settings applied. The ACR Cache doesn't store fully rendered previews so it still has to do the actual rendering work.

The cache does allow ACR to skip some expensive work toward the beginning of its pipeline, but the rest is done when the image is opened. Note also that previews are rendered into a color space that may not produce precisely the same results as you'll see on screen in Develop (which works in a wider gamut space, IIRC), so those previews aren't suitable for use in Develop. Lastly, the moment you actually started to move a control, ACR would have to do the setup and rendering anyway, so using a fast preview would just kick the can a bit further down the road, so to speak. It was viewed as better to delay enabling the controls and be responsive when they were used than to enable immediately and have them be initially sluggish.

That's not to say it couldn't be made faster, only that there are reasons for why it works as it does at the moment, so it's probably not simple or trivial to make it faster to load. Hopefully that's illuminating or at least helpful.
Photo of TK

TK

  • 531 Posts
  • 110 Reply Likes
Dan, you write "...so using a fast preview would just kick the can a bit further down the road, so to speak. It was viewed as better to delay enabling the controls".

The advantage of kicking the can further down the road would be that one could stay in the Develop module when navigating between images.

Partly due to preview caches not being handled properly, navigating in the Develop module can be painful to the extent that I sometimes switch to the library module to locate an image (or force an update to the Develop module previews) and then switch back again.

AFAIC, it should never be necessary to leave the Develop module just because one wants to quickly flick through some images, to compare them or chose the next one for editing.
Photo of sean

sean

  • 266 Posts
  • 44 Reply Likes
Dan, thanks for clearing that up. I really do appreciate the time you are taking to clue us in.

For those of us that prioritize performance over precision [a huge group I'd imagine], I would love the 1:1 previews to be initially in a color space appropriate for the Develop module. Why not? It's simple matrix math, eh?

TK is spot on, too. The reason I desire the quick preview and slider access is for those images that I don't even want to adjust. I've already applied the adjustments upon ingestion (sharpening/contrast/fill/highlight) and the 1:1 previews are either good or very close.

For one job, I prune down to 1000 images in the Library module. When I step into the Develop module, that's 1500-2000 seconds of pure render delay. That's 30 minutes per job times 30 jobs = 900 minutes per year [15 hours] (on the low end) I'm taping my finger while LR is rendering before I can determine I I simply want to move to the next photo. Let me state that again: that's 15 hours regardless if I want to make an adjustment or just move to the next photo. And, that's with my 6-core 3.33GHz machine. Most of my peers are using much slower machines.

So, pulling from the 1:1 versus the re-render would be one potent kicking of the can in my case.
Photo of TK

TK

  • 531 Posts
  • 110 Reply Likes
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.
Photo of sean

sean

  • 266 Posts
  • 44 Reply Likes
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.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 384 Reply Likes
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.