Lightroom: Noise slider does not affect main image, only when zoomed

  • 2
  • Problem
  • Updated 4 years ago
  • (Edited)
I'm really struggling with the Noise slider when I have my image on screen in full (not zoomed in). Obviously I only want to slide enough to take away the noise and not flatten the image too much. But no matter how much I move the slider, the image still looks noisy. It's only when I zoom in that I can see how much the image changes. But when I zoom back out, the image looks noisy again. See attached screenshots and note slider position. The full image doesn't appear to change, look at the sky. For reference I'm using a 21in iMac and LR 3 fully updated.

I want to be able to see what the final image will look like, am I doing something wrong?




Photo of chris davies

chris davies

  • 3 Posts
  • 0 Reply Likes
  • annoyed, I'm over NR'ing my pictures unnecessarily

Posted 7 years ago

  • 2
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
That's expected and normal, and done for performance reasons. Personally, I'd like a preference for that. However, a look in Library will show the detail panel settings applied at fit view.
Photo of chris davies

chris davies

  • 3 Posts
  • 0 Reply Likes
So it does. That's a real pain, I need to see it when I slide not have to keep flicking into Library to see what it has done to the full image.

Hey Lightroom developer, can we have a switch please.

@LeeJay - thanks for that
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
My understanding is this is due because zoomed out, the accuracy of the preview with NR would be less than ideal/accurate/correct. Now maybe there are performance reasons but like sharpening, getting an inaccurate preview isn’t useful so I think of this as the team protecting us from seeing something we shouldn’t and acting on it.

My understating is that in Library, we’re being fed a different preview process and its again, not as accurate as Develop.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
The problem with the "inaccurate preview" argument (which is technically correct) is that applying nothing at all is even less accurate then some sort of reasonable estimate (like what is done in Library). In some cases, this can lead to important inaccuracies, such as the color shifts that can come with not applying color noise reduction. You might act on those shifts (i.e. with a WB change) and not realize you actually messed it up once the color noise is removed.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
I see your point. But if you see no effect, you have the option to RTFM or asking in forms why you don’t see the effect (and you’re told you have to zoom in). The alternative is having it on, but incorrect which I suspect would lead to even more people asking what’s going on, which preview is correct and so on. Users have to understand what module they need to make color and tone critical edits in and how to view them.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
Well, it's not easy to make color and tone corrections when you can only see a tiny portion of your image, and it's also not easy when it's all covered in red-colored noise.

I'd rather have a somewhat inaccurate preview with a warning than a really, really inaccurate preview with no warning, which is what we have now.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
True but its easy to see the effect of noise and sharpening. Maybe that has to be dealt with earlier in the process and move out of the way for the other tone and color moves that *may* be affected by that stuff being shown. I don’t see an easy fix here. You either show an incorrect preview or none at all. Some want the incorrect preview, so maybe a preference is called for. I don’t see that ever happening because I think Adobe would find it a bigger burden on tech support and user satisfaction than the current path they’ve taken.

So the really, really inaccurate preview is a better option for color and tone correction than having an accurate preview with red colored noise (can you even see it zoomed out?).
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
"So the really, really inaccurate preview is a better option for color and tone correction than having an accurate preview with red colored noise (can you even see it zoomed out?). "

Zoomed out, I have images that have a strong red cast in Develop that have no such cast in Library, and it's just because color noise reduction hasn't been applied to the fit view in Develop.

As for sharpening, I think the right approach there is the one already built in - do export screen sharpening when looking at a "fit" view. That's what it's for. Could be a big performance hit, though.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
But we both know that the only accurate previews are in Develop from the ACR cache data. Lets stick with one module.

So in Develop, when you zoom in, does the red cast disappear with NR on? That could be a problem.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
"So in Develop, when you zoom in, does the red cast disappear with NR on? That could be a problem."

Absolutely it does.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
Well that’s a problem! That is something the team should be aware of. Can’t say I’ve seen this, I’ll have to pull up some really high ISO stuff.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
Don't forget, Andrew, the application already applies color and luminance noise reduction at fit size when it thinks it'll be visible. If you happen to have a low-ish ISO shot that you've pushed a lot with exposure, fill light or the tone curve, the application won't think the noise will be visible, it won't apply the NR at fit view, and you can see this effect. This isn't about accuracy, it's about performance.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
OK, I took an image shot at ISO 12800 under candle light, not white balanced so its darn warm. There’s the larger preview (Fill on a 30”) and the zoomed 1:1 preview with NR on and off. I have to say I do not see this big disconnect in color you report. Yes, no question that when zoomed in, without NR, you see noise. No NR isn’t the default but I zeroed out the sliders.

There’s a lot of red and other colored noise pixels as one would expect. Zoomed out, you don’t see those individual colored pixels. But I don’t see the difference here being a problem (for me). The overall color and tone zoomed out isn’t a surprise compared to the zoomed in preview. IOW, I don’t see a cast appear or disappear based on the zoom albeit, it would be foolish to say the two appear identically (something you can’t say for any dissimilar zoom previews you would compare.

But unless we had an option of NR being on when zoomed out, I have no way to prove or disprove the comparisons would be closer. That said, I don’t find this an issue. The image is at:

http://digitaldog.net/files/LRNoiseZo...

You will also notice that at Fill, you DO see some NR applied (its not off). But its not an accurate (pixel level) representation of the image, much like zooming out in Photoshop isn’t.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
"You will also notice that at Fill, you DO see some NR applied (its not off)."

Right...it's applied. My example below is from an ISO 400 shot that was heavily pushed. There, the NR is off at "fit".
Photo of chris davies

chris davies

  • 3 Posts
  • 0 Reply Likes
Ok, so I started this topic and I'm now even more confused. Excuse my poor terminology here (and I am quite new to LR) but since when was the big image in the middle of my screen a PREVIEW? Surely this is what I want my final image to look like isn't it? Therefore any changes I make using sliders anywhere (library or develop) should make visible changes?

If I'm taking the wrong approach to using LR please do say so and point me to any guidance or books I should be reading. Your discussions are very useful,

Thanks

Chris
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
"Ok, so I started this topic and I'm now even more confused. Excuse my poor terminology here (and I am quite new to LR) but since when was the big image in the middle of my screen a PREVIEW? Surely this is what I want my final image to look like isn't it?"

Certainly it is, but it's only a preview of that final image until you have that image exported at the final size you want, in the final space you want, put onto the final media you want, and viewed under the final light you want if that media is reflective (i.e. a print).
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
No, its a preview if you want to get technical. And the previews in Develop are generated differently than other modules, its where you want to view the images with the most precision.

The idea here isn’t that much different than Photoshop where there’s all kinds of edits you can’t see depending on the zoom ratio. If you want an accurate view of the pixel data, you have to be at 100% or greater there.

In LR, if you zoom to 1:1 or greater, its similar in terms of seeing the accurate preview of the pixel data. Noise reduction and sharpening simply can’t be shown to you, in either LR or Photoshop if you are zoomed out too far. The direction the LR team made, for good or bad is, there’s stuff we will not update in the preview if you are zoomed out too far.

The approach is, if you need to do edits that are so precise you need to see how they affect the image at a pixel level, you have to be at 1:1 or greater. Don’t be moving those Detail sliders around without either having the main preview zoomed in to 1:1, or using the smaller detail preview area in the pane. Otherwise you are flying blind.
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
I don't agree that noise reduction and sharpening cannot be shown if you are "zoomed out too far" (assuming that "zoomed out too far" includes a standard Develop module "Fit" image size).

If that were the case one wouldn't see differences between the Develop views (lack noise reduction in some cases) and Library views (include all image processing).

I also disagree that one is "flying blind" when making adjustments at less than "1:1" magnification. Yes, the latter zoom level is often the correct one, but what if I want to judge the effect of adjustments on an exported image that will have the size of the "Fit"-size of the view in the Develop module?

I'd say that adjustments are best made at the magnification level you are targeting with your final image. Sharpening can then end up being too high in a "1:1: view but that doesn't matter if it is right for the downscaled version you are trying to create.

In theory one could just do adjustments based on 1:1 views and output sharpening/processing would then get it right for all output sizes. In practice, that doesn't always work.

Even if one disagrees with my idea of using different adjustments for different output targets (compensating inkjet printing fuzziness anyone?) then I believe that it is still the case that some adjustments are difficult to make if one only sees some detail in a 1:1 view. So even if there is just one correct set of adjustments that is independent on the output target, I'd like to be able to at least approach them with lower than 1:1 magnification views.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
Here's an example, shown at 400%, of the color NR's effect.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
Yes, its similar to my example too. I do see the red noise, no question. I just don’t know if I’d do anything differently in terms of non NR editing based on what that shows me (its clearly a noise issue). Maybe I was thinking of cast in a different light.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
On a more extreme case, this makes the overall image look red-ish at the fit size.

Since it's a performance issue, we should have the option to turn it off especially if we have a fast machine and can live with the performance hit.
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
There seems to be a widespread assumption that all editing in Lightroom only has a single purpose: To produce a print with detail approaching that of a 1:1 view.

I dispute this assumption. I'm assuming that many images will either be viewed on the web with a size not exceeding 800x600 and/or will be printed to sizes that are smaller than 16x20 inches.

Therefore, it is important that one is able -- one way or another -- to get an as accurate as possible idea of how an image will look like scaled down, e.g., on the web. It is unreasonable to expect people to export images or view them in the Library module to get the respective visual feedback.

I agree that the 1:1 view in the Develop module usually is the correct mode to fine tune sharpening, noise control, etc. but for the above reasons lower magnifications should also be rendered as accurately as possible. That this is indeed attempted whenever the LR heuristic thinks that noise reduction will have a visible effect (it is often very wrong with my images) is testimony to the fact that the LR team does not think that the "1:1" Develop view is the only authoritative view.
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
>There seems to be a widespread assumption that all editing in Lightroom only has a single purpose: To produce a print with detail approaching that of a 1:1 view.

Ah, OK although I don’t know that for a fact considering the huge number of images that are used on-screen and not printed.

If you want to have an accurate representation of what the image will look like on YOUR screen, just look at it. Anyone else? All bets are off outside ICC aware app’s that preview that data.

1:1 of a resampled image for a fixed screen size appears accurately in color managed app’s at, well 1:1. That’s key. View the image at the size you intent to view the image on-screen at 1:1.

In terms of a print, there’s a huge disconnect between the display and print even at 1:1 considering the vast differences in output resolution between say a display at 100 or so PPI and a printer that will lay down 2880dpi. Gamut, contrast ratio, add to this disconnect to a lesser extent.
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
Andrew, I don't understand your statement "If you want to have an accurate representation of what the image will look like on YOUR screen, just look at it.".

I'd like the Develop module to show me how my final image will look like when downscaled to the size it is currently showing. It doesn't do that in many cases. It will show a downscaled version with noise reduction omitted, for example. My only options to see the effect of noise reduction are
a) 1:1 view; not ideal because I'm seeing detail as opposed to the whole image
b) switching to the Library module; takes time and the Library rendering might be affected by JPG artefacts and/or differing red/yellow tones in highlights (-> sunset images)
c) performing an actual export; way too cumbersome.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
>I'd like the Develop module to show me how my final image will look like when downscaled to the size it is currently showing.

Lets say we have a 4K raw that will be rendered. Well at what size in terms of its pixel dimensions? At 1:1, you see that full resolution preview of the native pixels. But you want to end up with a 1200x800 pixel sRGB image for web or email. You just have to render out at that size and color space and view that at 100% (1:1) for a truly accurate preview of the data. What you see now is what is accurate (on your display assuming you are viewing it in an ICC aware application).

Assuming you’ll render the full resolution of the raw, in ProPhoto RGB, when you view that at 1:1 in Develop, then view the same section at 100% in Photoshop or similar ICC aware app, they should match.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
"But you want to end up with a 1200x800 pixel sRGB image for web or email. You just have to render out at that size and color space and view that at 100% (1:1) for a truly accurate preview of the data. "

With NR and sharpening applied, and likely with export sharpening applied. What's wrong with doing the same at fit view? Remember, we already get that (excluding the export sharpening) in cases of high-ISO.

Repeating, this was done for PERFORMANCE reasons, not reasons of accuracy.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
Image on the left, the raw shown in Develop at Fit. Image on the right, the image exported for use on a web page (sized to 1000 px on long axis). Do they match?

http://digitaldog.net/files/Lrvsreali...
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
"Do they match?"

I think you're missing the point Andrew. The point isn't "do they match" it's "which matches better" - with or without the NR applied. You example has the NR applied. Remove the NR and it'll match even worse, and the only reason to remove it is performance.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
>I think you're missing the point Andrew.

The point I made was, the rendered image, at 100% is the right way to view the data ( "If you want to have an accurate representation of what the image will look like on YOUR screen, just look at it.") You can’t do that in LR in the example above.

My example shows that if you sample the data down, you can’t get a match anyway.
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
Andrew you write "You just have to render out at that size and color space and view that at 100% (1:1) for a truly accurate preview of the data.".

It's not an acceptable way of working for me to be forced to export an image at its target size to judge what my adjustments will look like.

It must be possible to get a very close approximation of the final rendering through the view in the Develop module. Note that I'm avoiding the term "Preview" because I'd like the Develop module "View" to be as accurate as possible, not just some "Preview".

Omitting noise reduction for the Develop module (for some magnifications) is a sure fire way to create a big discrepancy between the Develop module view and the final rendered image. The motivation for doing so is just performance. No particular "preview" philosophy is being followed here. If the rendering were always sufficiently snappy with noise reduction turned on, it would never be turned off at any magnification.

Lee and I are therefore arguing that one should get at least the option to always have noise reduction applied.

P.S.: Regarding your experiment with the two (non-) matching images, I'm not sure what it shows. Is the left one a screen grab? Are you then not just showing what I'm arguing should be avoided, i.e., a difference between a Develop view and the final output?

In any event, Lee Jay is right when he states that it is about "which matches better".
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
>It's not an acceptable way of working for me to be forced to export an image at its target size to judge what my adjustments will look like.

Sorry, its been this way since day one. Its been this way in terms of zoom ratio’s for rendered images in Photoshop since 1.0.
In terms of LR, you need to keep in mind its a parametric editor that builds a pixel based final image as the last step.

This can be a “close” approximation but then someone has to define what they mean by “close“.

In the example above I provided, the two images are screen captures from Lightroom and Photoshop when both images are previewed at the differing zoom ratio to match the size. That’s the only way you can view both the same way!

In LR, its previewing a very large raw file (5DMII). Its previewing at Fit. The other image is what I rendered out of LR from a very large raw at an output size of 1000 pixels. Now you have two options to compare the two previews. The first is to show both at 100% (1:1). Obviously you can’t compare the two, its apples and oranges (a 5000pixel and 1000 pixel file). The alternative, which is much like viewing images at differing sizes as previews in LR is to zoom out one. So you see them both at the preview size. They don’t visually match. But how could they? The data is different, one’s vastly resized down for one. That affects sharpening and noise reduction.

Going back to LR. You can preview a raw or rendered image at 1:1 for most accurate preview. But that only shows you the preview at 100% yet you can export that data to any size you wish, LR can’t possibly show you this until you do it and re import the file.

Take a high rez file with noise reduction and sharpening and view it at 100%. Now size it down in Photoshop 300%. View that at 100% preview. Do they perfectly match?
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
Here’s another example, all Photoshop!

Rendered the same high ISO image out of LR directly into Photoshop. Full resolution. Duplicated the image and resized it down 20% of original size (Bicubic sharper). The low rez file is zoomed to 100% (1:1) for the more accurate preview. The image outlined with the white border is the high rez file. It has to be zoomed to 20% to match the size of the other. They don’t match. Now I can zoom into the high rez file, it looks vastly different (and is an accurate preview of THAT data). But I can’t compare the two, one shows a vastly zoomed in preview of the high rez data.

Bottom line. With differing sized images, you have two options. Zoom out to see the entire image in which case the preview isn’t accurate. Zoom in to 100%, its accurate but only for that pixel density. Since LR has the ability to render out images of any size, the 100% preview in LR shows you that original pixel density correctly, but it can’t do this with other sizes of data it *may* render. And zoomed out, it can’t show you an accurate preview in terms of stuff like sharpening and noise reduction. You are not seeing a 1 to 1 relationship of the pixels!

http://digitaldog.net/files/LowRezHiR...
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
Andrew, which of the images on the left or right would you like to be seeing when you are editing, given that the middle one is the final exported image?
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
Thanks, Lee Jay, for reducing the discussion to a single, simple question.

My vote goes to the left one (preview with NR). Independently of the question of whether or not it is pixel identical to the final product (in the middle) it is a vastly better approximation of the final product than the image on the RHS (preview without NR).
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
Left
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
"Left"

So, if the only reason NOT to have that left one is performance, shouldn't we be able to choose to give up performance for the better quality preview of our final image, especially if we have a fast machine?
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
I don’t understand the question. Its obvious that the screen grab with NR looks closer to the export than the one without. It doesn’t match, its closer. You produced this screen grab set how in LR? Is the Left a preview at 100% as well as center? The other point yet to be proven (and we’d need an Adobe engineer to pipe in) is the idea that the ONLY reason is performance. And further, how can one render out a significantly smaller version and have the 1:1 of the raw match it. 1:1 is based on the full resolution of the raw.
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
Who says that the final exported image (the middle one in Lee's example) is at 1:1 RAW resolution?

Just assume it isn't. Then the LEFT preview makes more sense than the RIGHT preview (as you have voted yourself). Lee already said that "closer" is sufficient. Just because it might not be a 100% match, we'd still prefer "closer" over "not even close".

Regarding the Adobe engineer: You didn't need one to give the answer to Lee's question (which was "LEFT"). That's all that matters. If Adobe engineers had some further reasons, why did they change the Develop view behaviour from "Never apply noise reduction" to "Sometimes apply noise reduction"?
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
>If Adobe engineers had some further reasons, why did they change the Develop view behaviour from "Never apply noise reduction" to "Sometimes apply noise reduction"?

Did they? What causes the NO vs. sometimes? What’s the trigger? And to what degree is the sometimes used (fully, prefect match)?
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
Yes, they did. It was a change from LR2 to LR3.

The trigger is whether some heuristic yields that the absence of noise reduction will have a visible effect.

Please see Victoria Bampton's post regarding this subject. It also confirms that the only reason why noise reduction isn't always performed is performance.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
Well that’s an interesting read! It would be useful to again have an Adobe engineer comment as its quite obscure in terms of “sometimes you see it, sometimes you don’t. So presumably on a Macbook with a 5DMII, you would not see any (?) NR but on a Mac Pro with ton’s of RAM, you would?

And again, the 1:1 is always going to be more accurate in terms of viewing the pixel data compared to zoomed out, as I illustrated in Photoshop. In PS, its even more iffy depending on the use of Open GL and odd percentages of zoom ratio.

Lastly (again), if you have a raw or full rez image at 1:1, but render it out at anything but that size, when you view the smaller (or larger) rendered image, its not going to match. 1:1 (100%): show one pixel for one screen dot.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
It's not based on performance of the machine, Andrew, it's based on the camera (sensor size) and the ISO of the shot. That's one of the issues - my 7-year-old Pentium IV chose the same images to render with NR as my new Sandy Bridge machine which is 20 times faster. On the old machine, I would have preferred NEVER to have NR applied (it was really slow) and on the new machine I'd prefer to ALWAYS have NR applied (it doesn't seem to make much performance difference on this machine).

My examples were at "fit" view and my rendered (center) example was rendered at the same size as the "fit" view was producing.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
>It's not based on performance of the machine, Andrew, it's based on the camera (sensor size) and the ISO of the shot.

So the limit is based on what (sized megapixel)? I’m seeing it on a 5DMII. That’s a pretty big sensor.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
Big sensor = doesn't apply until higher ISO. Small sensor = applies NR at lower ISOs.

Noise on a 5DII at ISO 1600 isn't very visible. Noise on a G12 at ISO 1600 is VERY visible. The algorithm is based on the idea of only applying NR when it is likely to be visible.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
>Noise on a 5DII at ISO 1600 isn't very visible.

Its visible on the examples on the image I supplied (Karl with camera). ISO 12800, 5DMII. Toggle detail pane on and off, preview in Fit clearly updates (but again, doesn’t provide an accurate match). The ‘red speckles’ you refer to disappear. Hence the confusion.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
Right...ISO 12,800 makes the noise visible on a 5DII so NR is applied. Try it at ISO 400 or 800 and I suspect it won't be visible.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
>Try it at ISO 400 or 800 and I suspect it won't be visible.

Looking at a 400 ISO image, I can barely see any difference at 1:1 on or off (there’s very little noise at least in the 5DMII). Zoomed out, I can’t understand what I’d be seeing if the NR was applied based on this. In this context, its not an issue.
Photo of Lee Jay

Lee Jay

  • 990 Posts
  • 135 Reply Likes
Right....now shoot an ISO 400 shot 4 stops underexposed, and set exposure +4 and try it. This is not so far-fetched. Using the fill light and tone curve controls, it's not hard to push shadows 3 or more stops.
Photo of Andrew Rodney

Andrew Rodney

  • 645 Posts
  • 119 Reply Likes
>now shoot an ISO 400 shot 4 stops underexposed

You’re talking to an ETTR follower .
ISO 400 4 stops under equates to ISO 6400 doesn’t it?

I don’t know for sure that I’m not seeing NR with a properly exposed ISO 400 image. Maybe yes, maybe no. But I hardly see it at 1:1 so zoomed out, not sure how useful it is. And do I see any decrease in performance with this versus a 3200 where the NR is shown? Not on this machine. You want the behavior I see with the 3200 ISO on all the time? Fine with me. But again, its not an accurate preview of the NR (as to your example above, its better at higher ISO but its not how anyone viewing the preview should be moving the Detail sliders).
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
Andrew, you wrote: "Sorry, its been this way since day one."
I don't think that's relevant. Some problems present at day one have been ironed out in the meantime. This problem should be addressed as well. Note that LR has gone from "never apply noise reduction" to "apply noise reduction when (it thinks that) omitting it will be visible" in the Develop module. Apparently the LR team and you do not agree about what the correct approach to Develop views is. I agree with the LR team and only ask them to go all the way (or at least make it possible for me to chose that option).

"In terms of LR, you need to keep in mind its a parametric editor that builds a pixel based final image as the last step."
I am aware of this but note that the Develop view consist of pixels. It is just a matter of what pixels I get to see. How they were created (non-destructively vs destructively) is irrelevant (except for performance, which is exactly why noise reduction is sometimes not applied).

"They don’t visually match. But how could they? The data is different, one’s vastly resized down for one. That affects sharpening and noise reduction."
Here's how they could match: If LR internally did everything required to export a file at the size of the "Fit view" and then displayed the exported file. It would be a perfect match.

"...LR can’t possibly show you this until you do it and re import the file."
Oh, it could. It could show me what I want by doing automatically what you are asking me to do manually, i.e., export a file and then view it on screen.

While I'm arguing that this would be ideal -- WYGIWYS! -- I'm prepared to accept some mismatch between the Develop view and the final export. There could be slight differences due to perceptual rendering depending on the output format, etc. but I certainly don't want unnecessary differences in the form of omitting noise reduction to stand in the way of finding the right adjustments.
Photo of Julie Kmoch

Julie Kmoch, Sr. Development Manager

  • 102 Posts
  • 39 Reply Likes
Official Response
This has always been a tricky one for us. As Lee Jay mentions, it was an intentional choice to not always run noise reduction & sharpening in fit view because they are the most expensive parts of the pipeline, and it really can impact performance. We do hear your point that it's confusing, however, and will consider the request to have more control over it.
Photo of TK

TK

  • 531 Posts
  • 112 Reply Likes
Hi Julie,

thanks a lot for chiming in. It is great to hear from you. It is also great to hear that you will consider the request for more control.

I trust you have seen the "Selection of Fast (current) or Accurate Rendering in the Develop Module" thread. It contains a relevant discussion about this issue.

Will one of this threads obtain an "Acknowledged" or "Under Consideration" status or are these labels not really that important?

The most popular feature request on this forum (for "Photshop like Cloning/Healing Brushes") hasn't received an "Under Consideration" status yet, while less popular ones already have.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 385 Reply Likes
This problem is "solved" as far as I am concerned.