@John-M A late response to this topic but recent tests in another thread had me creating 6 VCs and applying a preset and then selecting a ‘Color Rendering’ ‘Category’ and then one of six ‘Rendering’ options, one per VC.
When I shutdown and restart the currently utterly, totally and completely useless current DxPL(Win) feature of showing the ‘Applied default preset’ tells me absolutely nothing useful about what I was actually doing at the time of the shutdown!
@Joanna Turning options on and off are fine for those options that work that way but useless when a ‘Tone Curve’ for example is being finessed. Having a full history is not a replacement for the non-linear adjustment strategy that DxPL offers, it is an adjunct to it and one that preserves a train of edits (of thought) that can be restarted after a shutdown.
I have managed without anything useful with respect to editing history on DxPL(Win) thus far and will be able to do so in the foreseeable future but it would still be useful.
I find it amazing that some of the people who are so against this feature actually have it and don’t want it, whereas, we Windows users are only asking for something that was sold to us but does not work.
I do believe that if those people actually tried using the feature, they would realize the benefits and incorporate it into their workflow.
The argument that if one were to go back into the history will result in the loss of recent adjustments is a false argument. Yes, it will happen, however, if it were such a negative, then why is History such a useful tool in Lightroom for example? Lightroom users are well aware of this and are still able to make the History feature a useful tool. Bryan, your example of Tone Curve adjustments is a good one. HSL adjustments is another.
For me, the ability to go back to a set of photos after several days or weeks and see clearly the steps taken so far, is the main usage.
So, DXO, We Windows users want what you sold to us to work properly!! Selling defective merchandise is bad for business!!
I am a Windows user and make use of the Advanced History on a regular basis. I have had many discussions with those users who believe this feature has little or no value to them. Although I disagree with their logic, each of us has our own development expectations and workflow and I can’t fault anyone for using PhotoLab differently than I do.
I also would like to be able to have the advanced history available across editing sessions. According to @sgospodarenko’s comment in a thread that I participated in November, 2020, she indicated this feature would be added to the Windows version soon! Obviously, here we are two years later and it still hasn’t happened. But to be honest there are a number of features that were implemented before they were 100% ready on the Windows side or has never been added at all. For instance Mac users have had the ability to uniquely name virtual copies since PhotoLab ab 5. That feature never made it to the Windows version.
However, I have to disagree with your statement that “Windows users are only asking for something that was sold to us but does not work.” To the best of my knowledge being able to save advanced History over editing sessions was never sold to Windows users. The only reason these discussions take place now is because the Mac version has it. However, as I pointed out earlier, there are lots of differences between the Mac and Windows version, mostly to the Mac version’s advantage. The real issue here is that Windows users have been promised a move towards parity with the Mac version for a couple of years now, with very little progress. In fact, the differences between the Mac and Windows version have actually grown over the last 2 years rather than shrunk.
@RvL My design, development, testing, supporting and consultation experience was on a single platform and a database product that could be accessed by ALGOL or COBOL (and I wrote the latter).
I understand the statement that transfer between systems is not trivial or a “no brainer” and there have been comments that DxO have suggested that implementation on Windows is “not easy” or even “not possible”, from which my takeaway is that they are using some feature on the Mac that is not available on the Windows platform, rather than they simply can’t be …!?
However, no-one from DxO has bothered to discuss the issue with the userbase, nothing new there I am afraid, but surely it is possible to copy the stack from the memory arrays to the DOP, at the very least, and then read them back when the user revisits the image!?
This would
Provide the history and keep it out of the database and secure from database wipe outs.
Consume a lot more space in the DOP (my what a big DOP you have!? - sorry)
So I would want the features to be optional (don’t I always!), e.g. attached to the ‘ADVANCED HISTORY’ as a check box to ‘Select’ or ‘de-select’ saving the history, probably with a ‘Preferences’ option somewhere which would dictate the starting setting for the preservation of the history.
If someone actually stated exactly why it is not already in the product we could stop “arguing” amongst ourselves and simply mutter and mutter and …
Regardless of the current Mac implementation the use of the DOP without the database doesn’t seem to be rocket science to me and would keep those unhappy about the very existence of the database “happy” (if that is … sorry again). Histories could be kept for as long as they might be useful (if at all) and then abandoned to conserve disk space by reducing the size of the DOP.
Yes I can manage without a (semi) persistent history but …
I do not have a problem with others using the software differently or not using some of the tools within. I do not use all of the tools available. We are talking about a tool that was incorporated and advertised as having such and such features and is still not working properly after how many requests?
I am just saying that those who do not want to use a tool should not be so vocal against that tool’s incorporation or usage. That is the point I was trying to make.
@Allan I am not sure the exact reasoning behind users that have access to the facility on DxPL(Mac) being vocal about DxPL(Win) users wanting the facility (my crystal ball has clouded over today) except maybe
They don’t feel that the facility adds anything to the DxPL editing workflow
and they don’t want us to feel “upset” that we are “deprived” of this facility
and they are concerned that it might divert the manpower at DxO and get in the way of “more important/worthwhile” developments
or …
As a facility it has merit, but is it more important than ??? I don’t know, currently there is zero reaction from DxO to almost anything written in the forum so …
I’m not sure if you interpreted my post on this topic as being an argument against History retention across PL sessions, Allan - but, just for clarification; as I have been quoted/referred to in a few posts above …
I am definitely not against this feature being provided in PL (although, it is true that I rarely use it myself).
Instead, the reason for my post was to ensure that it’s purpose is properly understood (as I suspect that’s not the case for all users) …
There’s quite a lot of discussion about the loss of a detailed History but in a practical sense it was one of the reasons I returned to Lightroom as my main processor. Just thought I’d mention that…
They call it an advanced history. It’s not even a history as it is not retained between sessions. It was said that it was going to be put in version 6. Well, we are at version 6 and no sign of a proper history let alone an advanced history. Many a time, I have deleted my virtual copies because it is quicker than trying to remember or find which option it was that I got wrong.
Why this can’t be easily added, I do not know. All the information I should imagine is in the database and should be easily retained.
DxO Seems so intent on adding new options. Well, this would be new option for widows, as it’s in the Mac version.
The Advanced history is not based on database entries. It uses the Windows standard Undo/Redo feature and it works the same way as Undo/Redo except that Advanced history makes the entries in the stack visible. That is why Ctrl-Z and Ctrl-Y work with the Advanced history. Hopefully DxO will eventually be able to save it across sessions like the Mac version. That was the original plan but they ran into difficulties. This is just one of many differences between the Windows and Mac versions of PhotoLab.
Thanks for the info @Mark. I must admit I gave up trying to program in Windows, at Windows version 3. I didn’t like the restrictions Microsoft were putting on programmers.
I just hope they can resolve it, as it will certainly save me having to keep on deleting my virtual copies and starting again as I find it much quicker than trying to find where I went wrong.
For what it is worth, ON1 Photo Raw for Windows also does not save the visual history across sessions. Neither did Affinity Photo 1. I currently don’t have Affinity Photo 2 installed so I can’t comment on that version, but I suspect it is the same.
Some members here do not use the Advanced history at all, and do not think it is very useful. We have being having an ongoing debate on this subject here since it was implemented in PhotoLab 4. However, I am a strong supporter of this feature.
By the way, I am @mwsilvers. The handle you used in your response is someone else.
FWIW I sometimes will keep Photolab open continuously for a week while I’m working on a project with a lot of images until I complete the whole project simply because I want to retain the history until all the edits are complete.
I would appreciate if history information was retained not only in the database but also in the sidecars.
The history is not currently retained in the database or the sidecars, just in the normal Windows Undo/Redo stack. I’m not sure where that information is saved currently in the Mac version.
I don’t know where the history is kept for the duration of an image edit which is then kept for the duration of a session but as has been pointed out numerous times it survives a shutdown on the Mac but not on Windows and the database contains no fields for the history!
The edit is contained here in the database which looks remarkedly like the DOP (as it should)!
Arguably the history could be retained in the database in a similar fashion but I don’t know what issues that would create restoring it to DxPL when an image is re-selected during an edit session. So the current DxPL mechanism could be used for session management but with the addition of storing the history stack in one of the following to restore in a future editing session
The database
The DOP
Both, like the edit ‘Settings’
Personally I would accept keeping it only in the DOP and restoring it from there but no-one from DxO has discussed this issue with the forum and since we don’t know how it is actually managed in “memory tables” etc. there is actually more that we don’t know than there is that we do know!
However, please note the totally redundant fields
AppliedPresetDisplayName = "5 - No correction",
AppliedPresetUniqueName = "5 - No correction",
Which are really of little use to anyone and I have asked for something more useful to be stored here, many, many,… times e.g.
The last preset applied to an image
The last preset created from an image’s edits
Both would be even better
The history - sorry been there and said that already
While I use Advanced history quite often and would like it to be retained across editing sessions, so far it hasn’t been a major hardship for me. What is more frustrating is that, despite assurances to the contrary, the differences between the Mac and Windows versions are growing with each new release. Since similar history tools in the Windows version of ON1 Photo Raw and Affinity Photo also clear their history between editing sessions perhaps accomplishing this in Windows is a more complicated effort then we might suspect…
As I have said before. The Dop file should be the ‘single point of data’ for the image edits and the XMP file should be the ‘single point of data’ for for the meta data. Only then should the database update itself and then be used for DxO’s housekeeping. That way, there should be less chance of the database becoming corrupt.
From what @mwsilvers informed me. It may mean that DxO would have to rewrite the advanced history code.
