P: Allow Selection of Fast (current) or Accurate Rendering in the Develop Module

[FeedbackCommunityMember]

Lightroom preferences should contain an option to enable the user to choose between "fast (but inaccurate)" and "accurate (but slower)" renderings in the Develop module. Currently, the setting is hardwired to "fast (but inaccurate)". The user should be given the choice of trading in speed for a better rendering (the latter is available in the Library module).

Some image operations (only noise reduction or more?) are not performed in the Develop module unless the magnification is 1:1. This means that at lower magnifications (such as "Fit"), one often sees grainy areas (such as grainy skies, when one has applied drastic HSL controls and/or the image has been pushed in exposure) which are shown to actually be smooth (e.g., due to activated chroma noise reduction) when one zooms in to 1:1. The graininess seems exaggerated in the sense that a normal downscaling of the noisy image to a "Fit" size should not show such course blotches of heavy grain, but something smoother. I find the resulting renderings very distracting and they make it hard to judge whether the overall colour of the blotchy area is as desired or not.

I agree that adjustments to sharpening levels, noise reduction, etc. should be made while looking at a 1:1 view. However, there should be a way to judge one's editing efforts on a downscaled image as well. Images are not always printed but sometimes just edited to be shown as downscaled versions, e.g., on the web.

I do not think that it is acceptable to be forced to go the the Library module to get a reasonable downscaled rendering of the current edits. It doesn't even make sense that the Library module shows a more accurate downscaled version of the 1:1 view than the Develop module. If anything, it should be the other way round as it would be excusable to lose accuracy in favour of speed while browsing (Library). However, the image editing activity (Develop) should always be supported with the best possible preview, no matter the magnification.

Ideally, this feature request would lead to the removal of any differences between renderings independently of the module in which they are displayed.

I do not only see differences regarding chroma noise reduction (resulting in Develop module views that are ugly in parts) but also in highlight rendering. There are quite non-subtle differences (regarding colour and extent) in how some highly saturated red/orange/yellow highlights are shown between the Library and the Develop module views.
Victoria Bampton has indicated that a bug is causing this behaviour.

The user should not wonder about which of several different renderings is the "correct" one, i.e., one that is closest to what an exported, downscaled image would look like. Will the latter look like in the Develop module, the Library module, or yet another way?

Summarizing, unless a user intentionally opts for faster, but inaccurate, renderings, they should be given the best possible rendering (which includes sharpening after downscaling) at any magnification. This should be true for all modules but in particular the Develop module should support this mode.

Ideally there would be a quick way (e.g., a keyboard shortcut, or a switch in the Develop module) to change the "fast" vs "accurate" rendering behaviour so that one may toggle between them, should the "fast" version be accurate enough for a particular set of images.

I had formulated this feature request as a bug report before, but is has been argued that the current behaviour ("fast but inaccurate") is "as designed" and hence, technically, there is no bug.

[areohbee]

I'm in for the spirit of this request, although I would prefer it if the user was kept out of the loop. In other words, rather than an option or a switch or a mode, that 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.

[FeedbackCommunityMember]

Rob, in principle, I agree. However note that producing yet a better rendering requires computing resources which may get in the way of a user wanting to have the best interactive performance with an image adjustment. Perhaps the background process that creates the next better rendering could be aborted once a user interaction is detected.

Furthermore, I suggest that any indicator is placed outside the image. I switched off the "Image loading..." indicator because it obstructs my view on the image (and I don't really need it).

[areohbee]

TK - First: how do you switch off the Loading indicator - I couldn't figure out how to do that last times I tried. Second, I totally agree that all indicators and info should be kept off the image proper - I consider the image to be sacred! - no info, no indicators... Third, the software could and hopefully would be written in such a way that the higher-quality rendering would not interfere with interactivity. If not, then... - dont know how to finish that sentence: we're all just doin' the best we can with what we have to work with...

[Mark Sirota]

There's another difference between Library and Develop that you guys aren't including -- Library previews (also used in other modules) are subject to JPEG compression, and in some cases you can see compression artifacts. This is one of the leading causes of differences in rendering between Library and Develop.

[FeedbackCommunityMember]

Rob, go to the Library View Options (Ctrl-J in the Library module). Select "Loupe View". At the bottom, there is a checkbox for the "Loading Image..." indicator.

I agree with everything you said.

[areohbee]

Thanks TK.
-R

[FeedbackCommunityMember]

Victoria Bampton made some very good suggestions regarding implementation details for this feature request.

[Victoria Bampton LR Queen]

As Mark said, there will always be some difference between Library and Develop, but I completely agree there should be a way of showing a more accurate preview in Develop, with the NR applied to smaller views. Obviously it'll never be a perfect preview at less than 1:1 because things like Grain render differently at different sizes, but the lack of noise reduction particularly can be very distracting.

There would be a performance hit in showing full processing at less than 1:1 view, so I believe the default should stay as it is, but there should be an option to show the preview with the NR applied too.

A visual indicator like the Process Version icon and a shortcut key to render the preview properly would enhance the current implementation for me - would that be enough to solve the problem for everyone else, or do you feel you need a global option to turn it on for all photos?

[areohbee]

Quote: "...there will always be some difference between Library and Develop..." - I sure hope not. There certainly does not need to be. If a 1:1 version has been rendered for develop, there is no reason that can't be used for fit view too, simply by resizing. If I were Adobe, I'd just add one level to the pyramid: after 1:1 jpeg, add 1:1 full-rendered, and ditch the ACR cache altogether. Then, treat library and develop the same way. A view rendered for one is a view rendered for both - no longer do we have the problem of develop changes that result in lib views being out-of-date, nor vice versa. Sometimes I think developers get too close to the forest to see the trees - I have this problem myself constantly - users of my stuff often come up with obvious things I've overlooked because I got my mind set a certain way. I think previews/acr-cache may fall in this category for Adobe. Their mindset is to use the ACR cache that was invented way back when as the common intermediate file format to share with Photoshop, but its really time to abandon it, and just ready keep the best rendering possible for Lightroom - lib & dev views. I know a fully rendered dev view is bigger than a jpeg, but I'd rather have a few hundred fully rendered files at the ready than a thousand not-hardly-at-all rendered acr-cache entries - any day. Having the most recent of course, but also intelligent look-ahead.

Summary:
-------------
I propose to ditch the ACR cache, and not bother with this fast-or-good option, and instead:
- Add a higher quality, fully rendered 1:1 file to the preview pyramid, suitable for highest quality lib or develop view.
- Upon initial switching, load the fastest one that fills area from disk (if highest-Q version not cached in ram), then replace with the higher quality view as it gets loaded from disk (or computed in the background if necessary).

Also, make all these previews available for 3rd party plugin-apps so they can show focus points, focus masks, or add destructive or non-destructive post-processing image enhancements, or zoom into them from google earth, or run face recognition on them, or sort by similarity - all the stuff Adobe won't get around to soon, if ever...

Final Thoughts:
--------------------
It works similarly to this already, except the version in ACR cache is worse than the lib preview it replaces, before the final rendering takes its place - this really is not optimal, to put it mildly. (and also, the lazy rendering results in frequently out-of-date views). So the change I'm proposing is not that big of a stretch... (that's develop mode). Library mode also works similarly, displaying the embedded preview until a better preview can be obtained... - so no real change, except for the sharing between modules (assuming not integrated), *and* that the highest quality view would settle into lib view too if user lingers for a moment.

I try to give Adobe the benefit of the doubt, but I also empathize with users that can see through the "oh we (or they) can't do that because..." lines they are sometimes expected to swallow...

Adobe - please make this right in Lr4 - I know you can...

[Victoria Bampton LR Queen]

Library uses a JPEG preview for speed and offline viewing. You can increase the quality of that preview by going for a larger size and higher quality, reducing the difference between Library and Develop (size, compression, and there's also a colour space difference as ProPhotoRGB doesn't squish into an 8-bit JPEG preview well), but then you have a speed and space trade-off because those previews are then bigger files, so you have people complaining that Library's then slower.

Develop always uses raw data for quality, and I agree the Develop preview could do with some attention to give the accurate view it deserves.

If, as it seems you're suggesting Rob, the cached 1:1 raw file (no JPEGs, same issues otherwise) was added to the catalog's preview cache for every image, the preview folder would be HUGE. Now if you wanted to take some photos out with you for offline viewing, you'd have to take these huge previews, in which case you might as well take the raw files and not cache the raw data at all, no? And why spend time and processing power reading and processing raw data to create a Develop quality preview when you only want to add a keyword in Library module?

There's going to be a trade-off somewhere - the debate is whether it's in the right place. If the modular concept was dropped, and Library and Develop were merged, then the whole preview system would need merging, but if Adobe are sticking with the modular concept, which seems likely, then leveraging the benefits of faster previews in Library and accurate previews in Develop seem to me to be the most logical.

So the question is, what's the crux of the matter here? Is it that Library previews aren't fit for purpose (rapid and offline viewing) or is it that the Develop preview needs to be more accurate at smaller zoom ratios, so that users don't have to flick back to Library to see the zoom they want? The OP seems to be requesting the latter, and personally I think he's got that targeted correctly.

[FeedbackCommunityMember]

I agree that it would be nice if a) the user didn't have to make a choice about accuracy because renderings would successively improved, time permitting (i.e., as long as the user doesn't start to work with an image interactively, since the latter should not be slowed down due to background rendering processes). I also agree that the ACR cache should rather contain fewer, high quality renderings, rather than many, "quarter-baked" images which then need a lot of work to be rendered into viewable versions.

At a particular time one only views a small number of images in the Develop module and quick access to cached 1:1 renderings would be much more valuable than the tiny speed-ups one currently gets (albeit for a lot of images, provided the cache is large).

[FeedbackCommunityMember]

Victoria, I like your ideas, but I wouldn't want to be forced to manually activate accurate renderings every single time I need them. There should be a way to make accurate rendering the default and I guess that means a global option, or at least a persistent state of a local option.

So yes, if it were possible to decide for particular images that they need accurate rendering and such images would "remember" this choice then I'd be fine without a global option. I just wouldn't want to be in a position where I had to reactivate accurate rendering every single time I visit the image.

[FeedbackCommunityMember]

Victoria, yes I agree with you. "Develop preview needs to be more accurate at smaller zoom ratios, so that users don't have to flick back to Library to see the zoom they want" captures my request.

Note that there is a solution to the conundrum of not making preview folders huge while allowing high-quality Library browsing at the same time. The solution is: Keep high-quality renderings produced either in the Develop module or by 1:1 zooms in the Library module cached. This cache would partially live in memory and partially on disk. It could be relatively small because in a given time interval one doesn't look at thousands of images at 1:1 magnification. But those images, one needs high quality renderings of, should be revisitable without taking a performance hit because the renderings have to be regenerated again.

As Rob writes, the ACR cache really should rather contain fewer, high quality renderings (and perhaps additional data to efficiently regenerate the former upon changes to the edit actions) compared to many, many small quarter-baked images which do precious little to speed up the viewing/editing experience.

So I'd be fine with preview folders that contain previews that are good enough for quick flicking through, but if -- during a session with LR -- I
* look at an image at 1:1 magnification,
* look at an image for a time span that exceeds a "quick peek while flicking through" at magnification/size that suggests a replacement of the available preview rendering, or
* edit the image in the Develop module,
the resulting high-quality rendering should survive as long as the cache size allows it. The latter cache shouldn't sit where the preview folders sit and AFAIC, it could be the ACR cache which currently doesn't seem to be tremendously useful.

Hope that all makes sense.

[Lee_Jay]

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

Yeah...good idea. I'm for that.

[areohbee]

That's all I was trying to say...

[areohbee]

Well said TK.

PS - I've got no problem with the high-Q image data being considered more acr-cache-like than preview-like...

[areohbee]

Previews + cache can be redesigned for a unified purpose even if module UI is kept separate (develop module is already accessing shared lib views, lib module could also access share dev views). TK pretty much nailed it below, IMO, so I shan't regurgitate, but maybe just point out:

If viewing in library mode, why not view highest Q if available, and if not available, why not compute it, then if you switch to develop view there is no lag. If you don't, then at least you get to see a higher quality view if you stick around, and if you don't then fine - no penalty...

[FeedbackCommunityMember]

I have posted another FR suggesting Better Develop Module Performance that I believe presents a solution to the problem of inaccurate renderings in the Develop module.

The inaccurate renderings are a result of shortcuts taken because the standard pipeline performance is not high enough to support optimal renderings at all times. My performance enhancing suggestion might offer a solution that combines excellent interactivity with optimal renderings.

[FeedbackCommunityMember]

I like the idea, but feel there should be a global option to turn it on for all photos. Maybe worth having is a configuration under that global option that lets you set the effect on or off by things like ISO value (800 and up - show me the noise reduction!) or camera or both as ISO performance keeps getting better.

[FeedbackCommunityMember]

With Library, isn't viewer intent and therefore viewing quality intent embedded in the view type? That is to say if I'm in grid view, it's clear I'm in it for speed since I've willingly given up viewing area (I'm likely doing key-wording or searching or something) while if I've gone to Loupe and made my image huge (say greater than 80% of my screen) or Survey (because I'm comparing them) then it is very likely I'm actually viewing the picture and need an accurate rendition of the image (what's the point in comparing non-acurate images).

[FeedbackCommunityMember]

I really hope this gets added to Lightroom 4, the inaccurate display in develop ia t leass than 100% makes it quite hard to adjust many of my log light images that need some noise touch up.

Jim

[FeedbackCommunityMember]

Not having NR in developer view with fit/fill is ludicrus. ITS NOT MEANT TO BE FAST, thats why we have library view isnt it? library = fast innacurite, developer = as accurite as possible irrelivent of time.

At the very least an option to enable NR fulltime in developer mode is a MUST.

I use alot of dark images with max NR. So what it should look like when zoom is set to fit and what it looks like without NR is massivly differant. Currently i have to switch to library mode but they your looking at a jpeg which i don't want.

[FeedbackCommunityMember]

Yeah library = jpeg preview, developer = raw.

Topic is more about NR/other been disabled in developer view(for the sake of speed? which should be librarys job)

[Lee_Jay]

So, NR is full-time in Develop now in LR4 Beta. Should we call this one "Implemented"?

[areohbee]

I think so, yes.