…hardly a normal user’s approach to fix DPL’s keyword shortcomings, e.g. in comparison to what Lightroom Classic can do.
Anyway, the title of the thraed says bugs and enhancements…and I think that many of the things mentioned as shortcomings or bugs could lead to separate feature requests for better visibility. Not that this will shorten the time to implementing those features…
I agree, not a normal approach. I wouldn’t expect anyone else to attempt this, but there seem to be a lot of programmers in this group so you never know…
I’d prefer to see DxO fix their bugs. If I can come up with reproducible bugs, I’ll submit them. For the moment, my focus is on seeing if I can straighten out their mess for myself.
I have no idea what Lightroom Classic can do. It’s a subscription product, so that’s where I stop looking.
Before someone suggests some other product, I’ll repeat that I’m doing the work so I can do my keyword searches directly in PL. I have no objections to other people choosing alternate workflows—if you’re happy with what you’re doing, stick with it.
Thanks for the reminder! The initial list of enhancements I placed in the OP received were not discussed much, perhaps because so many people are working around PL’s keywording. At some point, I will post them as separate feature requests.
Lightroom’s Library module can be used for the price of registering. and Bridge can be used without having to pay too. You could try these apps and fix your mess using tools that are better than PhotoLab in this respect - because they feature the necessary functionality.
Though I can understand the thrill of the challenge to fix things with PhotoLab alone, I propose you consider using alternative apps as you consider database editing, which is not really a built-in solution either.
Any alteration of the database requires a deep knowledge, not just of the table structures, but also of any triggers or stored procedures that might be present. Also, you could easily accidentally circumvent any referential integrity constraints that exist by modifying data in one table without regard to other affected tables.
I would never recommend “kludging” a database as the owner of the database design could change its structure at any point and totally invalidate anything you have written.
Then you have the problem that the macOS database is auto-generated from an object model created using Apple’s Core Data mechanism but the same doesn’t apply for Windows, therefore the structures (and especially the table and column names) are going to be different.
Then you have to bear in mind that the only way data integrity between the database and DOP files is enforced is by means of code written in Swift, Objective-C and C++ for macOS; or in C#, C and C++ for Windows. Not discounting any third party libraries that might be written in other languages.
Now, do changes get written to the DOP file first, then propagated to the database, or vice versa? There is a chance that both might apply so, depending on the operation, you might either get a missing update to the secondary destination or a duplicate, triggered by code unknown to you.
Although I don’t agree with @platypus suggestion on using Adobe tools, I do agree that you should use a “DAM” that works in the most standards complant way using either XMP sidecars or directly embedded metadata in JPEG, TIFF and other file formats.
As I have said before and others have noted, I am a strong believer in SPOD (single point of definition). As soon as you make an XMP sidecar the point of definition for your keywords, possibly via an external DAM, then that should be the only place that those keywords exist.
Unfortunately, because Windows doesn’t provide a built-in metadata indexing and searching engine, DxO were forced to use a database as a means of indexing and searching.
macOS, on the other hand, provides the Spotlight mechanism, which is continually indexing automatically, in the background, all files written to the disk. So, on macOS, my app can find any file, of any type, that contains given keywords. See the screenshot in my post here. As soon as I change a keyword in any file, the Spotlight engine notices it and modifies the index, so it is always kept up to date.
As to keywords for virtual copies, since XMP metadata is “extensible”, there is nothing to stop extra tags from being added without having to mess up the DOP files with their implicit confusion with the database.
…and herein lies the problem. Every app says it can do DAM, nevertheless, functionality and transport/metadata exchange are so-so, depending on which apps are used. Everyone can use whatever is around that can fix the issues. For some it’s Lightroom or database editing or self-made apps or whatnot.
Using Lightroom to fix issues of DPL with keywords has worked on my Macs for years, e.g. whenever DPL’s search found nonexistent files, I had Lr rewrite metadata to all files, deleted the DPL database and indexed the photo archive with DPL again. I use Lightroom because I have it and it works as my primary photo manager and editor…and provides such simple functionality that lets me update metadata of all files instead of folder by folder. Any dam app that can do this could be used to fix issues of DPL in this relatively crude way. BTW, I have given up trying to keep DPL’s database free of corpses. I use Lightroom regularly and PhotoLab if I must…and delete its database every now and then. I also set DPL to not sync dop and xmp sidecars, they are irrelevant under this SPOD approach.
As soon as DPL gets a set of useful database and metadata maintenance features including a possibility to remove images from its DB without trashing the files, external app would not be needed to fix DPL’s issues. Sadly, we do have to wait…and wait…and wait… for such functionalities.
What is so frustrating is when Adobe participated in the MWG (metadata working group) to form a standard, then promptly decided to change the way they do things to be different from that standard.
Take the Fruit | Orange | Satsuma hierarchy applied to an image using the MWG guidance…
<mwg-kw:Keywords rdf:parseType='Resource'>
<mwg-kw:Hierarchy>
<rdf:Bag>
<rdf:li rdf:parseType='Resource'>
<mwg-kw:Keyword>Fruit</mwg-kw:Keyword>
</rdf:li>
<rdf:li rdf:parseType='Resource'>
<mwg-kw:Children>
<rdf:Bag>
<rdf:li rdf:parseType='Resource'>
<mwg-kw:Keyword>Orange</mwg-kw:Keyword>
</rdf:li>
</rdf:Bag>
</mwg-kw:Children>
<mwg-kw:Keyword>Fruit</mwg-kw:Keyword>
</rdf:li>
<rdf:li rdf:parseType='Resource'>
<mwg-kw:Children>
<rdf:Bag>
<rdf:li rdf:parseType='Resource'>
<mwg-kw:Children>
<rdf:Bag>
<rdf:li rdf:parseType='Resource'>
<mwg-kw:Keyword>Satsuma</mwg-kw:Keyword>
</rdf:li>
</rdf:Bag>
</mwg-kw:Children>
<mwg-kw:Keyword>Orange</mwg-kw:Keyword>
</rdf:li>
</rdf:Bag>
</mwg-kw:Children>
<mwg-kw:Keyword>Fruit</mwg-kw:Keyword>
</rdf:li>
</rdf:Bag>
</mwg-kw:Hierarchy>
</mwg-kw:Keywords>
All three keywords clearly labelled as keywords and the hierarchical relationships fully described. Plus the requirement that all keywords are also mentioned in the dc:subject tag…
<dc:subject>
<rdf:Bag>
<rdf:li>Fruit</rdf:li>
<rdf:li>Orange</rdf:li>
<rdf:li>Satsuma</rdf:li>
</rdf:Bag>
</dc:subject>
</rdf:Description>
So, what do Adobe do?
They comply with the the dc:subject tag but then totally ignore the mwg-kw keywords and hierarchy tags, in favour of their own Lightroom based tag…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Fruit</rdf:li>
<rdf:li>Fruit|Orange</rdf:li>
<rdf:li>Fruit|Orange|Satsuma</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… which can be, and is often, interpreted in multiple ways, depending on the software writer.
Some say that standalone keywords must also be included as single level hierarchies, which means that they can be confused with the top level of another hierarchy.
Some say that there should only be one line for the entire hierarchy, but that leads to confusion. We can interpret the above tag as…
FruitFruit | OrangeFruit | Orange | Satsuma… or just a fully qualified description of Fruit | Orange | Satsuma, which, according to some software, doesn’t require the first two tags.
Now just look at what happens when we add Orange and Satsuma as standalone keywords as well as parts of a hierarchy…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Fruit</rdf:li>
<rdf:li>Fruit|Orange</rdf:li>
<rdf:li>Fruit|Orange|Satsuma</rdf:li>
<rdf:li>Orange</rdf:li>
<rdf:li>Satsuma</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
This was written by PL7, but is it valid for all other DAM tools?
If we refer to the MWG guidance, it is abundantly clear that a keyword must be defined as either just a standalone keyword or, if it is a hierarchical keyword, it must be mentioned in the dc:subject tag and then its place in a given hierarchy must also be defined in the mwg-kw hierarchical tag set.
Unfortunately, the world has moved on since the MWG hierarchy tags and we are unlikely to find any software that will understand them. So we are left with lr:hierarchicalSubject which when correctly used, appears to be fairly universally compatible.
At the other extreme, if we, inadvisedly, use the following preferences in PL…
… we end up with metadata that looks like this…
<dc:subject>
<rdf:Bag>
<rdf:li>Satsuma</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Fruit|Orange|Satsuma</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… which, with a lot of software, including macOS Finder, can never be searched for by either Fruit or Orange, since they do not appear in the dc:subject tag.
Fine. you can change the preferences to “do it right” but that will all depend on the default setting and few people truly understand the meaning of the flags.
For the curious, who want to use PL for metadata writing and to be as compatible as possible, the settings should be…
Honestly, this is getting silly. This is not my first rodeo. I know what I’m doing.
I look forward to your posts on various things, but this particular discussion is not a good use of our time. I do appreciate that you are trying to help, and continue to look forward to your posts on keyword standards in general, keyword bugs in PL, and other topics.
I appreciate that but, over the years, answering this type of question for more than just the OP helps to build a resource that others may find useful. So thank you for raising a question that allowed me to publicly publish something that had only been published in a beta forum.
I am just glad there are users who know enough to push the envelope for dxopl. By testing firmly and detailed or by having codingknowledge of there own. And point out the DxODAM’s flaws and misbehaves. Hopefully this kind of discusions and posts get the attention of dxostaff and urge them to adjust.
Me? I am just a average user. If a tool doesn’t do what i want and it has automated under the hood corrections which i can control in detail i just turn it off. Specially for things which ar time consumming for weeks if it screws up.
That’s why i would like to have a more controlled syncronisation. Prefferences which can be set to my liking.
Aka protect my metadata library for misbehaving.
Every application which uses metadata should have a read/write or read only setting. Which is know crippled in dxo because it doesn’t always sync wel when (fullduplex)sync is turned off. Indexing is crippled by bringing it to the front.
They have to adjust this.
One thing i have learned from @Joanna is single point management.
Aka 1 master and multiple slaves. Metadatamanagment isn’t a democracy it is a dictatorship kind of system.
So keep up the good work!
Enjoy fireworks this night.
You will, of course, never get every application to do any specific thing.
I was trying to picture how this would work. Let’s say I told PL to treat metadata as read-only. What would that mean?
PL goes and indexes the files it encounters (or those you tell it to index). For performance reasons, this information goes into a database. After this first index, the PL database metadata should match metadata viewed using other tools that respect the same scheme.
If you’ve asked for read-only operation, then PL should only the display the data it captured, but it should not allow you to alter it, right? You would be able to search for keywords, but not enter or rename any, for example.
But there are still problems.
Let’s say you use some other tool to alter your keywords while PL is not running. Then you start PL and perform a keyword search. PL uses it database so that it can give you quick results, but now some of the images that PL thinks contain the keyword don’t, while there are other files that do. The results of your search aren’t right and there is no fast way for PL to fix the problem.
If you ask for read-only operation, you are probably also asking PL to not support metadata searches.
As many here seem to be doing, you can restrict your use of the PL features to avoid getting erroneous results. You do all your metadata editing and searches in some other tool, and then ask that tool to open the images in PL.
I believe as long as you turn off the XMP sidecar synching, never use File > Metadata > Write to image , and always do your edits/searches elsewhere, you should have what you want today, right?
So what new thing are you asking from DxO? Do you want PL to give you the option of disabling all the DAM features that they added to their code, so that you don’t inadvertently alter metadata in PL or get invalid results from a metadata search? If so, this doesn’t seem like a request they are likely to honor.
I don’t really see any way of getting correct results unless you do all your metadata work in one place. You can’t alter metadata in one tool and search in another and expect to get any sort of consistency (at least, not unless the other tool runs some always-on indexing service so it can remain up-to-date).
That works. Because RAW file adjustments are not viewable by every tool (wouldn’t that be nice?), no one metadata-handler choice will allow you to universally view adjusted images. I can’t use PL to view my old Adobe RAW adjusted images and Adobe Bridge doesn’t show any of my PL adjustments (including virtual copies). That’s just how it goes. You pick a system and live with its limitations.
That it never writes back in xmp or jpeg propperties unles i say so.
And always say every 15min and every startup a refresh reading to update internal DB.
It can alter internal DB by default and mark it as off sync with external data.
So you can manual decide to sync. (which means it writes to external file only when you want.(if you use an external DAM then this is incidental so quite easy to manage.)
In the background a sync index by startup. Problem solved.
Visual “busy with” ikon to point out indexing running.
No not quite.
When i search a rawfile i would like a search function inside dxopl.
I won’t search for exported jpegs by the way do’s i don’t edit in dxopl.
I only don’t need iptc and xmp editing often inside dxopl because bridges system and dxopl system don’t play nice for 100%. So unles i trust dxopl as DAM i stay external.
That’s exactly how multiple users are being using a library. One master which is the input side and multiple readers for it’s data.
Slaves.
Every application should have a master or slave setting.
A equal based synchronisation on different pc’s and platforms(android) is fine but not in different applications with there own truth of standard.
@freixas No because DxO developed the software to provide its own mini DAM features, not necessarily be a slave to some other product. You are free to change the metadata as much as you like but if you write it back to the image the keyword formatting may change.
But this issue is not unique to DxPL, far from it, many packages have their own metadata capabilities built in, arguably one of the reasons that DxO added the capabilities to DxPL, if they are used and allowed to write the metadata back to the image then the same potential for keyword re-formatting will occur.
Why, when you take auto control away from DxPL you replace it with manual control, you are free to re-read from the images at any time to keep the data in DxPL up to date.
Why would DxO spend all that effort putting the functions into the software just to remove them, learn to work with the product instead of fighting against it! People are blaming DxPL for a problem that can occur with all the editing software that contains metadata capabilities.
Not the most convenient thing to have to do but so long as it is a one way pipe you should be O.K. The potential of re-arranging the keywords is a “feature” of all the programs not just DxPL.
Defining metadata in a single place reduces the risk of complications but actually I want that single place to be DxPL notwithstanding potential issues with searching, foreground indexing and the renaming issue I need to re-investigate.
My frustration is not with issues to do with interacting with other software, I am not really interested in the other software, I want DxO to finish what they started so I can use DxPL for metadata as it should be used.
This is very confusing. I was trying to find out what @OXiDant was asking for, but you’re responding as though these are things I was asking for. Most of what you’re arguing for are things I agree with you on.
It’s quite simple in it’s base definitions.
In order to have a steady metadata management you need a few things.
If we use dxo pl, XNviewnp or bridge or LR or Capture one or dedicated DAM apps as photomechanic that’s up to the user. Transfering a database to an other application is alway’s tricky. And can screwup your precious build keywords system. That transfer should be a choice not a fight between applications.
If i transfer to dxopl and use that as main search and edit application i know some things should be repaired due transfer mistakes.
My problem with dxopl’s settings is if sync is off it doesn’t read metadata again every time i start dxopl in order to be up to date.
Yes sometimes it does sometimes it don’t.
An other thing which can be tricky is:
Say i change geodata field. And manual command write to xmp.
Does it only write geodata field (change selective) or also al my keyword strings too? Blunt all data overwrite.?
The first is great. The latter is destroying my xmp build by Bridge.
See it as a book library.
You can borrow a book and bring it back without a problem for an other. You maybe have to wait for it before it’s back but it’s the same as before it was borrowed. Over and over again No text was altered. Read only.
If you rip out pages and fill new pages to stuff it in then rules of engagement should be agreed with the librarian otherwise the book gets a mess.
So it’s best as only the librarian is altering the books and keep track (logs) of the changes so the next borrower can detect a new version and read that again to see if it’s different from the first time he’s borrowed it.
Let me be clear i am not saying dxo must stop being a DAM. I am saying i should be in the controlseat of when what should be synchronised back (and thus a write command) with external files. A simple i discovered a difference in data: do you want to write from DB to xmp yes/no or from xmp to DB? Yes/no : a simple list of changes and me in control.
Is dxoPL the master?
I click on yes and remember this for next time. => dxo pl is leading.
A simple question of dxo pl before writing in xmp should be marveles.
And as i said/wrote not only dxo should have this feature , EVERY application which has capability of xmp iptc writing should have a form of controle in this matter.
@freixas Agreed I realised that but also that your questions then postulated conclusions that appeared to be not exactly correct or complete (or you were paraphrasing what @OXiDant had said).
@OXiDant Sorry you are wanting to live in “utopia” and it doesn’t exist!
The product you are using is made by Adobe and they “dictate” what the reality is with respect to image handling except they actually don’t when it comes to keywording!!
You are never going to achieve your desired goal and that is not DxPL’s fault any more than it is Capture One’s fault or Photo Mechanics fault it is an (unfortunate) fact of life!
So you will need to learn to live with reality.
During many interactions with DxO, when they existed at all (i.e. the interactions I think DxO still exist), I, amongst others, “campaigned” for an automatic read only process and a process that preserved the incoming keyword data intact so that at least the exports were spared “damage” but it never happened.
You are never transferring a database you are taking data out of one database and passing it to be put into another but I think you know that. As for the “tricky” part it simply comes down to the decision as to how to use the data elements on offer to format the keyword.
You want DxPL to adopt Bridge’s format, what about Photo Mechanic users etc. etc.
I created my “lovely” spreadsheet to discover what the differences are and proposed that DxO could actually allow users to choose the format.
With DxPL’s way of holding hierarchical keywords in the database it would have been simplicity itself to implement , which got zero response from the users and none from DxO! At least that made me start programming again!!
I apologise but please re-state what you believe is happening incorrectly in the transfer from Bridge to DxPL.
Plus please remember only keywords that show as this will be eligible for searching.
@Musashi I truly, truly …truly detest the keyword interface with drag and drop it is utter rubbish. Please provide a switch to disable it! I went to show the selection boxes for the hierarchy a|m|b and wound up with this
I either have a sticky mouse microswitch or a lazy mouse finger (comes with old age) and have moved the keywords to somewhere they don’t belong when I was actually trying to open the hierarchy. I have done this many times before and asked for the ability to disable that facility.!
The only way to get that back is either attempt to drag and drop or delete and re-add!!
So after a successful drag and drop @OXiDant we have
ONLY the item shown with a tick is available for searching. This was me setting option 1 and testing
Typically I work with option 2 selected and will get this automatically
but that also means a more comprehensive range of keywords, Option 1 keywords shown in the first group and Option 2 keywords shown in the second group
[quote=“OXiDant, post:54, topic:36569”]
My problem with dxopl’s settings is if sync is off it doesn’t read metadata again every time i start dxopl in order to be up to date.
Yes sometimes it does sometimes it don’t.
[/quote]LvE1BQ3FyPYY4ckJIQ.png)
If AS(OFF) then DxPL will (should) not re-read automatically except to raise the ‘S’ icon!
There should be no “sometimes” in this and I have no personal evidence that there is but I am specifically testing certain scenarios and you are using the product for your purposes!!??
DxPL provides controlled metadata copy and export but not transfer and I have not seen commands/controls for that in any other software I have tested. It is all or nothing.
I understand that will happen but please try to show a before and after snapshot.
If you are trying to do geodata in DxPL and return that to Bridge then you are breaking the “master” “slave” relationship, DxPL is becoming “master” of part of the metadata!
AS(OFF) puts you in the driving seat nothing is supposed to leak back into the image unless you explicitly request it. You are suggesting that AS(OFF) is actually AS(OFF maybe) but that is not the way it works, to my knowledge.
Start writing to all the manufacturers and if you think DxO are tough …
It is never going to happen, hence my ignored proposal for a table driven keyword formatter.
This was mentioned right back in the first betas. I had already designed my app with a keyword manager popup window by that time and did suggest it to DxO but, you know, not invented here, etc.
The right column contains all keywords, hierarchical or not. You create hierarchies by simply dragging a word from the right column to the left. It is impossible to create an invalid hierarchy because the drop is validated and can be refused.
The keyword entry box on the main form is predictive and shows the word being typed in all possible hierarchical combinations…
Otherwise…
keywords in the left column can be double-clicked to add them to the keyword box on the main form
keywords in the right column can be double-clicked to instigate a single word search on the main form
pressing the spacebar on a word in the right column will show the QuickView pane with thumbnails of all images that match that keyword.
there is a context menu on words in the left column…
… and for the right column…
I did propose this to DxO but it was met with the customary (non)response.
@Joanna You can lead a horse to water but you can’t stop it P ing in the pond! I have accidentally moved keywords a number of times and did it again when I needed to complete a snapshot.
It’s an interface that appeals to designers/coders but is about as much practical used as a “chocolate teapot”!
Incidentally in an earlier post you were referring to decoding the DOP why do you need anything clever for the metadata “chunk” in particular just unpack and repack as you see necessary i.e.
Sidecar = {
Date = "2024-01-01T08:28:13.3071157Z",
Software = "DxO PhotoLab 7.2",
Source = {
CafId = "C61004c",
Items = {
{
Albums = "",
CreationDate = "2023-12-29T16:50:34.6930089Z",
IPTC = {
}
,
Keywords = {
{
"a",
}
,
{
"a",
"m",
}
,
{
"a",
"m",
"b",
}
,
{
"x",
}
,
{
"y",
}
,
{
"z",
}
,
}
,
ModificationDate = "2023-12-30T10:56:02.1414381Z",
Name = "P1111351.RW2",
Orientation = 1,
OutputItems = {
}
,
ProcessingStatus = 1,
Rating = 0,
Settings = {
This is for the following keyword combination
and its not hard to work out how to decode and recode the entries, with ‘hr’ field contents first, followed by ‘dc’ field contents.
I have some examples with IPTC fields somewhere if you need them.
The editing stuff is another matter entirely!
Now I need to fix an ailing NAS drive
PS:- I changed “a” to “A” in the DOP and then did an ‘Import’ and got
a trivial example I know but …
PPS:- @OXiDant with no change to the image metadata because I am currently running “silent” i.e. AS(OFF) so the keywords are still
but if I ‘write to image’ I get
BUT I only if I write the metadata back to the image.
At first, are you feeling better? Is the flu, covid or something defeated?
Let me try to respond your post step by step.
If nobody aim for the horizon there will never be a discovery. 
I am awere of the fact that compagnies always say mine is the best so use that. Even when they have prove they don’t and. International Standards are also interpreted by most manuafactorers and not exact followed.
That’s the way it goes and customers need to deal with that.
I am not aiming for utopia i am aiming for more control in handling data by multi applications. There isn’t one provider(ecosystem) and there wil never be a lifetime user-product relationship so once in a wile your stepping over to an new product.
No i don’t, i would like that because that would solve my problems but not nessacerry. I want them to honer the fact that there are other ecosystems as wel which handle xmp , keywords in special, differently.
Easiest way to protect a carefull made library is build in some restrictions.
A question of proceding writing for instance which i could click [no] for most of the time when it sees a difference between external and DB.
The other way around i don’t care as external DAM user. (unles i start to use dxo’s DAM as main. Then i would need it the other way around for control.
I am not a programmer and writing code or reading code for that matter is not my expertise. I respons on what i see comming out of the user interface.
I love your digging and post’s because they show under the hood imperfections. But in details i am lost and frankly i don’t have the free time,(work hole week, a house to renovate, family to manage, some sporting activity’s), to learn keyword managmentcoding.
This is why i don’t use dxo’s DAM. It’s interface make me frustrated it does things i don’t want to do. Like you describe above that’s destroying a external library if you don’t be carefull . And because you can’t turn on or off which folders can be monitored and write to its difficult to use dxopl as editing program and test the same time it’s DAM user interface wile protecting your library for miswriting in a large scale.
In beta i alway’s turned off export of metadata and used the DB for testing soly. So any problems stays in dxo’s DB which i delete and restart.
In released version i delete the DB also from time to time when it’s viewing strange things. And let it reindexing to refresh. Dopfiles are it’s backup for editing status and xmp’s and filepropperties for other things so the DB is just a “copy” unless your start to fill empty fields or change fields.
So if you don’t or only in cases you control the amount of images and there metadata which wil be altered you will be more or less fine.
I think somewhere in EAv6 i tested realtime changing wile writing in bridge in iptc and changing keywords with both applications open and active and every time i hopped from and back to a folder it updated that change wile sync was off. (and write to dop as wel.) and this was every time.
I am not sure but i think somewhere in eav7 this behaviour is changed.
I think when indexing was drawn to the front activity’s. Aka you need to wait until it’s ready.
Sorry i ment transferring control of the database. Making an other program the “master”. You change user interface. There be always diferences which you have to cope with like migrating from a skoda to a ford. Many things would work the same but slightly different.
Auto door lock when you drive 10km/u the doors lock by skoda. Realy good for me because lots of stuf is for the grab in my car because of work and standing stil in a city could provoke a opening a door or back and grab something wile i am behind the wheel. My ford has the same option but not automatic. I need to close/lock manual and can’t set prefferences in autolock.
Asking Ford why? The answer was people didn’t like that auto feature so we deleted that option… That’s bonkers. If you don’t like it don’t turn it on in prefferences. Problem solved.Why delete a perfectly fine option? It’s pure software and that’s updated by wifi or sim from time to time.
Now i am driving alot with unlocked doors in city’s because i forget to manual lock when i drive in to a city.
I am now on my tablet and hope i have time to spent serveral hours on my desktop to clean up my keyword problems.
After it’s cleaned and fully updated i will make a full backup and after that i can turn on sync in dxopl and see if it’s changes things for the worse again.
(editing photo’s is stored in dopfile and if i donlt need to change much in keywords and such a screwup wil not set me back far when i have to delete active library’s xmp’s. And use backup to restore xmp’s.
DxO’s or mine?
It’s not just the metadata chunk that interests me and, if you compare the syntax structure, with other “standard” encoding/decoding mechanisms, the “punctuation” is weird, using ‘{…}’ instead of ‘[…]’ for arrays and putting commas after the last item in a list.
The effect is to make it very difficult to see if the commas are separating lists or just sections.
In the macOS programming world, there are already decoders that take a JSON or XML structure and create a dictionary in one line of code. Unfortunately, DxO don’t seem to like standards like that.
@BHAYT
see here my screenshot of my “problems” now: (on my export folder and after that i have to compare this with my raw archive too)
i have a few “drawers” which holds keywords but is itself not used as a keyword.
[overige]
[type]
[gebeurtenissen]
[vakanties en dagjesweg]
in there i have keywords flat and hieracical.
after a sync in dxo ive got this:
i have already cleaned up some of them:
by using:
i don’t know if it’s my doing or a double keywordmanagers error but it cost me day’s to restore.
i select a few until a V got a - and then deselect and select again the proper ones write back next group of images until the selection of “artis” is done.
then i search for other mismatch keywords “avond nacht images” for instance.
and so on and so on.
DxO’s user interface can’t help me with this because i afraid i do things which causes a write action i don’t want because of the well not my cup of thee interface so to speak.
edit: drawer principle: by checking “dieren” [overige] stays un checked
when i check one of the specific 's like “vogels” "dieren"got a check automaticly.
behaviour edit
uncheck wrong keyword (marked yellow) causes to uncheck right one with the same name also, so have to recheck that one again.
edit two:
when this is cleaned up on sourcefile and export file i could use advanged search to specify “vogels” more by adding sub keywords.
This kind of work i can’t in dxopl because i don’t know how and don’t want to cause new problems trying.
So i don’t open DxOPLv7.2 for now until i am done with this. then delete v7 DB.
make a back up of all xmp and files in a sub folder (should i need to zipfile this or is a sub folder enough?)
open dxOPL index the hole lot.
let update all dopfiles to v7.2 then backup those too in a subfolder
and start from there.
