Lightroom Classic: Presets no longer record and apply the turn on/off settings of the Develop panels

  • 5
  • Problem
  • Updated 4 months ago
  • Acknowledged
  • (Edited)
Prior to LR 7.3, presets recorded and applied the Turn On/Off switch settings in the Develop panels (HSL/Color, Split Toning, Detail, etc.).   However, in 7.3.1, presets no longer record those, and the on/off settings in presets created prior to 7.3 will be discarded when they are converted to the new format.  

As a consequence, if you record a preset with, say, HSL settings, and then you apply that preset to a photo with the switch in the HSL / Color panel off, the preset will have no effect.  This is clearly undesired behavior, whether it is unintended ("bug") or intended ("feature").

As a workaround, you can edit the preset's .xmp file manually and add back the on/off setting, e.g. for HSL / Color, you can add this line:
crs:EnableColorAdjustments="True"
(Be sure to restart LR after you edit the .xmp file.)

To reproduce:

1. Select a photo, turn on the switch in the HSL / Color panel, and set all the Hue sliders to -100.

2. Create the preset "Hue", click Check None, then check Color Adjustments.

3. Reset the settings of the photo.

4. Turn off the switch in HSL / Color panel.

5. Apply the Hue preset and notice there is no effect. The sliders have changed, but the panel remains turned off.

6. In the Presets panel, right-click Hue and select Show In Finder. Edit Hue.xmp in a text editor and notice that there is no setting that records the on/off state of HSL / Color. (Prior to LR 7.3, this setting was called "EnableColorAdjustments".)
Photo of John R. Ellis

John R. Ellis, Champion

  • 3871 Posts
  • 1023 Reply Likes

Posted 7 months ago

  • 5
Photo of Patrick Philippot

Patrick Philippot

  • 408 Posts
  • 84 Reply Likes
This reply was created from a merged topic originally titled [7.3] Preset Live Preview not always reflecting the actual preset.

I just noticed something that I consider as a bug : when
hovering the presets, I observed that some of them had absolutely no
effect on the full Live Preview. Very strange. Until I realized that the settings modified
by the preset and located in a disabled development panel (switch button at the top left corner of the panel set to Off), are not taken into account.

This is questionable. The live preview should show
the full effect of the preset by temporarily re-enabling the setting
panels that are switched off. Otherwise, this doesn't make much sense.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3870 Posts
  • 1023 Reply Likes
As Robert Somrak discovered, the live preview does in fact accurately reflect what will happen when you apply the preset.  The problem is that presets no longer record the on/off switch state of the Develop panels, as they did prior to 7.3.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 4291 Posts
  • 819 Reply Likes
This reply was created from a merged topic originally titled [7.3] Preset Live Preview not always reflecting the actual preset (merging).

I am following this thread now, Patrick and will report back as to 'as-designed' behavior as soon as the team responds. We will decide where to take it once we have their response.

Note: This conversation was created from a reply on: [7.3] Preset Live Preview not always reflecting the actual preset.
Photo of Robert Somrak

Robert Somrak, Champion

  • 176 Posts
  • 47 Reply Likes
This reply was created from a merged topic originally titled [7.3] Preset Live Preview not always reflecting the actual preset (merging).

If you change the behavior to preview the preset with the panel switches on than then when you apply the preset should it automatically turn the panels switches back on?  If you don't than the user will get a DIFFERENT unexpected behavior than the original issue, the photo won't look like the preview.

Note: This conversation was created from a reply on: [7.3] Preset Live Preview not always reflecting the actual preset.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 4291 Posts
  • 819 Reply Likes
Update: The current behavior is reported as-designed however I have logged it with team to have them look at changing the behavior in a future release. 
Photo of John R. Ellis

John R. Ellis, Champion

  • 3871 Posts
  • 1023 Reply Likes
I changed it from Problem to Idea.  But it does seem a little unusual that they'd change the long-established behavior of presets like that.
Photo of Patrick Philippot

Patrick Philippot

  • 408 Posts
  • 84 Reply Likes
Now I see another problem with this new behavior. The previous .lrtemplate format had provision for the state of each setting panel in the development module :

            EnableColorAdjustments = true,
            EnableDetail = true,
            EnableGrayscaleMix = true,
            EnableLensCorrections = true,
            EnableSplitToning = true,

There's apparently no corresponding tag in the new XMP format, as mentioned above. So, this information has been lost during the conversion from the old format to the new. Even if the previous behavior is restored in a future release, the only way to recover the information about the state of each setting panel will be to convert again the old presets... if they still exist (since they are no longer used, I had deleted them from my system - fortunately, I could restore them from an old backup).

I have noticed that the translation is triggered automatically as soon as presets not prefixed with ~ appear in C:\Users\<user>\AppData\Roaming\Adobe\Lightroom\Develop Presets. So, if Rikk succeeds in his attempt to convince the development team to go back to the previous behavior, a backup of the presets in the old format will be needed. If they have not been deleted, it will be necessary to remove the prefixing ~ in the preset names to trigger a new conversion.

Once again, the transition to version 7.3 seems to have been rather thoughtlessly managed. Too many obvious bugs that could have been spotted before release, unwelcome behavior changes,... As I already stated elsewhere, there's a problem with the QA dpt. at Adobe. If there's still one. I doubt.

We can't spend time "re-learning" LR and chasing bugs each time a new minor version is released. Doing regression testing is not our job. Adding features is nice as long as this doesn't break the user's workflow. LR has to adapt to the users and not the contrary.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3870 Posts
  • 1023 Reply Likes
Patrick, you can add these Enable* settings to a preset's .xmp file using a text editor. See the first post for details.
Photo of Patrick Philippot

Patrick Philippot

  • 408 Posts
  • 84 Reply Likes
Ah, thanks. I didn't read the first post after the merge.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3871 Posts
  • 1023 Reply Likes
I just released the free Fix Presets plugin that corrects this problem by automatically adding enable settings for the corresponding develop settings in each preset..

The plugin also provides workarounds for a number of other develop preset issues.
Photo of Patrick Philippot

Patrick Philippot

  • 408 Posts
  • 84 Reply Likes
Thanks very much, John.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3871 Posts
  • 1023 Reply Likes
Though the 7.4 release notes say this issue is "fixed", unfortunately it is not.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 4291 Posts
  • 819 Reply Likes
John,

I ran the test in the original post and it is working for me. Can you elaborate?
Photo of John R. Ellis

John R. Ellis, Champion

  • 3871 Posts
  • 1023 Reply Likes
I did a little more investigation. The new behavior is almost that of 7.2, but not quite, but it probably handles most of the common use cases.  However, you can no longer create a preset that turns a panel's "enable" switch off; if you try, LR just silently and confusingly fails.

The engineers will probably designate this "as designed", but it is certainly a change in behavior from previous versions.

Details:

In all versions through 7.2, presets would capture the value of the "enable" switch in a panel and  the value of the panel's sliders, regardless of whether the switch was on or off. 

Now, in 7.4, presets still don't capture the value of the "enable" switch. But when applying a preset, LR will turn on a panel's enable switch if the preset sets any of the panel's settings to a non-default value (the most common case).

But with this new behavior, it isn't possible to create a preset that turns off a panel's enable switch or turns it on without changing slider values. For instance, you can't create a preset "Detail Off" that turns off the Detail panel's switch or a preset "Detail On" that turns on the panel's switch without changing any slider values.

If you try to create the "Detail Off" preset, LR creates a .xmp file in the presets folder, but confusingly, it never shows up in Preset panel (another buglet).

Previous versions of LR would write the enable switches to the preset, whether they were on or off. E.g.

crs:EnableDetail="value"

Internally, as visible through the SDK, the panel switches are still visible via photo:getDevelopSettings(), and a plugin can turn them on and off using photo:setDevelopSettings(). So the mechanism for the prior behavior is still there.

Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 4431 Posts
  • 1638 Reply Likes
ACR doesn't have toggle switches, so I suspect you're right about it being as designed, but I agree it's confusing.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3871 Posts
  • 1023 Reply Likes
Also, note the inconsistency between presets and copy/paste and sync of settings. Copy/paste and sync correctly copy the enable settings, but presets do not.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3871 Posts
  • 1023 Reply Likes
On reflection, I don't think this was by deliberate, considered design.  Even though ACR doesn't have toggles in the UI, it continues to obey the values of the enable settings (the toggles) set by LR when opening a raw + XMP sidecar.  This is easy to demonstrate: In LR's HSL / Color panel, move all the Hue and Saturation sliders to the right, turn off the panel's toggle. Then do Metadata > Save Metadata To File.  Open the raw in ACR, and observe that the color adjustments aren't visible. [See Robert Somrak's follow up below.]

Given all the changes in behavior of the new preset implementation, I think it's clear that the responsible engineer didn't understand the existing develop settings as used by LR and ACR.
(Edited)
Photo of Robert Somrak

Robert Somrak, Champion

  • 176 Posts
  • 47 Reply Likes
John,
If you look at the XMP sidecar in the above situation the HSL slider values are ZERO so when you switch a panel off the XMP is saved with default values of zero and not what the sliders are set at so naturally ACR is reading zero values.

This can be also demonstrated by doing a reset on the file in Lightroom and then reading the XMP file.  The switch in HSL is on and the settings are zero and not the values that were in the disabled HSL panel when the XMP was saved.

Hopefully I didn't misunderstand what you were referring too.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3871 Posts
  • 1023 Reply Likes
Ah, I missed that, thank your for the correction. I had mistakenly assumed that the develop settings stored in the LR catalog and accessible via the plugin API were written unmodified to the .xmp sidecar.  But that's wrong in the case of settings whose panel is disabled.
Photo of G0apher

G0apher, Employee

  • 37 Posts
  • 18 Reply Likes
John, yes there is the inconsistency between presets and the copy-paste/sync behaviour. This has been filed as a bug to investigate with the concerned team.

Thanks for bringing this up and with all the details.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3853 Posts
  • 1011 Reply Likes
Thanks for the update.
(Edited)