Absolutely. But, as I mentioned, it would mean adding custom keys in the XMP file, for virtual copies - not exactly rocket science and would solve all sorts of problems.
Agreed. There is absolutely no reason why DxO shouldn’t follow MWG to the letter. The problem seems to be that they are trying to appease folks using other DAM solutions that don’t follow MWG
Only fivefold?
I once acted as consultant/designer for a project that “connected” a Windows app, written in Delphi, with a Java data provider. I started by laying out the “interface” between the “provider” and the consumer and wrote a JNI wrapper for the Windows client to talk and listen to.
The Windows team created dummy data behind a proxy data provider, for testing and, when the time came that the two sides were both ready, it took changing only three lines of code to point the client to the real provider instead of the test one. It’s simple if you follow the rules
and I think that it’s not necessary. DxO has more than enough food for thought and adding more of the same will not help imo.
If DxO should have questions about what to do and why, they can ask their questions here, like they have done in the past on a few occasions. I feel that a lifelike discussion should be initiated between DxO and people on the Forum and others, but I fear that its a) difficult by messaging and b) that it’s not going to happen, in spite of all the possibilities like webex, Zoom etc. or c) it’s already taking place behind the scene •
It seems to me that DxO could do with some external IT consultants to help with their design, so why not offer your services to them @Joanna and others specially since you @Joanna are already in France
From the lack of enthusiastic response, or even dialog, here, I think there might be a tad of “not invented here” syndrome and I gather DxO use Agile methodology - something, from my experience with other companies, that can severely affect flexibility of thinking. But I hope I am wrong.
Although I am not a fanatic about not updating multiple copies of data at the same time, multiple databases is a whole new thing entirely. Why bother when a well designed and well programmed single database is fine. Some metadata is going to exist in the editing database anyway as part of the editing process so why split it other than to take advantages of Mac OS features that are not available in Windows which make maintenance even more difficult!
More in common between version than not, perhaps.
Because the DOP is effectively an audit record of the database. It can be carried between systems, if done carefully. It can be used as long term storage of edits and metadata. But if inadequate it needs to be improved not dispensed with altogether (please remember Virtual Copies - which you did in a later comment).
The DOP is not intended to be an active component of the system just an audit at a point in time. Some are copying DOPs off and keeping a history of editing attempts/possibilities!?
But they wouldn’t lose everything @Joanna because the data will be recovered with AS(OFF) from the DOP and thanks to the latest change with AS(OFF) the DOP will be used in preference to the metadata even if the metadata is actually later than the DOP. I don’t hate the change I just hate the way it was implemented and I hate the lack of any attempt to use metadata in preference to the DOP.
Because DxO appear to consider the metadata from the DOP as a DxO addition to the database the so called ‘Conflict Resolution’ code is not triggered. Herein lies my real gripes about DxO development, half-hearted or half-cocked or both but certainly inadequate (at times).
Adding metadata to PL5 does not trigger the ‘S’ icon when it conflicts with the image metadata because according to one response I received from DxO it was never intended to!
The same applies with the 5.3.0 release with the data taken from the DOP, no check with the real metadata and no ‘S’ flagged under any circumstances!
If you don’t put it there then the only other place is back into the image. I like the two-stage process it means that if I discover that DxO have got it wrong it is up to me to not write it back to the image. On a serious note when I started PL5 Beta testing I did envisage a situation where there might be shoot progress data in DxPL that was kept separate from the main (real metadata) and was used to progress work with the customer.
This would require a greater metadata separation but the export option I suggested to take metadata from the image directly to the exported image to avoid the “my metadata has been corrupted” situation would actually do that nicely @Musashi@sgospodarenko!
The scenario you described worked fine for me did you have AS(ON) or AS(OFF), mine were done with AS(OFF) when the keyword metadata will be taken from the DOP!
@Musashi and @sgospodarenko please start talking to us because the implementation of the IMatch alternative keyword strategy of PL5.2.0 and the reversion to the DOP strategy of PL4 but now with a huge amount of metadata effectively blocking the metadata from the image on first discovery or not based upon the AS(ON) or AS(OFF) settings are just … words fail me!
This one seed sorry seems (how and why did I type seed) to work (on Win 10)
After internal discussion, here are the actions we will work on for a future version (PL 6.0.X).
1/ Preference to apply all KW hierarchy to an image or just the selected child
We will add a preference to apply all KW hierarchy or just the selected one, this preference will be added in the Preferences menu.
2/ Compatibility mode
We will add a preference to add the keywords hierarchy in “DC subject”
3/ Option to search for whole KW hierarchy or just selected KW
We will add an option to choose whether to search the whole KW hierarchy or just the selected one (via contextual menu on the token or option button in search field with list of options, this is work in progress)
These additional developements will be planned for a release close to the PL6.0 launch.
We hope this will suit you and will answer positively to the majority of questions here.
I wrote this but had not completed and posted when the welcome post from @musashi copied to @sgospodarenko@CaptainPO@kettch@alex@Marie was posted. I have made some amendments to the posts but feel that whatever points I was trying to make are still valid.
@KeithRJ Why “pay” for what is on offer for free!?
To be honest the “metadata” not meeting guidelines is an “easy fix” but without that and a means for keyword pass through the product is currently worse than useless for me (to start using it for metadata) and for others who want their metadata preserved @Musashi@sgospodarenko.
If DxPL is the last link in the workflow chain then the export mechanism must work the way that the users wants/needs it to work regardless of whether that meets any guidelines or not (other than the users “guidelines”)!
Otherwise the metadata must then be (re-)adjusted after export, the so called “DAM sandwich”, or I’m DAMned if I do but well and truly DAMned if I don’t or something like that.
The major problems are
Bugs of a minor or major form that “litter” (“litter” not “flood” or “blanket”) the PL5 build and have become evident during close scrutiny of the keyword implementation in particular.
Unnecessary and " crudely" implemented reactions to perceived user complaints without proper consultation and evaluation which then lead to an even worse situation.
Unfinished good ideas that are going nowhere, deliberately it appears, namely the so called ‘Conflict Resolution’ the major part being ‘Conflict Detection’ followed by a simple way of the resolving any conflicts easily. Or rather detecting any conflicts between external metadata and DxPL but not the other way around because who needs that feature. That element of the product is half-way to being useful now please finish it properly rather than provide some excuse that it was never intended to be a complete well-rounded solution!
A development team that appears to be snowed under with work and I sometimes feel that the support staff at DxO are not held in high enough esteem and that the software engineers are “revered” as “gods”. The support staff should be the “champions of the user” and the “guardians” of the companies reputation and not someone that needs to go “cap in hand” to anyone (that was the way I was treated in my own company, as the “champion of the customer” where I was front line support for most of my career, albeit I started as UK support for the database product for the first 2 years). Is there something profoundly wrong inside the development infrastructure that is leading to such a patchy reliability record and a complete absence from the forum when topics of importance are being discussed which directly impact the usability of the product in one particular area or another. I stand by this statement even after the welcome post from @Musashi and others including @CaptainPO.
Agile is the last thing that the DxO development seems to have become! It appears to be mired in the legacy of the metadata implementation which I believe has actually exposed issues that have been in the product for some time.
Some (most) are actually minor fixes but I do not want DxO to monitor this or any other topic and then quietly go away and repeat the PL5.2.0 (change to the ‘dc’ fields) or PL5.3.0 (revert to the PL4 DOP handling methodology but by hijacking a PL5 feature) without discussing it openly and actually developing a solution for all, does the new post from DxO change this statement!?
If that means adding more options to the sacrosanct ‘Preferences’ @Musashi then do that or add another ‘Metadata Preferences’ to the ‘Edit’ menu. In the world of metadata handling most packages have some options that allow users to tailor the keywords in particular. Some improvement here then!
In truth there are “hidden” options that “came to light” (to me at least) while investigating this topic namely the impact of this (which are arguably a powerful set of capabilities albeit ones that may well infringe the odd guideline or two @Joanna)
or this
or this
or this
Resulting in this from the now “damaged” PL5.3.1 versus the DxPL5.1.4
The reason that I discuss implementation strategy at such length in some of my posts is not to show what a good designer I am (that’s a given - ) but to try to open the eyes/minds of the DxO developers to the possible routes to a “better” or “fixed” product at the very least, since I am concerned about some of the decisions that have been made and the thinking behind them as evidenced by this topic in particular.
I have just seen the post from DxO and need to digest exactly what it is promising; other than we will need to upgrade to get access to these “new” features!
But @Musashi I am very puzzled about the issue I “tripped” over, prompted by a discussion with @Joanna, as to the original intent of the design I considered a “bug” in this topic!?
@nwboater I understand that but want to assess whether that goes far enough with respect to the issues raised in this topic and others and once again we have a DxO reaction to forum posts that may be “well formed” or “badly informed” by other posts upon which I and others then base our comments.
Actually they are promising them for PL6.? rather than PL5. So they will not be around until after September/October and only if you purchase an upgrade to PL6 (which I am likely to do anyway)
I could promise my wife that I am going to “fix” the leaking tap but does that mean take it apart and replace the washer (difficult if it is ceramic), replace the leaking tap with a new one that may or may not match the old one, rip out the sink in a fit of pique and replace all the taps and the sink and discover the new sink doesn’t fit the cut-out in the work-top and anything in between.
Exactly what do DxO think they mean, the “devil” is in the detail?
We float ideas and make complaints and hurl insults in the forum but so far DxO’s reactions have been “misinformed” either because we are not being explicit enough (I tend to overdo the explicit enough by a huge amount), or DxO is misunderstanding or both!
Listening and promising action is good but what I would like to see is DxO actually reaching out to users and actively interacting before deciding on the final design and the implications of that design, with these changes DxO is not exactly exposing the “crown jewels” of the product and NDA’s can cover a wide variety of things not just a Beta test !
Before DxO offer us a beautifully crafted “chocolate teapot”, good to look at, good to eat (perhaps) but useless as a teapot and prone to melting in a hot room etc.
Hopefully DxO will stick to the MWG guidelines until they get everything working correctly and no bugs.
That should mean easier maintenance and less code writing and most of all keep the meta data in the XMP file and not the DOP file. That will make one SPOD for the meta data in the XMP file and one SPOD for the imaging editing in the DOP file. Again making coding easier to maintain.
@Prem they can get all the advice they want but if you look at the spreadsheet pages I included some posts back you will see that the packages do not all agree with Capture One but DxO comes close but only with all elements of the hierarchical keyword assigned!
But many users don’t want that, they want exactly what their DAM put into the image so DxO needs to accommodate those users as well or risk continued dissent (a polite word for the actual reaction contained in the topic with f… etc in the title).
If DxO follow the MWG guidelines at least there dam will be correct. If you are expecting DxO to program and be compatible with all other dam programs. You are expecting them to do an awful lot of programming which should not be their responsibility as you can see from some of these postings. Some customers are expecting the nigh on impossible. I still think DxO should get their software running properly before worrying about being compatible with software that does not meet the standards.
Yes, I think that idea is left over from the thought that the PL DAM might possibly have been better packaged as a “plugin” like FP or VP. Not all users want DAM functionality in much the same way as other users might not want the FP and VP functionality. Developing it “in isolation” would have meant that folks who feel it necessary to delete the main database to overcome problems moving files didn’t feel so wary, in case they also lost their metadata.
As others have said, over the years, DOP files have become their fundamental record of changes, with the database simply acting as an indexing and caching mechanism.
As someone who regularly trashes their database to fix file reorganisation issues I would strongly contest that assertion.
What I am getting at is that it is possible to run PL with no DOPs or XMP files, just the database - something that scares me silly.
I guess this is because DxO regard any changes made by them as “the new truth”, replacing all past truth. From what others have said, this appears to be quite a pain point because some want the metadata format imposed by another DAM to be respected.
If by saying “back into the image” you mean into the XMP, why not?
I always have AS(ON) otherwise I could not scrap the database when I needed to. And it was testing this situation that revealed that a single, top-level keyword does not get restored from the DOP if the database is scrapped (@Musashi please note)
As others have said, thank you for letting us know that you are taking notice of our discussions but could I please ask that you don’t make any knee-jerk reactions to what we have said, including my 2¢ worth.
This needs clarifying. Do you mean in the (non-RAW) file, the DOP, the XMP file or the database?
This I don’t quite understand, unless you mean ensuring complying with MWG guidance by ensuring all keywords mentioned in lr:hierarchicalSubject are recorded.
Failure to record all such keywords will impact heavily on your item 3/ - in that, although you might be able to work something out for a search in PL, without all keywords present in dc:subject means that other software, like the Spotlight search in macOS, will not be able to search effectively.
Something inside by brain keeps telling me that 2/ and 3/ are just two sides of the same coin and only one option may be necessary (discuss)
Exactly. And I think the answer is that DxO would much rather get all this free consultancy from us, as experienced developers and analysts, as well as possibly rather autistic or OCD
As of PL5.1.3, metadata handling seemed fine and to guidelines. I could confidently work with it, Capture One and my app without any conflict. As I have often (possibly too often) mentioned, I have absolutely no need for DAM functionality as part of PL and it would seem that it is only really when PL’s DAM is used in tandem with certain other software that it starts to fall down.
I think I mostly agree with this.
… and this.
I don’t have any problem with infringing guidelines, as long as it doesn’t cripple functionality - as evidenced by the mess it causes to external searching and lack of compatibility with other DAM providers.
That’s what I like to see - a bit of humility
I was employed as a consultant by a major international business software house to “rationalise” their codebase as it had gotten somewhat “spaghetti-like”. Fortunately, the managing director, who also wrote the initial version, wasn’t too precious about his legacy code and, much to my surprise, decided to start from scratch on a completely new codebase, whilst part of the development team maintained the legacy app in the meanwhile. We mutually agreed that constructive argument was “a good thing™”, sometimes having multi-day “arguments”, where we would both try to prove the other wrong. What we ended up with was solutions that blew us both way with the shear genius that could have only come from more than one brain
I couldn’t agree more with your post. To my mind, any options should be based on
I am not suggesting compatibility with other DAMs from the start of the furore I have asked for only 2 things;
Compliance with standards
A pass through for all users who effectively want DxPL to keep its “paws” off their lovely metadata.
Item 2 has some “nasty” implications if a user breaks their own rules and starts adjusting the ‘Rating’ in DxPL for example (the most likely potential infringement) what should be carried forward and how do you allow the user to configure such a “pick and mix” scenario, if you allow it at all, but that is what design is all about:
enumerate the possible scenarios
enumerate the solutions
pick the cheapest or those that offer the most “bang for the buck”
block those scenarios you won’t/can’t handle or offer limited value for the investment
or something like that!
But don’t leave a giant hole for unsuspecting users to fall into, i.e. document what can and can’t be done with the product don’t leave it to “idiots” like me to waste huge amounts of time doing “boundary” tests when they or other users vanish down “rabbit” holes!
I am not sure that they want or expect anything except their favourite RAW editor, they simply don’t like what is on offer because it bends their metadata out of shape…
Now as for me, but that is a whole different story. I’m afraid that I don’t think that any of this is that complicated which makes me irritated when it seems to require so much effort to start the ball rolling.
The table shows more similar if not identical scenarios (right or wrong) than it shows radically different ones. Photo Mechanic and Capture One stand out for different reasons and Photo Supreme is not there because my tiny brain cannot handle the way is demands categories!
I think that PL5 drew flack from PM and IMatch users and the change in PL5.2.0 was to effectively implement the output from IMatch except that the output in question to the ‘dc’ fields is controlled by a pair of options from which there are 3 different combinations.
The original PL5 correctly followed one scenario, another scenario is similar to other packages and not my choice under any circumstances and the other scenario is the same as the one implemented on PL5.2.0 where it becomes the mandatory choice (no option at all).
I purchased a license for IMatch when it was on offer at Christmas but it is a bit of a behemoth and I would welcome something simpler. But the author, the frequency of releases, the release discipline and release notes are exactly what any developer should aspire to and light years away from DxO who don’t …
This is the output from a test currently running on my Test machine for A - “Animal”, B=“Mammal”, C=“Bear” and D= “Black bear” with PL5.1.4.4728 on Windows 10.
PL5-1-4_4 is the result of selecting B (“Mammal”) but automatically selected A as well and PL5-1-4_5 is the scenario with “Mammal” and “Black Bear” selected and PL5-1-4_3 is all selected which correspond exactly to what you are showing
I have to admit I have no knowledge of the workings of the metadata but what you have written Joanna certainly looks logical to me. I certainly would like to see DxO get their coding working correctly resulting in minimal maintenance and only additions for any bright ideas. Once they achieve that that will allow more time for improving the image editing or adding to whichever maybe, my time for bug fixing and more time for bringing the 2 versions more compatible.
Agreed that is what one gathers from the many and varied problems when the put the worn image with the wrong DOP to the wrong database and get Virtual Copies, so they dump or clear the database first!
It is whether you agree or not you are simply using it to you advantage. DxO consider the database to be the “holy grail” hence the fact that the database entry is always the [M[aster in any battle and the DOP the [1] slave even if the data in the DOP is more up-to-date that the database!
Arguably not entirely true with Lightroom but the third time I used it for testing the database was declared as corrupted so I threw it away but lost everything (I was not and am not an LR expert). It would be a scary notion but that is why you have the image and the DOP.
I was told by DxO that the feature was never intended to handle two way conflicts, if I made the changes I should know the score! I was not and am still not impressed. That is not an excuse for leaving the “ship” half painted, either “laziness” or the economics of actually implementing it with other pressures on budgets. I want the equivalent of LR and suggested that the pointed end of the ‘S’ could be used to point at the direction of the mismatch(es).
The bulk of the code is there already, someone is trying to cut corners and I am not impressed (not that that counts for anything).
Because some users are trying to keep DxPL generated metadata away from the image!
That is the reason that I have written more responses than you can shake a “cat” at when ‘Rating’ and ‘Rotation’ have been lost when users believed that the PL5 DOP would preserve the data. It does for PL4 DOPs, it is there but remains unused for all options pre 5.3.0.
On PL5.3.0 they changed the rules but instead of providing an option to use DOPs as a metadata input they tied it to the AS(OFF) setting! So now we have
AS(ON) retains pre PL5.3.0 rules and no metadata is taken from a PL5 DOP
AS(OFF) If a image is discovered for the first time with a PL5 DOP the metadata will be retrieved from the DOP but not from the image
If I wrote that into a play no-one would believe it @Musashi!
I am pedantic not autistic nor OCD. I do not know how much the audience know about the subject and English is not the first language for many users and my thought processes can lead to a rather stilted and slightly non-liner English. i.e. there is actually a simpler way of putting it but redoing it yet again gets to be a real …
5.1.4.4728 on Windows 10
Hmm!
I understand but it requires a certain amount of understanding on both sides and currently there is way too much coming only from the forum and not the other way.
I am certainly not doing this for the “good of my health”, nor the copious accolades that I receive(not) (in truth I sometimes feel that the “finder” of “bugs”/problems are seen as the cause of the problem)!?
I want a more lightweight set of DAM features available and doing what they should be doing!
Any and all changes in functionality (other than turning something that fails into something that works - and even that can be problematic because users can be using a “fault” as a feature) should be implemented in such a way that the old is preserved and users can elect to use the new as and when they are ready (or not at all).
PS this topic is becoming “long post nirvana” or should that be “long post hell”!? Replies to that comment are not solicited and will be treated as a “bug”, i.e. an unwanted feature.
That was what was so amazing about our “relationship” - we both gave each other the right to say that they were wrong, even when we knew they were right, in order to make the other prove, beyond all doubt, what they were proposing. It might sound daft but it was such a change from the usual “Joanna is being paid for being right, therefore she must be” that a lot of developers would come back with.
After the bulk of my work was done there (over 7 years) my “adversary”, the managing director and chief programmer, turned to the development team and told them to have the same questioning (even argumentative) attitude to his ideas
Please @Musashi don’t either just accept what we say, or go off on your own track without being prepared to defend your stance. I’m sure I speak for the “others” when I say we have the best of intentions to get this right for the benefit of both DxO and their users. And you get the benefit of several brains for free
