Skip to main content
Adobe Photoshop Family

513 Messages

 • 

11.1K Points

Thu, May 5, 2011 12:57 PM

Solved

Lightroom: Low Quality Downscaled Views in the Develop Module

In the Develop module certain image operations (such as chroma noise reduction) only seem to be applied at 1:1 views. At lower magnifications, I often see very grainy skies which are shown to actually be smooth when I zoom in.

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 highlights are shown between the Library and the Develop module views.

This begs the question, what is the "correct" view? How will a downscaled image (e.g., intended to be shown on the web) look like? Will it look like in the Develop module, the Library module, or yet another way?

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). The image editing activity (Develop), however, should always be supported with the best possible preview, no matter the magnification.

Responses

Champion

 • 

5.9K Messages

 • 

104K Points

10 years ago

The lack of noise reduction in less than 1:1 views is as designed for performance reasons. The noise reduction is very processor intensive so it's only applied to previews that LR thinks the noise would be distracting, based on ISO/camera/file type/process version, etc.

That's a step up from LR2, where it was never shown in Fit view, but I agree that as a Feature Request, there should be an option to 'always show' with a warning of the performance hit, so that the user can make that decision. Alternatively, a warning triangle, like PV triangle, should warn that it's not an accurate view and allow you to click to apply those settings to the preview. If you'd like me to switch this thread to a feature request instead of bug so people can vote, just say.

As far as the highlights differences, I think we need to see a picture. There are two bugs that I'm thinking - one that shows a different view between Library and Develop particularly on saturated red/orange/yellow highlights (i.e. sunset/flame) and another where local adjustments cause highlights to change even when the brush isn't anywhere near that area.

Victoria Bampton a.k.a. The Lightroom Queen

www.lightroomqueen.com

Author of Adobe Lightroom Classic - The Missing FAQ and Adobe Lightroom - Edit Like a Pro books.

513 Messages

 • 

11.1K Points

10 years ago

Victoria, thanks for your response.

1. The highlight differences I saw were precisely with saturated red/orange/yellow highlights in sunset images.

2. I'm hesitant to have this be transformed into a feature request because to me being presented with a sub-par rendering while making image adjustments is a bug. It should be fixed and then someone else can put in a feature request to get an option for "fast but inaccurate" image rendering in the Develop module. Does that make sense?

I don't want to appear to be non-cooperative and am open to have this turned into a feature request, but am quite positive about the current design choice to be a flawed one.

946 Messages

 • 

13.8K Points

". I'm hesitant to have this be transformed into a feature request because to me being presented with a sub-par rendering while making image adjustments is a bug. It should be fixed and then someone else can put in a feature request to get an option for "fast but inaccurate" image rendering in the Develop module. Does that make sense? "

No.

By definition, it's not a bug if it's doing what it's been designed to do. A request to change the as-designed behavior is by definition a feature request.

513 Messages

 • 

11.1K Points

10 years ago

Lee Jay, I see your point, but note that not only implementations can be flawed but specifications as well. From a user perspective, it doesn't matter whether the undesirable behavior is caused by an incorrect implementation or an inadequate specification.

If a feature request is required to be heard (and this bug report will be regarded as incorrect as the implementation behaves as designed) then I'm happy for this to be turned into a feature request. However, I would have to update the text a bit.

3 Messages

 • 

88 Points

10 years ago

Just to second this - please go see original topic for more detail - http://forums.adobe.com/message/36575...

4.5K Messages

 • 

76.3K Points

10 years ago

In my opinion: Adobe should be able to handle this as an "Idea" *or* a "Problem" - the distinction being somewhat academic in this case.

Maybe when the whole Lr preview/caching business is reworked, it will be a good time to straighten this business out too. Maybe even before then...

513 Messages

 • 

11.1K Points

10 years ago

From a software engineering perspective there is no bug (the implementation is correct, i.e., adheres to the specification). From a user perspective, the software doesn't behave as desired. Should the user make the call which case (faulty implementation or faulty specification) they are dealing with? Maybe that's worth clarifying in the FAQ ("What's the difference between a bug report and a feature request?"). A user will however often face the problem of not knowing whether or not some behaviour is intended (i.e., technically not a bug) or is not intended. For instance, Jeff Schewe once (incorrectly, AFAIC) argued that the failure of LR3.3 to adequately deal with spaces in keywords is not a bug, but was "as designed" and a change would warrant a feature request rather than a bug report. To me that suggests that bug reports should not be dismissed on the basis that, technically, there is no bug. I hence would allow users to regard any behaviour that they regard as being wrong as a "bug".

In any event, I have created a feature request that captures the spirit of this bug report. I think that this bug report should not be deleted. A merge might make sense but one could also leave it as it is to see how many people regard the problem as a "bug" vs a "feature request". :)

Champion

 • 

220 Messages

 • 

4.1K Points

10 years ago

Turning into a feature request will certainly gain more traction. It doesn't matter what you call it bug or feature, the answer to a bug report is: it is working as designed and implemented. A bug is when something is not working as designed.
Hence you need to say the design and implementation isn't what you want and state the case for what you want with specific examples. Otherwise you may continue you beat your head against a brick wall!! :)

Victoria's "but I agree that as a Feature Request, there should be an option to 'always show' with a warning of the performance hit, so that the user can make that decision. Alternatively, a warning triangle, like PV triangle, should warn that it's not an accurate view and allow you to click to apply those settings to the preview." sounds about right to me.

513 Messages

 • 

11.1K Points

Geoff, I agree that Victoria's suggestions are very good. I have awarded her post a star. :)

3 Messages

 • 

88 Points

Whatever gets a response is OK with me, it's great to get some momentum going, but can I just ask if any of you guys talking of it as a "feature request" actually have the problem? Because - in my case and others posted on the Adobe forum I can view a JPG file in the Develop module, with all it's adjustments faithfully rendered, at all views! So does this "feature" only apply to RAW? Can anyone point me to where Adobe have said this is a feature but only with RAW files?

Champion

 • 

5.9K Messages

 • 

104K Points

Yes, it's a behaviour that bugs me too. The reasoning behind it makes perfect sense, but I wish there was a user-option that would allow the choice.

Yes it applies to raw only. I don't think Adobe have posted the details on a public forum, but I have had a private conversation on the subject. If it helps, one of the free samples from my book has a grid that shows where it applies and where it doesn't. http://www.lightroomqueen.com/lrqeboo...

Victoria Bampton a.k.a. The Lightroom Queen

www.lightroomqueen.com

Author of Adobe Lightroom Classic - The Missing FAQ and Adobe Lightroom - Edit Like a Pro books.

513 Messages

 • 

11.1K Points

Thanks for the pointer to that free sample, Victoria. I look forward to reading it.

946 Messages

 • 

13.8K Points

"Yes, it's a behaviour that bugs me too. The reasoning behind it makes perfect sense, but I wish there was a user-option that would allow the choice. "

Myself, I think I'd leave it, but the algorithm needs to be smarter. It need to take into account things like screen size, computational horsepower, how much adjustment has been made to the darker tones (exposure, fill-light, tone curve), and white balance in addition to camera and ISO. Then it needs to apply color NR earlier than L-NR. If a suitable algorithm can't be formulated, then I'd give in to the user preference approach.

I also like the approach suggested elsewhere (here?) that it always put up the image as fast as possible, but then continue to refine it as time allows. So, even with a huge raw image on a huge screen displayed by a dog-slow computer, if you let it sit there, it'll eventually apply all settings and downsample that.

513 Messages

 • 

11.1K Points

I doubt the decision procedure can be made smart enough to work well with all sorts of cameras and images. Hence, I'd prefer an option over waiting for a working decision procedure to be developed at some point in the future.

I agree that the "continuous refinement" approach would be best.

6 Messages

 • 

174 Points

I would consider it almost a bug, the compare tool because almost unusable if you can judge the details only in 1:1

2 Messages

 • 

94 Points

10 years ago

Are we all a bit too consumed with the semantics here? Does it really matter if its a bug or a design flaw? Whatever it is it is wrong. It should be fixed.

Maybe I am really asking for this - but can anyone give me any other graphics package that whilst editing an image does not give me a true representation of what I am doing regardless of the view? If I want to see a full screen shot of my picture while tweaking the overall effect I should be able to! And before I get shouted at - the hands are raised here :)

I see no difference to telling me that I can only see my images in mono unless I zoom in... Makes no sense from a users point of view whatsoever. I was so bitterly dissapointed with Adobe to find this had not been sorted with 3.4.

There feel better for that :)

513 Messages

 • 

11.1K Points

Make sure to vote on the feature request. :)

3 Messages

 • 

88 Points

Oh - if only Adobe ever, ever, looked in here Paul! Then I would feel better too... but I am beginning to think writing here is about as much use (as I have found with Spotify and several others on Get Satisfaction) as writing all this in your personal journal and then slipping said journal into your bedside drawer and leaving it there! What a shame - I do so want to love the software on my Mac as much as I love my Mac!! :0)

Any comments from a company rep? No... oh well thought not :-/

Actually, lets be more positive about this - I give Adobe 3 weeks to respond to this thread - bearing in mind if we all make sure we moan at least once a day (and put only sad faces on our posts instead of smileys) the mood in here will be awful and surely that must kickstart some auto notification system that notifies the company concerned we is not happy? Hey - it's worth a try?

4.5K Messages

 • 

76.3K Points

I agree more responses from Adobe employees (and more specifically, Lightroom engineers) would be welcome. But, I think they read a lot more than they write... - or at least skim. And in this particular case, I would guess that sharing the truth with users would probably be seen as a losing proposition for them...

Just for grins, my sheer fantasy of what the truth might sound like:
- We know this sucks, but John Doe is the one who wrote it, and Jane Doe has since taken over, but she hasn't figured it out yet, and in any case the code is kinda messy, and last time in we had all kinds of trouble getting the lid back on Pandora's box and the worms back in the can... And anyway, right now the the US economy is hurting, and department funding is lean, and we really don't have time to mess with this, since there are still cameras to add and a bunch of problems most user don't even know about. Anyway, we may get around to improving this some day, or we may not - but I wouldn't hold my breath if I were you... - Cheers, Adobe.

If you want to have fun too, try a sheer fantasy response to this from the users...

PS - This could be worded with more tact - but users are often merciless and pull no punches where Adobe is concerned - I'd hate to be Adobe on these forums...

PPS - Adobe and users are in some respects partners interested in a common goal, but in other respects the relationship can be very adversarial, and Adobe has to be careful not to start things on this forum that they don't want to finish... - or so I postulate...

4.5K Messages

 • 

76.3K Points

If you want to have fun too, try a sheer fantasy response to this from the users...

Champion

 • 

5.9K Messages

 • 

104K Points

Adobe are reading Tim, but you've seen the number of posts each day - it takes me ages to get through them all! If they stopped, discussed and replied to every one immediately, they'd never have time to actually implement them. It would be great to see employees on this forum more, but don't panic if they don't reply - it could mean it's on a meeting agenda to discuss before saying anything publicly, etc. Unlike some of the smaller companies who use this kind of fr/br forum, they have a lot more corporate constraints in what they can say publicly.

As far as 3.4 goes, I would be very surprised if you saw any change to this behaviour before 4.0, even if there's agreement within the team that it could be changed. The preview system is a major major part of the software, and major rewrites tend to wait until major releases as you risk introducing some big bugs and they require longer testing than a dot release.

Victoria Bampton a.k.a. The Lightroom Queen

www.lightroomqueen.com

Author of Adobe Lightroom Classic - The Missing FAQ and Adobe Lightroom - Edit Like a Pro books.

513 Messages

 • 

11.1K Points

10 years ago

Hey guys, let's keep a positive and constructive attitude on this site. Ranting, bashing, venting, etc. can/should be done on the old user2user forums. :)

Seriously, Adobe created this site in order to get constructive feedback from customers. It trumps everything we ever had before. Many employees and champs leave comments.

Yes, it would be great if employees and champs appeared even more often and had put an "Under Consideration" on my favourite feature request :) but a) they don't have all the time in the world to hand-hold every poster and b) some responses cannot be made by individuals only but require team consideration.

Consider this "inaccurate rendering" problem: Maybe the solution is not as straightforward as it seems? What if renderings were as accurate as possible and the editing became rather slow? How many would complain about "sluggish software" without even realising that they could activate a faster rendering mode?

More often than not the performance optimisation of not applying noise reduction in the Develop module renderings works in our favour, doesn't it (I only experience the "blotchy grain problem" in a relatively low number of images)?

Maybe a more accurate rendering can be enabled once some other performance bottlenecks have been addressed but no single Adobe employee is in a position to make any promises?

Ideally, some official would drop by and say "Yes, it is a known issue we are still thinking about" but if that doesn't happen, we shouldn't be ranting and venting here. Please use the old user2user forums for the latter and keep this a positive place. :)

4.5K Messages

 • 

76.3K Points

I apologize for my part... - thanks TK.

513 Messages

 • 

11.1K Points

No problem, Rob! All cool. :)

4.5K Messages

 • 

76.3K Points

Whew...

513 Messages

 • 

11.1K Points

10 years ago

I found the golden solution to the "bug" versus "feature request" semantic issue, we've been discussing!

The good news is: On this site, you are not filing a bug report, but a problem report.

Hence, any behaviour that deviates from my expectations can appropriately reported as a problem, independently of the fact whether it is a bug or just a design flaw from a software engineering perspective.

4.5K Messages

 • 

76.3K Points

Its so obvious now that you've said it. It *is* a problem for you - who could argue...

2 Messages

 • 

94 Points

Haha - Ever thought about politics as a career :>
No way is this a lets knock Adobe rant, but attempting to just bypass what is a problem to some of us by stating it 'would slow it down' smacks as lame. Again, perhaps Adobe needs to emply someone from one of their competitors that seem to have cracked it. Anyone use Apples software? Does that do it?

4.5K Messages

 • 

76.3K Points

I'm *sure* its a matter of time & energy (& money, & commitment...), not ability. Adobe does challenge my ability to give the benefit of the doubt sometimes, but I do think TK is right - better for them, and better for us, to at least try...

PS - Aperture has its problems too, more people have migrated from Aperture to Lightroom than the other way around.

14 Messages

 • 

290 Points

10 years ago

While i totally agree with the request/problem report, i am reluctant to sacrifice any more performance.

The performance of LR is the number one priority for adobe, IMHO. Rendering of previews is one of the biggest culprits to the continued poor performance that can bog Lr down.

4.5K Messages

 • 

76.3K Points

Any raw processing software will take a "long time" to render raw files with bunches of parametric adjustments. The problem with Lightroom is with the preview/caching subsystem. It needs to be revamped to maximize use of ram & disk & cpu so that the renderings it needs are more likely to be there when they're needed. In this particular case, most of us don't have a problem with being shown a view quickly if its the best Lightroom has got so far. Its the fact that it doesn't continue to compute a better version to sneak in there, and hold on to for the future, that is the rub.

Summary:
-------------
We all want the same thing here - in this case a user option is not the right way to go. To recap: faster at first, better at last, only recompute if caught short...

Final thoughts:
-------------------
As long as rendering improved views is lower-priority/interruptible, it will never interfere with program responsiveness.

I don't mean to make this sound easy - I would guess it'll be a challenge. But its doable, albeit probably very time consuming for the developers. I suspect its on Adobe's own list of shortcomings (its certainly on their user's lists). I dunno if its on their to-do list yet.

513 Messages

 • 

11.1K Points

Very good points, Rob.

513 Messages

 • 

11.1K Points

10 years ago

Maybe my feature request regarding better Develop module performance is a solution that combines the best possible interactivity/performance with optimal renderings.

4 Messages

 • 

124 Points

10 years ago

For people who shoot a lot in low light, say around 800 ISO, (think performances, concerts, etc) this is a serious problem - it's not small percentage of their shots. I also suspect this problem is going to become continually worse as the DSR continue to assault the Medium format and add the pixels (and ISO).

For the record, the problem caused me to download Aperture 3 for comparison purposes, and I have say it is a very pleasant product that doesn't seem to have this negative behavior.

As a long term LR user, I'd ask that Adobe address this in the current product in the near future. Photographers have to be able to see, and trust what they see, their changes as it is their livelihood.

I've added my +1 to the feature request as well, but wanted to also add my voice to this. All the speed in the world means nothing if it gets us to the wrong image output.

12 Messages

 • 

248 Points

10 years ago

I agree with TK and Michael. Not being able to view detail develop settings in the "standard view" (i.e fit view) is very annoying, and is does not work as expected (in comparison to every other develop setting).

In fit view, the detail Panel On/Off icon is effectively useless. It is impossible to see how the entire image is changed by the effect of the detail panel.

This is also true when using the before/after views (because they are also at fit view). This behavior is counter to every other develop setting.

I fail to see how this is a performance issue. In the library module, detail settings are visible in fit view. Why not develop module?

I too would really like to see this addressed as well (I've added my +1)

Champion

 • 

5.9K Messages

 • 

104K Points

>I fail to see how this is a performance issue. In the library module, detail settings are visible in fit view. Why not develop module?

Right or wrong, the difference is that the Develop module is a rapidly changing preview, whereas Library works off a stored preview.

In Library module, the settings are applied once to the largest preview and then that processed image is downsized to Fit view. That's why you see the detail settings in Library.

In Develop, it's done on the fly because it changes every time you move a slider. If you're zoomed into 1:1, it only has to apply all of the settings (incl. NR/sharpening) to the patch you can see on screen. If you're zoomed out to Fit is has to apply to everything. Applying to everything takes more processing power.

I'm not knocking the FR - I agree it needs work - but hopefully the extra information will help you understand the decision as it stands at the moment.

Victoria Bampton a.k.a. The Lightroom Queen

www.lightroomqueen.com

Author of Adobe Lightroom Classic - The Missing FAQ and Adobe Lightroom - Edit Like a Pro books.

12 Messages

 • 

248 Points

Ok, fair point, I see this takes more computational resources. I guess what I meant was my current process is:
Apply detail develop setting -> Switch to Library View and look at Fit View -> Go back to Develop View
Iterate until satisfied. The most time consuming part I find is moving the mouse to switch modules (i.e. not the computation of downsizing).

So there IS a way to currently see your edits applied in fit view, you just have to manually switch to Library. So if this can be done, why can't we cut out the middle man of switching modules?

However something that currently can't be done is to compare before and after views of the entire image with detail edits. For any high ISO image, this is a real issue.

142 Messages

 • 

3.7K Points

If the most time consuming part is moving the mouse to switch modules, use the keyboard shortcuts instead (E for Loupe, D for Develop).

4 Messages

 • 

124 Points

10 years ago

Victoria, Thanks for the reply. I know understand the tradeoff a little better. So let me state it back to you to be sure. The current view is 90% of the photos don't require noise reduction or sharpening which are extremely processing intensive, so why make the user wait when they touch their sliders to adjust the other 90% of the controls? What is being expressed here by the photographers, at least your discerning ones, is this is the wrong trade-off, that we need to see the effect of everything we apply to the whole picture (e.g. Fit view) even if it slows us down for things like tweaking color temperature - final image is everything, and develop is where we produce that. This is why we consider this a bug that needs to be addressed now, and not a feature request. It is also why we spend thousands on really big monitors with great color and computers with tons of memory and computing power.

Now we'd like our cake to have and eat too, hence the discussion around a switch to turn Noise / Sharpening live update on/off in fit - that seems like a good compromise for Laptop use.

The 2 other things to note here are high ISO shots are increasingly the norm as the modern camera deliver these capabilities, and processing power is ever growing - even the laptops at this point are many core with outrageous Graphic Processors. This is likely by the main competition for LR, Aperture, has made the decision to show NR/Sharpening in their version of develop and fit view. And frankly this issue is important enough to me, that I may go through the hassle of switching over to it 100% rather than just using it for slide show creation as I currently do now.

This is a big deal to us.

Champion

 • 

5.9K Messages

 • 

104K Points

>The current view is 90% of the photos don't require noise reduction or sharpening which are extremely processing intensive, so why make the user wait when they touch their sliders to adjust the other 90% of the controls?

Basically, yes. There's a lot of intelligence in which photos it thinks the noise is going to show, based on camera model, ISO, Develop settings etc. But I agree, there needs to be more user control over that, as that intelligence doesn't always get it right.

Just to clarify one point - sharpening is always shown in Develop regardless of zoom as long as the photo is PV2010. It's just the NR that's adaptive.

Victoria Bampton a.k.a. The Lightroom Queen

www.lightroomqueen.com

Author of Adobe Lightroom Classic - The Missing FAQ and Adobe Lightroom - Edit Like a Pro books.

4.5K Messages

 • 

76.3K Points

Hopefully Adobe will rework this so the user does not have to exert control. I don't think anyone has a problem seeing fit view without noise reduction immediately if that's the best Lightroom has for the moment (e.g. nobody wants to wait for NR to kick in before they see an exposure change). The missing piece is not following-up with a better rendition after a bit, so user doesn't have to switch to the library module and back.

Summary:
=======
I really don't think offloading the decision to the user to control whether they want it fast or good is the right way to go here, since what the user wants is clear: responsive, but ultimately: show the final result in develop module - and with a little love its possible to have both.