Lightroom: Low Quality Downscaled Views in the Develop Module

  • 29
  • Problem
  • Updated 6 years ago
  • Solved
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.
Photo of TK

TK

  • 531 Posts
  • 109 Reply Likes
  • hopeful that others regard this behaviour as a bug (or uncalled for performance optimisation) as well, as opposed to stating that the behaviour is "as designed since LR 2".

Posted 7 years ago

  • 29
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

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

TK

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

Lee Jay

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

TK

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

timiambeing

  • 3 Posts
  • 0 Reply Likes
Just to second this - please go see original topic for more detail - http://forums.adobe.com/message/36575...
Photo of Rob Cole

Rob Cole

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

TK

  • 531 Posts
  • 109 Reply Likes
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". :)
Photo of Geoff Walker

Geoff Walker, Champion

  • 214 Posts
  • 42 Reply Likes
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.
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

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

TK

  • 531 Posts
  • 109 Reply Likes
Thanks for the pointer to that free sample, Victoria. I look forward to reading it.
Photo of Lee Jay

Lee Jay

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

TK

  • 531 Posts
  • 109 Reply Likes
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.
Photo of Carsten Saager

Carsten Saager

  • 6 Posts
  • 0 Reply Likes
I would consider it almost a bug, the compare tool because almost unusable if you can judge the details only in 1:1
Photo of Paul Clark

Paul Clark

  • 2 Posts
  • 1 Reply Like
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 :)
Photo of TK

TK

  • 531 Posts
  • 108 Reply Likes
Make sure to vote on the feature request. :)
Photo of timiambeing

timiambeing

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

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
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...
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

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

TK

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

Rob Cole

  • 4831 Posts
  • 373 Reply Likes
I apologize for my part... - thanks TK.
Photo of TK

TK

  • 531 Posts
  • 109 Reply Likes
No problem, Rob! All cool. :)
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 373 Reply Likes
Whew...
Photo of TK

TK

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

Rob Cole

  • 4831 Posts
  • 373 Reply Likes
Its so obvious now that you've said it. It *is* a problem for you - who could argue...
Photo of Paul Clark

Paul Clark

  • 2 Posts
  • 1 Reply Like
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?
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 373 Reply Likes
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.
Photo of Bradley Fernihough

Bradley Fernihough

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

Rob Cole

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

TK

  • 531 Posts
  • 109 Reply Likes
Very good points, Rob.
Photo of TK

TK

  • 531 Posts
  • 109 Reply Likes
Maybe my feature request regarding better Develop module performance is a solution that combines the best possible interactivity/performance with optimal renderings.
Photo of Michael Paolini

Michael Paolini

  • 4 Posts
  • 1 Reply Like
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.
Photo of Shaun Hooper

Shaun Hooper

  • 12 Posts
  • 0 Reply Likes
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)
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 3798 Posts
  • 1256 Reply Likes
>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.
Photo of Shaun Hooper

Shaun Hooper

  • 12 Posts
  • 0 Reply Likes
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.
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 28 Reply Likes
If the most time consuming part is moving the mouse to switch modules, use the keyboard shortcuts instead (E for Loupe, D for Develop).
Photo of Michael Paolini

Michael Paolini

  • 4 Posts
  • 1 Reply Like
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.
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

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

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
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.
Photo of mike A

mike A

  • 3 Posts
  • 0 Reply Likes
Agree, no NR in developer mode is a bug, its not meant to be fast, its meant to be accurite.

Feature request should be to have an option to disable NR at low zooms
Photo of kim siebert

kim siebert

  • 4 Posts
  • 0 Reply Likes
Chiming in after being a lurker - but, with TOPAZ Software there is an option to apply an effect and have the preview turned on or off. Topaz is ridiculously slow though.

Don't get me wrong, but, I love the fun and variety with Topaz Plug ins, however, the plug ins, (all of them) are NOTORIOUS for being super laggy. Which is why I don't use them as much as I do NIK and ONONE.

Side Note: Their latest B/W plug in is their best yet. It rivals NIK - Even though there are a bunch more variety in TOPAZ, there is just an outrageous amount of outcomes you could end up with that it is overwhelming.

*you should try it out, free 30 day fully functional trial and you can use it in PS and LR* (and you can thank me later! And it is EXTREMELY inexpensive.

Perhaps LR could follow suit and offer a full size or fit to screen preview after applying NR?
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
You're a little late to the party - Adobe has implemented NR in dev mode, across the board - not an option - works well - have you tried it?

Thanks for the Topaz tips...
Photo of Todd Shaner

Todd Shaner

  • 130 Posts
  • 10 Reply Likes
FYI - I have just posted a 'Part II' continuation of this subject here:

http://feedback.photoshop.com/photosh...

This concerns an issue with both LR3's and LR4's resample algorithms affecting both preview image and exported image quality when processing noisy high ISO raw files.