Happy new year every one!
hole year to improve things.
It’s my personal idea and execution to not use 1 DAM, which you normally would do to be safe, but more applications to let write in the XMP.
Why? well most good reason is the 1 can’t do anything i like to have and the others can do things i like but have negatives on the other side.
Best ideal world is every application reads and writes absolutely the same. (no screw ups and mismatches.)
We don’t live in an ideal world (Covid? not really ideal!)
So after my mental blowout due the fact that my metadata is screwed by a misstep or wrong transfer/writing i started to think of the ideal solution to get every user type happy.
Selectivity selector for writing in XMP and writing in the exported files properties.
Like this one:
The tool/window is already written and is used for “metadata database” editing inside DxOPL.
and we have export selectivity but rather basic, as in only groups)
If we have the copypaste selectivity and we can set this in preference:
just an extra tab button on the X
We can control the level of intrusion of DxOPL in the precious XMP data.
So everyone can adjust his writing risk if you use other applications for main DAM and still want to edit some of the fields later wile editing inside DxOPL (which would help developers to enhance and improve workability by users experience and improve flexibility of the users.)
This way we can migrate from old DAM to New DAM (dxopl) safely step by step or fine tune the interface between the main DAM like Imatch (anything else) and give some wigglespace to edit xmp inside workspace of DxOPL without the risk of ruin your keywords hierarchy or other metadata.
On the export side i like to have the same.
(for me as hobby photographer not really a key feature)
But i can assume that people who spread there image’s around that they like to have more control in what is “burnt in” the exported file.
And then last thought!
possibility to set master slave.
- master is change by typing all others take over by reading at instant)
- Slave is only changing fields AFTER approval. (and only the fields who are checkboxed as active for writing) and is mostly a following vehikel.
- This needs a DataBase which has no “only inside the program living metadata” or at least it has to be visualised by character color to know its DataBase only. (maybe all not checked boxes in writing preferences get a light grey background?)
for the more manual actions you could create a push XMP sync for the selected files.
This way we can decide ourself’s how intrusive dxopl is for our worklineup and keep everyone happy.
And DxO has less pressure on there DAM Development and can let it grow in the right way for Main-DAM without the people turn there back on the DxO-DAM out of fear they lose there lifework.
A win win situation!
regards Peter
