Lightroom: Better Develop Module Performance

  • 45
  • Idea
  • Updated 7 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
  • 117 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 8 years ago

  • 45
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 136 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
  • 114 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
  • 136 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
  • 114 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
  • 386 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
  • 114 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 TK

TK

  • 531 Posts
  • 116 Reply Likes
Thanks, Dan!
Photo of MarcusT

MarcusT

  • 48 Posts
  • 7 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

  • 48 Posts
  • 7 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

  • 48 Posts
  • 7 Reply Likes
Thanks! And I shall try!
Photo of MarcusT

MarcusT

  • 48 Posts
  • 7 Reply Likes
+1 for (perceived) performance optimizing the Develop module
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 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 Rob Cole

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
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
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 Reply Likes
So I'm editing a jpg render or am I rendered a subsampled RAW?
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
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.
Photo of seanhoyt-dot-art

seanhoyt-dot-art

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

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
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
Photo of Dan Tull

Dan Tull, Employee

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

seanhoyt-dot-art

  • 315 Posts
  • 51 Reply Likes
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?
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
|> " Most likely it is grounded in a (somewhat puritanical) mindset of ensuring Develop view only shows 100% genuine pixels or somesuch."

I can't help but think a part of the reason is that Lr's dev module is essentially a thin veneer over the same ACR used in Photoshop (which does not share the code to access Lr's previews...). So, there may be a ACR code-sharing thing too... - just guessing.

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

Could the name be: "fast-load data"? My experience: marginal improvement. about the same amount as ACR cache (~15% faster), making me think it is just housing the ACR-cache data internally. Again, this is speculation, albeit based on experience...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
|> " I'll give the DNG a try..."

My experience: raw DNGs (w/fast-load data) load for develop no faster than raw NEFs (with ACR cache entry). But, that's just one data point. Please do report back after you try it.

|> " I had tried it in prior versions but found a ton of DNG corruption across a year's worth of work files..."

That's disturbing. Do you have any idea what caused this? Were they stored on optical media or a wonky disk or something? (it's very rare for corruption to be caused by Lr writing the DNGs).

Rob
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 Reply Likes
The DNGs were stored on a Drobo so stored redundantly on many disks at once.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
So, any idea what caused the corruption? - any reason to believe if you try again the same thing won't happen again?...
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 Reply Likes
I'm going to try DNG again. I back up my 'virgin' NEF files to backblaze cloud and blu-ray before touching them in Lightroom.
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 Reply Likes
I concur with Rob-- the DNG development responsiveness was no faster than NEF. In fact, I am seeing a similar delay with JPG development...

Camera: 16MP Nikon D4
Computer: Mac Pro 2010, 3.33GHz 6-core, 24GB RAM, Catalog on 240 OWC Extreme SSD (550 read/write uncompressed sequential on PCIe 6G SATA), images on 3TB Seagate Barracuda (150 read/write)

Full screen 2560x1440, just dev panel open about 350px wide on right, same 11 horizontal images
NEF = 1.3, 1.5, 1.3, 1.4, 1.3. 1.6, 1.4, 1.4, 1.3, 1.5, 1.5
JPG = 1.2, 2.3, 1.6, 2.0, 1.6, 1.9, 1.9, 1.8, 1.9, 1.8, 1.8
DNG = 1.4, 1.7, 1.9, 2.0, 2.3, 3.1, 2.2, 4.2, 2.3, 1.9, 1.9

So, DNG is actually a bit slower on my system (some cases much slower). DNG also continues to render the image while the sliders are available contributing to feedback lag between slider adjustment and image adjustment.

Now, compare that to a 1:1 cache pull in the Library module which is pretty much 0.1 seconds from sharp render to the next sharp render. Dan, I'm not seeing why a 1:1 jpg render in cache isn't the same as the Development Module render that's presented. What's the difference? I don't see any compression artifacts in either. I really, really want a preferences option to allow me to bypass that re-render. What about an option for those of us that could stuff 64-128GB of ram in our system to preload all of the NEF/DNG/JPG files into RAM? Wouldn't that make Lightroom fly?
Photo of Dan Tull

Dan Tull, Employee

  • 172 Posts
  • 38 Reply Likes
The Library case just has to scoop the bits off disk, decompress the JPEG, and blit assuming the preview is up to date.

The Develop case is actually grabbing the raw data (possibly short circuiting the early stages of the pipeline via the ACR cache, though that's not usually a huge savings, honestly) and performing the render right at that moment.

At your screen resolution, it's probably using the 1:1 pyramid level, too, which means any sharpening and noise reduction settings are more expensive to boot. Having now seen your resolution info now, I'm not too surprised that the DNG fast load isn't helping (sorry I didn't reply soon enough to save you the DNG experiment). That preview is capped at 2K on the long edge, IIRC, so in your case it's probably falling back to doing a full render anyway.

There's another DNG load speed boost, but it only applies if you're reading them from a really fast disk (striped 10K raptors fast) and have lots of cores, but I got some mixed results if I varied the setup at all (it didn't work very well on Windows, either for whatever reason) and ran that experiment quite some time ago, so I wouldn't bank on that one, either.

The scenarios that might be interesting to compare would be:
- what's the load time if the images are on a faster disk?
- what's the load time if the images have default settings (no sharpening or noise reduction, especially)?
- what's the load time if you reduce your window size so that the on screen display is less than 1/4 of the total resolution of the image?

The latter two would indicate the problem is bound by the rendering, the former indicates that I/O is holding you up.
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 Reply Likes
I moved 10 NEF files to my SSD which has a sequential, uncompressed read of about 500MB/s. Extremely fast drive, same or faster than a striped array of raptors especially with non-sequential stuff. No difference in the delay. This is all CPU bound. It does render faster with smaller screen sizes in both cases (SSD & 3TB barracuda spinning disk)

But I had another question before: 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? Is it a DNG versus a JPG? more data?

I'm basically asking this stuff because I do about 30 jobs a year that require 2,000-3,000 photos each so probably 100,000 images per year when you add in odd jobs. If there could be a way (LR 5) for me to queue up some job to build out these renders while I sleep so I can skip them while I edit, that would be HUGE time savings. That's what I do now for the 1:1 in the Library module for pruning, but you are alluding that this 1:1 cache build is ignored for some good reason when I hit the Develop module. I don't see why but I'm ignorant on the mechanics here.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
Thanks Dan, for participating and informing...

I have found that the time from selecting the next image (when not in negative/ram cache) until sliders enabled depends more on resolution than format, whereas time from sliders enabled until loading indicator extinguished depends more on format. This is in agreement with Sean's report above.

After my initial experiments with "fast-loading" DNG, (when I didn't know it was possible to reduce the resolution and still maintain raw editing characteristics), I abandoned the EditInLightroom project, since it wasn't helping with the most critical lag (time until sliders enabled). Moral of the story - it was the resolution drop that helps enable those sliders more quickly.

|> " If there could be a way for me to queue up some job to build out these renders while I sleep so I can skip them while I edit, that would be HUGE time savings."

This is precisely what EditInLightroom allows you to do (granted, you lose the ability to zoom 1:1). Is it not helping? Or, are you simply asking Adobe for similar help, built-in & smooth...

Rob
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 Reply Likes
Adobe should have something similar, built-in & transparent to the user. At normal screen res, show me a proxy that's optimized for my workspace. If I zoom in, pull up the RAW and give me more res. By the time I'm in the Dev module, I've already made my picks so I don't actually do much pixel peeping at that stage. Others might, but that might be a flaw in their workflow. I've advocated face detection for intelligent 1:1 zooms, too. If this was applied, Lightroom could zoom in on the faces (not ID the faces, just ID that they are faces) and show me that subsample'd region of the raw, not the full raw with panning. Right?

Your software is brilliant. I used it on about 50 images, but the conversion back to hi-res didn't load the data. I had to manually load it. Also, I don't see that flags sync meaning that I can't do further filtering while developing my files which is quite frequent. Also, on the Hi->Lo, I get a LR dialog for each selected file saying "Lightroom is concerned". So, for a 2k set, you can imagine that not working out too well. I'm probably not doing it right, though.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
Sean,

I couldn't agree more - improvement should be built-in. But, seeing as we've now gone over half a decade without such improvement, it seems worthwhile to consider workarounds for the mean time. It might be another half decade before Lr has such improvement... Anyway, many plugins that push the envelope require some reading of "the fine print" too. But if your originals were DNG, then 'Update DNG Previews & Metadata" should trigger Lightroom to re-apply the lo-rez settings to the hi-rez version (along with flags...), after invoking the 'Edit Hi-Rez' plugin command.

Anyway, feel free to contact me outside the forum for plugin support.

Rob
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 Reply Likes
I'm not certain about that timeframe.... At it's present incarnation, I could use Lightroom for 20 years. CPUs will become more powerful and the image files will become more detailed, but the functionality is pretty much there barring some cool trick tools. So, this is a perfect time to focus purely on optimizations and rethink and improve the engine.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
You're preaching to the choir (although I have a voracious appetite for some cool trick tools too). And, Adobe has heard you too, even if they don't respond. But it's going to be at least a year or so, at the earliest, and maybe longer, so it may be worth considering a strategy for the mean time. PS - I'm now guessing you were using EditInLightroom with proprietary raws (right?), - try with DNGs - it's smoother. PPS - Don't forget to check that "Don't show again" box when you've seen a prompt as much as you care to ;-}.
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 Reply Likes
Well, how about the strategy of me driving down the street and knocking on their door? I live about 2 miles away from their office....
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 387 Reply Likes
I doubt they will be more likely to accelerate development in response to the personal nature of your visit - could be wrong. Got a plan B?
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 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
  • 387 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
  • 117 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 seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 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
  • 117 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 seanhoyt-dot-art

seanhoyt-dot-art

  • 315 Posts
  • 51 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
  • 387 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.