P: Better Develop Module Performance

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.