Before-after comparison: problem?

[bns]

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

[Tim Lookingbill]

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.

[Schewe]

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.

[Schewe]

I also did send a PB to Jeff Schewe.

I can repeat this...I'll pass it along as a bug. Good catch...

[bns]

I can report...I'll pass it along as a bug. Good catch...

Thanks a lot Jeff.

cheers,
Boudewijn Swanenburg

[Tim Lookingbill]

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.

[Tim Lookingbill]

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.

[bns]

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