(Managed to post this first in the Lightroom 3 forum. Trying again ...)
I have given Lightroom 4 beta a spin on my last month of photos. Here are a few observations I've made so far.
1. The Clarity slider is now a totally different beast than before. The effect is much more pronounced and quite different. A lot more tonemappish:
Lightroom 3, Clarity: 100
Lightroom 4 beta, Clarity 100
2. In general, switching from process 2010 to 2012 seems to be a bigger change (to contrast/tones) than it was from 2003 to 2010. It won't be simple batch convert operation for me at least.
3. Several of the items on my wish list have come true! (RGB curves, local WB adjustment.) I also love that pick flags are global. The old behaviour really got me a number of times.
4. The WB picker now samples a larger area when zoomed out. It is still unclear exactly which area it is sampling. Sadly it doesn't seem to sample the entire enlarged loupe area. Perhaps it only samples the middle pixel (marked with a cross hair) but for some reason the sampled WB value varies with the scale of the loupe, even if the pointer is left over the exact same pixel.
5. There is still no way of applying sharpening in the slideshow module, which means I still have to export my photos and either re-import them or show them with a separate program (I use FastStone for this).
6. The contrast slider also provides slightly more oomph at 100 than before.
A few minor bugs/issues:
- When using the new sliders Whites/Blacks, the history item says "White Clipping"/"Black Clipping". This is perhaps intended?
- The "Noise" slider for local adjustments should perhaps be labeled "Noise reduction" since a higher value removes more noise. (Alternatively the slider/effect should be reversed.)
Anyone else with similar experiences?
Yes, on all counts.
1. Clarity is stronger and now tone-mapped, so it is a different effect. You'll need different values.
2. Definitely don't batch convert if you don't want to reprocess. The new look is so different that the automated upgrade is a starting point at best.
3. Excellent!!!
4. It's sampling the area you can see in the loupe, so when you're zoomed out, you're sampling over a larger area which is useful for noisy images.
5. No, you're right.
6. Yep, that sounds right.
White/black clipping - yes, that's the 'proper' name for the sliders, there just wasn't enough space.
Noise - yes, probably a space issue again
Victoria Bampton wrote:
Yes, on all counts.
1. Clarity is stronger and now tone-mapped, so it is a different effect. You'll need different values.
2. Definitely don't batch convert if you don't want to reprocess. The new look is so different that the automated upgrade is a starting point at best.
3. Excellent!!!
4. It's sampling the area you can see in the loupe, so when you're zoomed out, you're sampling over a larger area which is useful for noisy images.
5. No, you're right.
6. Yep, that sounds right.
White/black clipping - yes, that's the 'proper' name for the sliders, there just wasn't enough space.
Noise - yes, probably a space issue again
About nr 4. I devised a simple test, and it doesn't seem to use the whole loupe area. I sampled from a white area with a green line through it.
When I sample just next to the green line I get a fairly reasonable WB value:
However, if I center the picker over the green line I get a very different value. (Taking care to move the cursor only horizontally, to keep the amount of green in the loupe ~constant.)
This is repeatable too.
Would be great to hear from someone who knows how this actually works. (Would be even better if it actually did use the entire area.)
A better test is keeping the location fixed and only vary the sample window size (use the scrollwheel) and compare the resulting temp and tint. In my test, I can confirm that the result temps and tints are different for different sample window sizes (expected). I traced through the code and confirmed LR is passing throught the sample window size correctly. The difference in appearance is largely due to the difference in tint values computed in the two cases.
-Simon
My testing agrees with Simon's. The Loupe covers more pixels when the image is zoomed out, and it indeed seems to take into account all pixels in the loupe. On the other hand, David's test seems to contradict ours, and the images he posted are quite compelling. I don't know what to think.
Hal
Yes. Essentially the pixels you see in the WB sampler window is the area that will be used for WB computation. One could use the scale slider or the mouse scroll wheel to change the sampling window size.
In davidnaylor83's example, the resulting tint values changed between the two sessions (10 -> 88), that could explain the signficant change in appearance. In theory, a larger windows size should minimize that. Maybe the WB computation is still sensitive to small variations in the sample averages.
I did a quick test with an artificial TIFF image:
I cannot do the exact math, but the tool seems to be behave exactly as it is now supposed to.
If the area is all gray, then I can use any location in the image, even close to the other color and I get the same WB. But as soon as the sample window gets polluted with the purple pixels, the WB changes.
Sample window size also behaves as it should.
So, this is perfect for me ![]()
I agree with slarti3’s observation that the entire loupe area is being sampled. I also checked the affect zoom has the sample area.
At 1:1 zoom view the loupe is mapped 1 pixel per box, allowing adjustment with the Scale slider from a 5x5 pixels to 17x17 pixels sample area. As you change the zoom view the pixels being sampled increase linearly, with 1:2 zoom mapping 2 pixels per box (10x10 to 34x34 pixel sample area), and the maximum 1:16 zoom view mapping 16 pixels per box (80x80 to 272x272 pixel sample area). This is a much welcomed improvement over the current White Balance eyedropper tool’s fixed 5x5 pixel area.
I ran some White Balance tests using ColorChecker Passport images. Sampling the gray scale patches using the largest 272x272 eyedropper loupe and zoom setting produce very consistent readings. With LR3’s 5x5 pixel sample the readings vary all over the place due to sensor noise and minor surface irregularities in the ColorChecker patches.
slarti3 wrote:
I did a quick test with an artificial TIFF image:
I cannot do the exact math, but the tool seems to be behave exactly as it is now supposed to.
If the area is all gray, then I can use any location in the image, even close to the other color and I get the same WB. But as soon as the sample window gets polluted with the purple pixels, the WB changes.
Sample window size also behaves as it should.
So, this is perfect for me
This is really strange. I'm testing myself now with the following image, and it makes no difference if the blue line is directly under the cross-hair or somewhere else in the loupe.
So with TIFFs at least it seems to work perfectly as intended. I need to go back and test on more raw files, I know I wasn't imagining what I saw before! (And still can see in the screenshots above...)
(Scroll to the end for the conclusion.)
Okay. I have now done a semi scientific test of the WB picker with the following shot of a white paper with a red line down the middle.
(For the record taken with my 7D, converted CR2 -> DNG on import.)
I set the image zoom to 1:16 and scrolled the loupe to maximum size (17 squares), which in theory should average 16x16x17x17 = 272x272 = ~74 000 pixels.
The following WB value, 6750 K and tint +14, was pretty typical for the white area to the right.
I was able to find pixels that gave exactly the same WB values even thought the red line had entered the 17x17 loupe:
Even this close to the red line I could find pixels that gave the above WB value:
Not until the red line started entering the middle 3x3 boxes did it affect the WB:
The more centered the red line is in the middle 3x3 box, the larger effect it has on the WB:
Here fully centered:
As we move to the left of the red line, the WB values become more normal again:
Once it is out of the 3x3 box, the value is pretty much as it was to begin with:
I converted the image to tiff and got the same results. Only when the line entered the middle 3x3 box did it affect WB.
So this must mean: At zoom level 1:16 and a loupe size of 17x17, LR4 is sampling no more than 3x3x16x16 = 48x48 = 2304 pixels.
Since LR seems to be treating raw and tiff in the same way I intend to make a synthetic image with a 1 pixel line to test 1:1 zoom and other loupe sizes.
So I created an 8-bit tiff image with a neutral grey (~80% brightness) background, the same size as my 7D file (5184x3456) and drew a 1 pixel red line down the middle.
I re-did the test at 1:16 zoom and loupe size 17x17.
Strangely, the red line (very faint in the zoomed out image) only affected WB when it was either dead center or directly to the left of the cross hair.
If the red line was directly right of the cross hair the WB went back to 0/0 again:
Now, if you think that was weird, have a look at this.
If I scroll the loupe to 5x5, or in fact any other size than 17x17, the red line doesn't affect WB even if it is right under the cross hair:
Zoom 1:8
With the line directly left of the cross hair, it only affected WB at loupe size 17x17. I got the same result with the line directly to the right.
With the line centered under the cross hair it affected WB more and more the smaller the loupe size. Here 5x5:
Zoom 1:4
Now the red line affects WB when it enters the middle 5x5. But only at loupe size 17x17! (And it then affects WB equally wherever it is in the middle 5x5.)
With the line directly left or right of the cross hair it affects WB at loupe sizes 17x17 down to 9x9, but not 7x7 or 5x5!
With the line centered under the cross hair it affected WB more and more the smaller the loupe size.
Zoom 1:3
At loupe size 17x17 the red line now affects WB in the 3 lines to the left, the center, but only 2 lines to the right:
The results for the other loupe sizes were equally weird and erratic, I can't really be bothered to list them all.
Zoom 1:2
At loupe 17x17 the red line now affects WB in the middle 9 lines.
With the 5x5 loupe the line affects WB in the middle 3 lines.
Zoom 1:1
The red line now (finally!!) affects WB in all positions, at all loupe sizes. Here 13x13:
Conclusion:
I have no idea!! Pls help me.
Edit:
Ok, well one conclusion is this. At zoom 1:1 Lightroom seems to actually use the full loupe for the WB picker. However, at all other smaller zoom levels (1:2 ... 1:16) Lightroom only uses a smaller section of the loupe. And the number of boxes used in the loupe varies with loupe size!
This is weird beyond belief.
OK, I think I finally worked it out!
Zoom level doesn't affect the actual number of pixels sampled, only loupe size does. So the number of image pixels sampled is always = the number of boxes in the loupe.
The problem is, zoom level affects the view in the loupe. (Loupe shows display pixels, not image pixels.) However, the WB sample size is always the loupe size in image pixels.
Was that even remotely comprehensible?
davidnaylor83 wrote:
OK, I think I finally worked it out!
Zoom level doesn't affect the actual number of pixels sampled, only loupe size does. So the number of image pixels sampled is always = the number of boxes in the loupe.
The problem is, zoom level affects the view in the loupe. (Loupe shows display pixels, not image pixels.) However, the WB sample size is always the loupe size in image pixels.
Was that even remotely comprehensible?
That sounds like exactly what it's supposed to do.
Lee Jay wrote:
davidnaylor83 wrote:
OK, I think I finally worked it out!
Zoom level doesn't affect the actual number of pixels sampled, only loupe size does. So the number of image pixels sampled is always = the number of boxes in the loupe.
The problem is, zoom level affects the view in the loupe. (Loupe shows display pixels, not image pixels.) However, the WB sample size is always the loupe size in image pixels.
Was that even remotely comprehensible?
That sounds like exactly what it's supposed to do.
From the release notes:
"White balance sample area is now zoom-level dependent"
I think there is a bug. I created a large TIFF file with 10 pixel red vertical stripe down the middle and get the same behavior as davidnaylor83 discovered. There also appears to be a fixed loupe pixel sampling area, which is independent of zoom view setting (i.e. 5x5 up to 17x17 pixels at all zoom view levels). So this statement by Adobe is apparently incorrect:
"White balance sample area is now zoom-level dependent."
The reason I didn't pickup this behavior is because the ColorChecker patches I sampled are all neutral grayscale seperated by an also neutral colored black frame. The readings are now more accurate, but only because the sample area is increased up to 17x17 pixels (from LR3's fixed 5x5 pixels).
trshaner wrote:
I think there is a bug. I created a large TIFF file with 10 pixel red vertical stripe down the middle and get the same behavior as davidnaylor83 discovered. There also appears to be a fixed loupe pixel sampling area, which is independent of zoom view setting (i.e. 5x5 up to 17x17 pixels at all zoom view levels). So this statement by Adobe is apparently incorrect:
"White balance sample area is now zoom-level dependent."
Glad to hear you found the same thing.
If the loupe is to show "display pixels" (zoom level dependent pixels) as opposed to "image pixels" (1:1 pixels), it must also use the display pixels (or all the underlying image pixels) to determine WB. The current behaviour feels illogical.
simonsaith wrote:
Yes. Essentially the pixels you see in the WB sampler window is the area that will be used for WB computation. One could use the scale slider or the mouse scroll wheel to change the sampling window size.
I would definitely like to challenge that. Just did the same test again I conducted a few days ago.
But this time I made the image larger than the display area.
My conclusion: Simon's statements holds true for 1:1 zoom. But at 1:2 I can see that exactly 1/4 of the area gets sampled. The more you zoom out, the less pixels of the little preview window get sampled. Or in short: The sample window always has the same absolute size.
So, definitely a bug in the program according to the beta specs.
simonsaith wrote:
"The sample window always has the same absolute size"
Correct. I'll follow up with the documentation. Thanks all.
Is this the intended behaviour? If so, it would be much more intuitive if the WB loupe always shows 1:1 pixels, independent of image zoom. (So what you see in the WB loupe is what you sample.)
That would probably make the WB loupe very fidgety at small zoom levels like 1:8 and 1:16 though, so I still feel the best would be if WB sample size was dependant on both zoom level and WB loupe size.
davidnaylor83 wrote:
That would probably make the WB loupe very fidgety at small zoom levels like 1:8 and 1:16 though, so I still feel the best would be if WB sample size was dependant on both zoom level and WB loupe size.
I agree. It would be more intuitive if what you see in the WB sampling window is what should be used for WB computation. I just fixed this so that the WB sample size is dependant on both zoom level and WB loupe size. The new behavior will be in the final release.
simonsaith wrote:
davidnaylor83 wrote:
That would probably make the WB loupe very fidgety at small zoom levels like 1:8 and 1:16 though, so I still feel the best would be if WB sample size was dependant on both zoom level and WB loupe size.
I agree. It would be more intuitive if what you see in the WB sampling window is what should be used for WB computation. I just fixed this so that the WB sample size is dependant on both zoom level and WB loupe size. The new behavior will be in the final release.
Wow, great news! Many thanks!
North America
Europe, Middle East and Africa
Asia Pacific