Don’t you simply enable local adjustments by clicking on a tool and leave it by deactivating the tool by clicking on it once?
So basically the same like the horizon tool, crop tool, spot weighted tool… ?
That’s because, from DxO’s PLv7 design perspective, (since the demise of the big "Local Adjustments button), there is no longer the concept of 2 modes … Global & Local.
Like you, however, I find this often confusing and really annoying !!
There’s more, and broader, discussion on various issues related to PLv7’s new approach to Local Adjustments here … with links to requests & suggestions that you can vote for.
1 Like
That’s true only if you leave the LA button active. Otherwise, you don’t see these tools. But leaving the LA button active is actually masking access to the other panels. Once you returned to the any other non LA panel, you have to click again on the LA button to access the LA tools. In the Windows version, at least.
I still find V6 much easier to use for local adjustments. The constant clicking to get done what was one click and a key press does is frustrating
Done. I think the problem is that the DPL UI doesn’t seem to be designed as a finite state machine. Designing an UI this way allows to make it more consistent and easy to manage in a centralized way.
1 Like
Isn’t that true for every panel/toolset or whatever a group like that is called? You need to open it or click on it to bring it into view to access what is in it?
I click on the mask tool that I want to use, set the points or lines or whatever, then click on it again to deactivate and make my adjustments. Never had the issue of accidentally setting a control point or adding a brush stroke or erasing a mask (under Windows).
I’m adding my vote for the switch between local & global adjustments to be made simpler. Let’s hope the devs are monitoring this forum!
A few readings about Finite State Machines
You don’t need to be a programmer to understand the concept. This may shed some light on the reasons for which the DPL UI is not consistent enough.
Why is there even a need for a global or local mode?
All that is needed really is a baselayer/the image layer itself and all the rest ought to be “local”.
End of confusion
1 Like
Let’s open our minds for a moment. While having to actively switch between GA and LA (be it with layer or button approaches etc.) can make things easier to understand, a possibility to edit globally and locally at the same time could present an added value nevertheless.
Imagine you do a LA and find that there needs to be a change in GA before proceeding with the LA. Having to actively switch between modes can become a real pain if the adjustments need to be done iteratively, going to and fro between GA and LA.
If we keep tools as they are in DPL7 with separate palettes for GA and LA, all that needs to be made certain of is, that DPL reliably applies adjustments within the scope of the respective palette or tool. This is how things work in Lightroom, but PhotoLab does seem to mix scopes occasionally, which I’d call a bug - or suboptimal thinking and testing on DxO’s side.
I still fully agree that PhotoLab should have easy-to-use and reliable GA and LA features.
Fully agreed. This is why I referred above to a design based on a finite state machine. The FSM basic rule is that, at a given moment, the machine (here, the application UI) can only be in one among a finite number of precisely defined states. Each time this rule is broken, bugs and inconsistencies appear.
Every state in the FSM accurately defines which input will trigger which transition and lead to which new state. GA and LA are 2 different states because they accept different inputs and identical inputs may trigger different transitions. Identical inputs triggering different actions should not co-exist in a given unique state (e.g. a state where GA and LA are simultaneously active). However, this is exactly what the current DPL UI is trying to do and that breaks the rule.
I should also add that a given state of the FSM should be clearly identified by the user by a specific view. Just looking at the UI should make the user immediately aware of its current state. Currently, deactivating the LA button while not deactivating the current LA tool, switches to another view corresponding to the GA state while the LA state is still active. This leads to a state/view inconsistency which is reinforced by the fact that the LA button is not lit.
1 Like
Let’s look at another example
This screen capture describes a very strange situation :
- The WB color picker icon in the top toolbar indicates that we are currently in Global Mode.
- The LA button is enabled. So, the LA tools are displayed.
- The LA list indicates that a Luminosity Mask has been created.
- The Luminosity Mask icon is deactivated, I can select the “Sky” LM in the list but this doesn’t activate the LM tool icon.
- The LM settings are displayed and enabled after I clicked on the Sky entry in the list. Acting on them modifies the area covered by the Luminosity Mask although this tool is not selected.
- The mouse cursor is still the Global Mode color picker.
Maybe we now have an explanation about why we don’t have a color picker for WB and HSL in LA mode ? But just imagine the confusing situation if the WB settings in the Luminosity Mask had one. With an FSM-based UI design, this could not happen.
I found myself in this situation after making a global WB modification and returning to LA mode. You said confusing 
?
1 Like
I’d rather like it so that the user can choose a default option for the type of LA they wish to use when the LA panel is active and they click on the image.
Like you, I use control points most of the time.
I keep selecting the LA palette and then moving the mouse to the image to click on it to create a CP, and repeatedly forgetting to first click on the CP icon before moving the cursor to the image.
That’s not actually so - and, that’s the key UI design problem, I reckon;
Despite it being positioned slightly apart, this 
is not a Button, it’s a Tab …
- just like any of the other GA tabs:
The user experience would be much simpler and clearer IF this control was acting as a Button - to switch between Global and Local modes.
I don’t see any advantage at all in the concept of PL being “modeless”;
- On the contrary, we’ve all been trained (via the big “LA” button in PL pre-v7) to accept the concept of the LA & GA modes being quite separate … and it’s never been a limitation that I’ve ever been aware of.
Even when/if we need to move between LA & GA modes … such as in this scenario;
-
One still needs to activate one of the GA tabs (or none, to reveal one’s default Workspace) in order to change from interacting with one of the LA tools (on the LA Tab) to one of the GA tools … and vice versa;
– So, it’s not a process that gets in the way - it’s the natural way of working within PL -
… and it would be MUCH less confusing if doing so were to deactivate LA mode in the process - so that the last-used LA tool is not left visible (and “orphaned”, without its corresponding sliders being available) on the main screen.
Yes, this situation is one of the weirdest (and, therefore, most confusing) aspects of PLv7’s new LA user-interface;
I reckon most users are assuming that the LA Tab ( 
) is switching us into LA mode … despite that not being the case at all … as explained in my previous post.
-
On this typical assumption, it’s then reasonable to expect to be able to click on the “Sky” LM (in Patrick’s example) to be able to work on its parameters/sliders, etc … BUT, bewilderingly, that’s not the case - because we’re NOT yet in LA mode !
-
To actually activate LA mode, we need to click on one of the LA Toolbar items … and, it doesn’t even need to correspond to any of the currently applied LA tools !!
-
- Now, LA mode IS activated … and now we can work with one of the currently applied LA tools (such as the “Sky” LM)
It’s bizarre !! …
Instead, a clear state of being in LA mode –OR– GA mode would resolve all this confusion …
- And, the obvious way to do so would be for the LA Tab to actually function as a LA-mode Button (which is exactly how the majority of us think of it functioning in any case).
What do you mean by “tabs”? Palettes or tool panels? Many of the latter activate themselves as soon as e.g. a slider is touched, although some need to be switched on before sliders can be moved. Not that I use slider for all things that change something, sliders, buttons, magic wands etc.
Hi Mr. P … All the best to you for the NY
I mean one of these: 
…
- These are Tabs - which reveal groupings of Palettes/Tool panels
- Or, in the case where no tab is selected, one’s own groupings (Workspace) are listed.
The LA-tab on the far RHS is just another Tab (to group LA-specific Palettes/Tool panels)
– as argued above, it w/be MUCH better if this Tab acted as a LA-mode Button
I call them “view filters”…but I see what you mean. Thanks.
All those tabs do, is to hide the tools that don’t belong to the predefined categories and sort the presented tools in a predefined order which cannot be changed by the user. The tabs are DxO’s response to our requests for something like Lightroom’s Solo Mode. I must say that I do prefer Lr’s approach and Lr’s way to group sliders into groups and what could be called palettes. It’s less fragmented than in DPL and saves many clicks.
Capture One provides tabs in the left dock/sidebar. This feels more logical to me than the somehow “grown” mix of things.
Whatever the implementation might be in a near or far future, the scope of a tool should be defined by the tool alone and should not depend on what was last used. If the scopes were clearly defined and adhered to, things ould be much easier to handle. Maybe there is a well concealed logic in making tools dependent on past actions…but I feel that this is creating more issues than it solves.
Yes, exactly … Where the confusion arises is that many of us think of the LA-Tab (the one on the far RHS) as a “mode-toggling” Button - to switch between LA and GA modes … BUT, unfortunately, it’s actually not !