Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: bns on June 03, 2018, 04:47:02 am
-
For some time I have a problem with the before-after comparison in the development module of Lightroom. My suspicion of something “funny” going on dates back quite some time, way before LR Classic I think.
Lately, working on images with a lot of dark tones, I got worried.
I use the before-after comparison – either the sequential comparison using the “\” key or the side by side “Y” key - a lot when making the last subtle adjustments to an image.
I turns out that using the before-after comparison between two identical development states, the comparison shows a difference. I have tried to make this visible with the attached figure.
Left is “before”, i.e. the original image, right is “after”, that is after pushing the development reset button. The dark tones in the before image are noticeably lighter than in the after image. The tones in the after image seem to be the same as in the original.
I suspect that something similar goes on in the softproof mode.
Has anyone seen this kind of effect? What is wrong with me or with my system? Any ideas?
Configuration: LR Classic 7.3.1., Windows 10, display Eizo CX271 calibrated with i1Display Pro, set at 5500K, 80 cd and white-black ratio 250:1.
Cheers,
Boudewijn Swanenburg
-
To my eyes the right image is very, very slightly more saturated/darker than the left image, but one needs to look long and hard to perceive any meaningful difference, so the problem is unclear (to me from my well-profiled NEC PA271 monitor) from this presentation.
-
Hi Mark, thanks for your reaction.
I have imported the screen shot displayed above again into Lightroom. Then I read the Lab values of the discrete greyscale steps at the bottom of the image.
The values below the block labled 24 (the brightest of the dark blocks) reads 14.7 0.0 0.0 in the left (before) image and about 11.8 0.0 0.0 in the right (after) image.
To me that is a significant difference, where zero difference is expected.
Boudewijn Swanenburg
-
OK, the difference is there if you measured it. I can't explain it. When you push Reset does EVERYTHING go back to exactly the way it is portrayed in the "before" state? If it does, there should be no difference, but perhaps something that was adjusted doesn't reset?
-
Yes, the two versions are absolutely identical. I verified that by measuring the pixel values of the before and after images in single view.
I would very much appreciate if you could try to duplicate my observation on your system with one of your images.
At low tonal values the effect is most pronounced.
If the effect is real, it looks like to be a Lightroom bug. If it cannot be reproduced, my system must have a problem.
By the way, I see the same effect on a non calibrated laptop.
thanks,
Boudewijn Swanenburg
-
I'm using Lr 7.1 using Mac OSX 10.11.6, so I'm not sure anything I test would be determinative. Whatever I find leaves open various possibilities with the one exception being that if I can replicate the problem we can say it's an application issue. If I have anything in Lr that is useful for such a test I'll do it. Need to check.
-
OK, I have the same Outback printer test photo in my Lr catalog so I pulled it up, made a huge Exposure adjustment, then clicked Reset, then pressed Y for the Before and After view and measured all the dark patches from 2 to 24 in the grayscale ramp containing the two ends of the scale (very dark and very bright patches) in the Black surround. In both the Before Image and the After image all readings are identical for the same patch. The Before state = the After state in each image and the same patch # has the same value in both the Before and After image versions. So I see nothing wrong with Lr 7.1 in OSX 10.11.6.
-
Yes, in the individual images the values are identical. But if you viually compare the before and after image ("\" key works best) don't you see a difference? The before patches beeing lighter?
-
I did that - I compared the Before and After images with both on the display so I could readily pass the eyedropper back and forth between the one and the other, and as I said, for the same patch the value is identical for the two states. I think this is conclusive that at least here there is no issue to report.
-
Hi Mark, thanks for your effort.
At my side I get the same result with the Eyedropper. But vsually I see a difference.
Could you possibly make a screenshot of the before-after comparison with the "Y" key, and measure the pixel valus form that?
That is where I got the difference.
Boudewijn Swanenburg
-
You are welcome.
I don't consider it reliable to take measurements from screen shots which have been manipulated from the original state of the images themselves. Reading directly off the Lr representation of the raw file is the only scientific way to do this and if the numbers are the same the visual impression should be the same; I don't understand why in your case you see a difference. Is it possible that your monitor illumination is uneven? Anyhow, here is a screen-grab of what I see.
-
Just thought I would mention that you don't actually "know" the current "before" state that is used unless you explicitly set that state, or remember when it was set. The before state can be any step in the history, and LR does seem to have an unusual behavior on what it does to the default before when you do things like reset the image. To make sure the before state is what you believe it is is to right click on it and set that step to the before.
This may not be relevant, rushing to an appt so sry I don't have time to read the OP in detail right now to understand the full problem in that post, but on the off chance it might be pertinent I thought I would throw this out there (and also sry if this was mentioned in a follow up post).
-
Hi Wayne,
Thanks for coming into the discussion. Yes indeed, you have to define the before state by right clicking on it. That is one of the nice things about the comparison feature. One can compare the current state, with any of the previous states
What I did, was comparing the state after Reset, with the state after Reset again i.e. two absolutely identical images.
@ Mark
Thanks a lot for presenting your screenshot. I downloaded it, imported in LR and used the eyedropper to investigate the pixel values. I agree that pixel values from screenshots may not be the most accurate in absolute terms, but for a relative measurement it may be OK.
The L values I get from your image are:
Block 8: left 12.3 and right 14.0
Block 16: left 5.7 and right 9.2
Block 24: left 3.0 and right 5.1
I am almost sure that if you would toggle between the before and after image with the “\” key, you will visually confirm that there is a difference between the two.
I repeated my previous analysis on a cropped version of the same image. The result is attached. "Before" is up, "After" is bottom.
This makes the difference more easily visible.
While fine-tuning the appearance of (deep) shadows in an image, I find this effect very disturbing and I would very much like to pinpoint the cause.
Boudewijn Swanenburg
-
You're right. Doing it by using the "\" key produces different values in the deep quarter tones. I can also confirm this happens whether or not one has edited and then reset the image. So there is something going on here between the two states ("Before" loaded/not loaded) that needs to be explained. It's either an application bug going back some time or there is some deep dark reason I, at least, am unaware of. Thanks for your persistence on this one! It should be reported to Adobe for follow-up.
-
Thanks, Mark.
The "funny" thing is, that in the adjacent before-after display, using the eye dropper, one reads the same values, but the brightness is different. It looks like the before and after versions are using different lookup tables (or transformations) between data and display.
As I have no experience with contacting Adobe, could you possibly suggest a way to bring this problem to their attention?
cheers,
Boudewijn Swanenburg
-
Hi Bouewijn,
Adobe has a Lightroom site for reporting problems, here: [type]=problem]Lightroom-Problems (https://feedback.photoshop.com/photoshop_family/categories/photoshop_family_photoshop_lightroom?topic-list[settings)
That said, I have no idea how effective it is. But worth a try.
-
I wonder if it relates to the previews generated either upon import or otherwise before going into Develop.
-
Thanks, Mark.
The "funny" thing is, that in the adjacent before-after display, using the eye dropper, one reads the same values, but the brightness is different. It looks like the before and after versions are using different lookup tables (or transformations) between data and display.
cheers,
Boudewijn Swanenburg
Just speculating but does this happen at 100% zoom views or smaller?
I know in Bridge CS5 the main preview and thumbnails render in sRGB (which is encoded in that non-standard oddly shaped gamma curve that resembles the behavior of that gray ramp). I can hunt these truncated previews in my OS's Bridge directory and get info indicates they're tagged in sRGB.
I don't do any Auto/Reset process to check if shadows are affected similar to your situation. I've never had this problem in LR4 except I have to have a matrix color space like ProPhotoRGB set in Soft Proof or else black and shadows look a bit milky in Develop module compared to how the same file looks in Photoshop where there is no milky shadows.
It may be that at certain zoom levels the sRGB preview takes over and doing anything Auto to it references it's non-standard gamma curve space.
-
@ John
Thanks for the suggestion.
I now compared two states with all kinds of edits in between. At one point I make a snapshot. Then I apply various edits. Recall the snapshot and compare. Exactly same effect, most noticeable in the dark tones.
@ Tim
Good suggestion. But no. I tried 100% view and may other zoom levels. Same effect.
Different rendering of separate previews could certainly be a cause of the effect. Don't know how to verify.
@Mark
Thanks. I'll try to wake up Adobe.
I also did send a PB to Jeff Schewe.
-
One thought, if you are comparing an image that has been reset, reset doesn't actually reset the image to how it was when it was imported, it resets the image as though you are importing it again. So if anything has changed from the time you first imported the image (such as the newer version of LR that might be using different profiles) there might be a difference. An example I ran into recently, if you change a camera default to apply some modified settings (such as a different profile) , all you have to do to apply that new default to images already imported is to reset them.
Random thought. I just imported a series of images, made some changes to a few, reset them, and then compared, and I'm seeing identical before afters.
-
One thought, if you are comparing an image that has been reset, reset doesn't actually reset the image to how it was when it was imported, it resets the image as though you are importing it again. So if anything has changed from the time you first imported the image (such as the newer version of LR that might be using different profiles) there might be a difference. An example I ran into recently, if you change a camera default to apply some modified settings (such as a different profile) , all you have to do to apply that new default to images already imported is to reset them.
Random thought. I just imported a series of images, made some changes to a few, reset them, and then compared, and I'm seeing identical before afters.
You are right. But, if you have time, I would appreciate if you could do the following test:
- take any image that includes some dark tones.
- do any edits you like, or pick any of the edit steps you may have done already.
- make a snapshot, call that 'before'. Apply that snapshot, so your 'before' edit step is marked.
- do any series of additional edits.
- recall the snapshot ‘before’.
- make at that step a snapshot called ‘after’.
- right click on the snapshot step ‘before’ and make that the before state.
- click on snapshot after.
- the screen displays the after state.
- press the “\” key: the screen now shows the before state.
- use the eyedropper tool and pinpoint to any position in the image.
- the Lab or RGB values show the before and the after values. They are identical, as they should.
- do the same in a dark area of the image. The Lab or RGB values before and after are identical, as they should.
- So, the before and after data are identical, as they should.
- Now, make sure your screen background is dimmed, and toggle the “\” key repeatedly.
If you don’t see any difference in the dark tones of the image, your system does not show the problem Mark and I are seeing. Please tell us your secret.
If you do see a difference, somewhere there is an annoying editing problem, because we edit with our eyes, and not with numbers.
Cheers,
Boudewijn Swanenburg
-
I think what's being missed by bns's long list of procedures in LR is that he's indicating the numbers are not matching up with the preview after the reset test.
I've always suspected in Adobe and other third party image editing apps that black point appearance on calibrated/profiled systems seem to experience a sort of hiccup. I suspect none of these apps are designed to be this precise and consistent with how they map data to previews. I mean xmp edits I've applied to Black slider number in CS5 ACR or any other slider setting will be off by maybe one or two numbers after opening the image a week later.
If my black slider was at 2 and the next editing session later it's now at 1 or 3 as now recorded in the xmp rider makes a huge difference to shadow appearance but I never remember the actual RGB number I set absolute black (usually 5RGB which may change to 3 or 7) in any of the shadow detail. Even Jeff Schewe mentioned this years back on trusting xmp to not become corrupted.
And then there was the LuLa thread I participated where a poster with the best high end calibrated/profiled display system posted screengrabs of a variety of black 0RGB appearances in the same image across a wide variety of image editing and viewing apps that hadn't even been touched. No one could figure out what was going on.
This might be such a case. This could be an issue with a lack of consistency and precision with data/preview in a color managed system.
-
Even Jeff Schewe mentioned this years back on trusting xmp to not become corrupted.
I never said that...what I actually said is I didn't trust .xmp files to not get separated from the raw file thus losing the parameter settings. I NEVER said anything about .xmp files themselves being prone to corruption–they aren't any more prone to corruption than any other file and if you are having issues with .xmp files' settings getting changed, I would immediately back up your hard drive and quite using that drive.
Seriously, .xmp file settings don't just spontaneously change on their own.
-
I also did send a PB to Jeff Schewe.
I can repeat this...I'll pass it along as a bug. Good catch...
-
I can report...I'll pass it along as a bug. Good catch...
Thanks a lot Jeff.
cheers,
Boudewijn Swanenburg
-
I never said that...what I actually said is I didn't trust .xmp files to not get separated from the raw file thus losing the parameter settings. I NEVER said anything about .xmp files themselves being prone to corruption–they aren't any more prone to corruption than any other file and if you are having issues with .xmp files' settings getting changed, I would immediately back up your hard drive and quite using that drive.
Seriously, .xmp file settings don't just spontaneously change on their own.
In the fog of my memory that far back, Jeff, I do remember you using the word corrupted in that conversation on xmp sidecars and yes, I did remember you saying you don't trust xmp files which was part of a workflow strategy discussion on the concern of having a huge collection of Raw files that were not cooked/saved to tiff but whose edits were assumed would be preserved forever in the form of xmp sidecar for future improvements to Raw converters.
I've had xmp slider numbers change from CS3 to CS5 across two Mac systems the ten years I've been processing Raw files and never did I lose one image or experience a hard drive failure.
So you remember saying it one way and I understood it to mean something more in regards to future proofing large volumes of xmp sidecar edits to Raw images.
I still back up on occasion. But this issue with slider numbers changing happens all the time and I'm not so sure it's on account of a hard drive failure.
-
One more point about moving these sliders in ACR is that sometimes the slider will feel stiff or drag or become slow as the number changes to the correct number like say for example +20. I save to xmp as usual to lock in the edit and close the file. Work on other images for a while come back later and the number is now +19. This applies to all sliders but not at the same time. Maybe one or two slider numbers will change like this.
Sometimes the slider isn't so stiff and moves with ease along with the changing of the number. This behavior has been going on for ten years on in ACR on both Mac systems. I never complained because I thought I just had a slow computer. I never lost one image. In fact I've never lost any file since I started on the Mac since OS 8 in '98 on a tower system, then a Pismo Powerbook, then an iMac and now a 2010 MacMini.
This sluggishness with the slider movement could be a USB mouse and keyboard related issue. Don't know. This slider behavior still continues.
-
Thanks a lot Jeff.
cheers,
Boudewijn Swanenburg
I just discovered by accident:
The behavior depends on the “Use Graphics Processor” option setting. If the GPU option is checked, the unwanted effect is there. If the option is unchecked, the behavior is as it should be.
Cheers,
Boudewijn Swanenburg