Confirm Auto Preset behaviour

So a recent poster to the FB group noted that if you go to a module that is inactive and go directly to the preset menu and create a new preset and give it a name and save it to auto apply to all images that the result is a no-op. Clicking the preset menu does not by default activate the module and if you make no changes to the module it is also not activated however you are able to save that as an autopreset. I think he was under the impression that this would for example add dehaze with the default settings.
I think this might be rare as generally you are altering the default to create a preset or working with the module in an activated state nevertheless the result is an entry for the module that appears in the history stack which isn’t much use as it was never activated so really stepping back to it doesn’t achieve anything and selecting steps in the history does not reposition you to the module in the the editing pane or anything so its not really a place holder. THere may be a use case for this behaviour but I could not think of one but perhaps there is a reason that it is set this way. In any case it caused confusion for this user.

My comments to him were…

“Thinking about this a bit more…this may be a bug or have a use case I cannot think of. I was actually talking about styles in my previous comments to you and not presets. They will capture the state of the module so you can add a style that has a number of modules…it might be your default workflow with your common settings defined for each however they can all be in the inactive state…now as you edit you sequentially activate them or maybe you have some active but say noise reduction or some others initially inactive but ready to be applied by simply activating them with your settings and not the default ones for that module. So there is a use case here. But i tried your experience by going directly to a module and asking it to be auto applied without activating it or setting any parameters. As a result it will add the module to the the history stack but it is not activated and no edit is ever applied. I would assume you thought it would be applied with the defaults?? Most people when saving a preset will make some adjustment so this will likely never happen but in your case your initial steps gave you a null result… As I said there might be a use case for that setup but I think its just that for the most part not many if any have created the auto preset using your steps…”

Your comments seem like perfectly reasonable use cases. I use inactivated-but-auto-applied presets for quite a few modules so that they start in the state I want them in, and not the out-of-the-box defaults. I then enable and tweak them as required in my preferred workflow order.

For example, I occasionally use shadows and highlights (I know, I’m a rebel) but prefer it to default to a no-op (shadows/highlights settings at 0/0). This way I just need to enable it and tweak a single slider if I need it. Similarly I have default noise reduction settings that I want to be off by default because of the processing time, and because my images don’t always have noticeable noise in them.

It does seem odd to choose to do this without changing any settings, but we can’t always prevent users from doing odd things.

1 Like

Ya it fooled me a bit too when he first asked but I guess if you go strait to something like dehaze it could fool someone in to thinking its not really working if you make no changes. You go to dehaze and select preset, auto, give it a name and then leave all parameters blank so it applies to all images. If you had made a change then its like a style with inactive modules ready to activate with your settings, the use case being an inactive module with your custom settings when you do activate it. It semantics but it might be worth adding to the manual that he state of the module is saved in both presets and styles…I’ll have to double check but I don’t think that is currently in there and at least for this user he thought that creating the preset would apply the module with defaults… I guess as almost any other action performed in the module does activate it?? Maybe just a one off case…