As of DPL 4.1.2, the first entry in the “advanced” history reads “Default Preset”
Please replace or enrich this non-information with the actual name of the preset that was used as a default.
Thank you
attn. @StevenL
3 Likes
Seems to be a Mac only issue. The Windows version shows the name of the default preset.
Mark.
On Windows 10 it shows the name of the preset, yes. Nevertheless it could, should in my opinion, be a drop list of what correction(s) this preset activated and what settings were applied. It would be good practice and something DxO already does for any other Preset that we activate afterward, even the “No correction” preset, with more logic than we could think at first, since “No correction” deactivate all Auto correction, which is worth mentioning.
1 Like
While I suppose it would be nice to have for some people, I’m not sure how necessary it is compared to the many other history updates that need to be implemented. With regard to the default preset, each of us sets it up a based on how we want the starting point of our editing to look. Therefore, presumably we know, or should know, what that default preset does.
Mark
1 Like
…unless we change the preset from time to time (as I do) and would like to know without having to find out…
The only reasonable way under these circumstances is to set NoCorrection as default and then add the preset that fits the series, making the first entry obsolete…
@platypus What you describe is a good workaround. I am all in favor of adopting these alternative workflows since it is obvious that the development resources dedicated to PL is clearly are limited, in proportion, no doubt, to the serious challenges the team faces up when creating such original tools as DP and the new TSL.
@platypus @mwsilvers Nevertheless, I don’t think that what I’d like to see would be such a big effort, since anyone can, within the history, find what the default preset just by… reapplying it… 
Another workaround also consist into selecting the default preset in the history and toggling the little switch, top and right of the palettes, that reveals all active correction tools.
Still, the code already exist, it’s obvious and likely need only to be migrated to make the UX consistent.
I don’t think that it would be that hard to implement since the code already exist. The amount of benefit, the priority to accord to it, the impact that it would have on the sales of PL5 are all things that I can’t evaluate and that I leave to DxO with confidence. I guess that I’ve become fussier since I am learning Raw Therapee and Darktable : I am getting used to the fine granularity of the control that these programs afford their users.
I’m perpetually bemused over indications that users actually look at the history list to see which corrections were applied to an image: Why not simply scan the correction panels ?! … The “DxO Advanced” workspace provides a very quick & easy means of doing so - - - What am I missing ?!?
John M
I use the history list for most of the images I edit. What you propose won’t tell me the order of the edits that were performed or give me the ability to immediately jump back to a specific earlier point in the editing process.
The fact is that while editing I often decide I am no happy with the direction things are going and want to go back to the point in time when things started to go awry so I can try a different approach. Some people suggest using virtual copies for that purpose and I often use them myself, but VC’s provide far less flexibility
If like some people I only applied a small number of edits to any given image the history list would probably not be very useful, but I often apply a very large number of edits to my images making a history list almost indispensable.
Mark
1 Like
Why do you need to know the order in which you applied your corrections, Mark ? (You do know that, with PL, the order in which corrections are applied makes no difference - Right ?)
John
2 Likes
…if it exists, why not make it friendly?
2 Likes
Actually, it is only in regard for the final result that the order of totally different correction tools does not matter. What matters though is finding out where in history (aka “when”) the change was made if we want to branch out from there. Moreover, the order in which settings to one given correction tool matters since only the last will be taken into account.
2 Likes
I think I covered that in my previous response. I’m not sure how I can explain it better, but I’ll try. I also used the history list when I was a lightroom user, and I use it extensively today when I’m in Affinity Photo. It’s not unlike using the older undo stack except its current ease of use greatly expands how I use it on a regular basis.
It gives me infinite possibilities for developing the same image with different branches. It allows me to quickly go back in time on the fly to change or remove earlier edits or to create a VC snapshot and then move forward again.
I may have anywhere from a couple of dozen to a couple of hundred edits in an image depending on my goals for it. With the application of that many edits I am still able to work very quickly. There is a huge amount of interaction between various sliders so your approach simply would not work for me in a complex editing situation and would not allow me to quickly return to an earlier state with a specific combination of edits and settings. A visual history list is obviously not important to your workflow, but it is a very important component of mine. .
Mark.
You are very much entitled to your way of doing things but what surprises me is that you can actually tell which edit out of several hundred you want to go back to, especially when the setting of one tool may have been changed tens of times, in both directions - all you end up with is the final value because all the previous alterations were overwritten.
I remain firmly in the camp of those who just go back to a tool and readjust it, because that doesn’t undo all the changes to all the other tools on the way back to the point I thought I wanted to be at.
1 Like
Not an issue. I was a computer programmer and analyst, software designer, and system development manager for over 35 years. In my earlier years I programmed and managed several large systems for JPMorgan Inc. mostly written in IBM 360/370 Basic Assembler Language (BAL) and was responsible for maintaining and debugging several million lines of assembler and PL/1 code. I have always had excellent attention to detail, although as I get older it is not as good as when I was young. Working with a couple of hundred edits for an image and knowing where in the list I want to step back to is a piece of cake.by comparison. I have also spent hundreds of hours playing with slider combinations and I am very comfortable with the relationships between them. Being retired gives me plenty of time to learn the nuances of PhotoLab.
Mark
Yikes! My time was spent in the higher level languages: Pascal, C++, Clipper, Delphi, C#, Objective-C and finally Swift.
As time went on, I really had to write more comments in my code; it was just too complex to remember and the folks that took it over wouldn’t have stood a chance 
I worked mainly as an independent consultant who had to write a lot of code to show the developers how to implement my designs. I reached retirement age last year and occasionally I write my own apps for macOS and iOS, just to keep the brain from ossifying.
But I still prefer version control (virtual copies) to a history list
1 Like
Funny.
I started wirh RPG2 in a time when monitors didn’t exist yet. For myself later on with Pascal, Clipper for the dbase functions and tried VisualObjects. I still use for my administration the clipper programs, althoug I had to move them to Harbour, a window shell around the dos based clipper progs.
George
1 Like
In my earliest job we did not have monitors either. I wrote all my code on coding sheets and we had a bank of people typing the program instructions to Hollerith punch cards. In that job most of the assembler programs I worked on had almost no documentation comments in the code to help me understand the functionality. Trial by fire.
It seems we have a bunch of old programmers gone out to pasture 
Being very analytical with a lot of attention to detail can be both a blessing and a curse!
Mark
In lower machine languages like BAL sometimes I would need to write around 10 instructions just to format and print out a line on a report. It required a huge amount of coding for not a whole lot of functionality. I had to identify the address of the data and load the data to be printed based on its hexadecimal address in memory, calculate the length and displacement of the data to format the print line, move characters to the print line, and so forth.
Mark
Unless someone is learning the program there are rarely hundreds of steps, well, there shouldn’t be that many if it weren’t for the problems of PL’s history, especially with local adjustments. Also, it does not take too many steps to see if an edit is going in the wrong direction.
You are one who, it is obvious, has a profound knowledge of PL. Maybe, probably, you do not need to experiment as much as I do.