I do believe what you say. (sometimes i have trouble to follow the exact context. )
Move dxopl to a neutral directory means highlight a neutral folderby clicking on it right?
You don’t move the folder itself because then it becomes “new” right?
Point 7 shows that ones keywords are read and stored in the DB of dxo they stay inside dop or xmp? So indexing ADD’s new keywords but not all.
Right or wrong?
According to this image it does right?
This is exactly why i don’t trust the sync option and certainly not as master DAM.
After a few years it’s dxo db cluttered with “old news” and hidden old keywords.
If i recall correct keywords and iptc are spread over xmp and dopfile due the write to image action?
If so dual sync isn’t possible then because in my case Bridge can’t read the dop file.
Ive too less free time to fully test a database(bridge) to database(dxo) and back for multiple times. In order to mimic months and years of use of both.
If so that things got shattered in xmp and dop (if read your comment correct) that would be my no go. what’s in the xmp Should Not Migrate To The Dopfile!
100%, that’s why dxo must be crystal clear in what inflics what.
Which action provokes what.
In retroprospect dxopl and therefore the dxo DAM will never be a leading factor. So it never will be a Master DAM for all people who uses dxopl.
Therefore ddopl’s DAM must be able to be set as Slave DAM. Aka it’s has to be able to read and write xmp data only back in xmp file. And acording the same rules as for instants adobe’s rules. And photomechanic’s rules. And name an other leading DAM provider.
It has to be “play nice” with others so to speak.
Aslong i am not sure of this i like to be able to delete the dxoDB and re-index to get a clean DB and not be lost any metadata which i should placed in the xmp.
I know for sure geodata is written in xmp.
Iptc fields arn’t the same in name because of language difference between bridge(Netherlands/dutch) and dxopl so blanc fields can be causing a surprise when filled.
@OXiDant just a quick response, there should be no spread across. DOP contains what the database contains, xmp contains what it is automatically allowed to contain as a result of AS(ON) and AS(OFF), plus what the user “forces” out to the image via the ‘Write to image’ command.
There should be no mix and match between the two, rather in an AS(ON) system they should both be showing the equivalent metadata (but you may not want DxPL keywords written to the image), in an AS(OFF) situation the same thing applies with respect the keyword format but at least you are in control of when it is written.
Sadly the ‘copy selected metadata’ and the selection settings available for export are not available for the ‘Write to Image’, i.e. we would like a ‘Write to Image - selected’ command please @Musashi.
Please don’t be offended, it’s not an attack, just an observation of how difficult it is to read the essentials in a language you don’t fully master.
In French, I can diagonal read.
In the explorer, I show only jpeg picture and hide associated files (raw, dop, xmp, json) so it is much easier to manage.
The unique identifier is the 8 char code at the beginning of the file name.
I use it to rename, copy, tag and resize pictures, generate html pages and maps for publication on the internet (escaich.com)
Useful reminder but I don’t see DxO updating keywords from xmp file…
I hope that DxO uses exiftool, the best tool for IPTC/XMP tags !
I use it in my own soft and it works pretty well.
Correction: for RGB files, keywords should be written only to the file. For RGB files, there are no XMPs. I just checked this with Adobe Bridge 2024.
And a note: Somehow, during testing, I managed to get a DOP file with my latest keyword, but with an XMP file that included a keyword I had tagged the image with a while back. Unfortunately, I don’t yet have the minimum steps required to reproduce and file a bug report.
I had a similar problem with an RGB file and its DOP—they had two different sets of keywords—but I don’t know how this happened.
A proposal:
For RAW files, with XMP synch enabled, the database, DOP and XMP keywords should always match.
For RGB files, the database, image file and the DOP file keywords should match.
When differences are detected, they should be fixed.
For interoperability, precedence should go to XMP (RAW) or image file (RGB) over DOP. If the DOP file has a later timestamp than the XMP or image file, then it could be used if the user approves.
In any clash, the database should have the least precedence, at least with XMP synch enabled.
The XMP synch setting is confusing. For RGB files, there is no XMP file, but for RGB files, the image plays the same role as the XMP file at least with respect to storing keywords and probably other metadata. How does XMP synch affect RGB files? How should it affect RGB files?
I feel close to making a feature request here, but some of you have looked at this longer than I have and might want to counter-propose.
[type] in bridge is not a keyword it’s a drawer (header) with keywords inside. so i never should see “type” visual in the jpg properties as “keyword” but it does.
that’s in my eye’s a mismatch/bug.
Thanks for this @BHAYT - is Bridge “free” again - The last time I tried it, I had to download a trial version of LR for it to work and then delete LR.
Currently use Mylio (definitely NOT a proper DAM but still quite powerful). I am still exploring digKam, and good to know others are using it - however, it does not appear to play nice with DxPL when it comes to coloured labels.
I also have Excire running, and it is analysing my 79715 images. The only downside of Excire (so far) is that it has no interest in video files from what I can tell. I’m not sure if this is a deal breaker just yet. The interface is beautiful - I have not done any DxO interface analysis yet either. I have to wait for the AI to finish evaluating all my images.
Regarding the table (WOW - some serious time must have gone into that - fast on the keyboard, I would assume as well) - it got me thinking that perhaps attempting to fix this universal metadata problem between packages is just too difficult and as you point out better to put the heat on DxO to fix.
An alternate that it appears some are doing is to build their own metadata “Ripper / Recompiler” so that DxO gets the information it needs and works as we would like it to. The problem is then back compatibility to the DAM. From here, it is “Turtles All the Way Down”!
Most of my video’s are short movie additions of photo’s.
A proper DAM for all image content should be supporting also video, gifs, all kinds of stills.
Therefore DxO’s DAM will never in that position. Which is fine by me.
That’s why there should be a bricked interfacestandard between DAM’s
Too much people uses there phone as a kind of DAM by using apps as instagram and god knows what more (yep i am old and not interested…) because of the buckload of new images every day on that device a propper DAM should be helpfull.
I am genuin interested how influencers organise there mixed content and will this be privacy proof?
One reason why I use macOS, because Finder and Spotlight continually indexes all sorts of metadata from all sorts of files without my having to think about it
Just FYI: I had a lot of trouble figuring out exactly what you wanted. I can see a lot of eyes glazing when they try to read what you wrote, which might reduce the number of votes you get. I wasn’t sure myself whether I should give your feature request a vote.
Joanna does seem like a reliable source, but I disagree with her on this.
The keywords/metadata need to be in the database for fast access.
The keywords/metadata need to be in the DOP file in case the database is ever deleted or corrupted and needs to be re-created. However, if PL were to always enable XMP synch, then the DOP file could be skipped.
The keywords/metadata need to be either in an XMP file (for RAW files) or within the image (for RGB files). This is for compatibility with the rest of the world.
All these sources need to stay synchronized, which is what I’m proposing. By synchronization, I meant that all the sources should match and that PL must recognize changes made by external tools, even while PL is running.
All metadata that is “global” (keywords, star ratings, colors, etc.) must be properly synchronized. PL should never wipe out metadata in XMP files that it doesn’t recognize–it should only alter the metadata it recognizes.
If Program X changes the star rating of an image (a change to the XMP file or the RGB image), then PL should pick up this change and update the DOP and database to match. Of course, external programs need to do the same. If you then change the star rating in PL, the external program needs to pick up the changes. If you use an external program that doesn’t follow the rules, then any problems are on you.
Right now PL doesn’t follow the rules so it’s reasonable for people to avoid using it if they have a workable alternative.
Hopefully you and your wife feel better soon.
There is in the Netherlands a bactery which causes lung / windpipe infection and a corona virus at the same time very easy to catch up too. I spent a week in bed and an other to be able to work again. So take your time.
@freixas why would you use dopfiles to store keywords and other data as iptc? In rawfiles you use xmp and rgb files you store it inside.
When the DB crashes you can re index and retrieve the data again from xmp and propperties of rgbfile so the dopfile isn’t needed. Keep in mind dopfiles arn’t readable for any other applycation so any syncronisation is only through dxopl.
About my proposal:
Key feature i need is
Read only sync
Read and write with control of writing sync.
Full automatic sync (which we have now only)
An other key feature which is connected to the three above is folder selectivity.
Hide and ignore folders who arn’t containing images for dxopl to see.
And the folders which dxopl need to be seen needs selectivity in syncronisation.
Me i would like read only or read and write with selection list before writing.
I never would like to have dxopl to be sync in full automated way aslong as an other application is used as DAM.
If you have seen how Syncback free works you understand the mirror function and the different values in that sync command.
I tried to lay out a path of control which DxODAM communicate with files and thus other possible DAM’s.
This is exact the problem.
Which DAM functionality is the right way?
If both are poking in your database/library you will get a mess.
A simple “read only auto sync” checkbox would be enough for most i think.
That way dxopl is always up to date for information wile using dxopl for editing and then it is not important how dxo pl handles the xmp and rgb imagedata inside it’s own ecosystem/database. Every screwup stays inside so no problem.
It’s too easy to state it’s the users problem if things go wrong.
Search speed. I just tried creating a Smart Collection in Adobe Bridge to find all images matching the keyword “Bird”. It’s been running for a while, and it’s only up to my 2009 folders (2005 is the first year). Without a database, the search has to be repeated every time.
Well, that’s where one needs a standard. I think you can get pretty far with:
Metadata in XMP files for RAW files. Adobe started this, most others follow this because…well Adobe sets the standard.
Metadata in RGB files.
No one shares database files. Programs with databases should keep up with metadata changes to the XMP/RGB files made by any other tools at any time. I realize this is easy to say and hard to do.
My proposal was for a method that fixes problems as they are found. A re-index that uses timestamps to resolve all problems might be the solution for resolving the problems all at once.
It’s easy and it’s true. If things go wrong, then the user has a problem. I think you meant to say that it’s not the user’s fault. I agree—if software works improperly, it’s the fault of the people who wrote the software.
On the other hand, if you know a program has a problem and decide to use it anyway knowing that it will screw up, then it’s on you.
I am using PL for metadata handling. I know it screws up. I can submit bug reports for the problems I can replicate and I (like you) can make feature requests. I hope things will get better.
At the moment, I’m working on ways to fix the database/file mismatches myself. Not ideal, but I don’t want a workflow that involves using a separate keywording/metadata tool.
I don’t do anything with any other metadata and so have not noted if there are problems elsewhere.
which will be the same reading the database so dopfile isn’t needed.
Most of what you write i agree with in some or more precentage. I see iptc/xmp/propperties data as a database on its own. (if it changes it changes on many places too when reading this changed file.)
So any program who changes this data by just turning it on ( activate it) and don’t have a "we noticed changed data should i write from DB to file? yes/no "can be causing big problems for the users personal data.
And DxOPL does this with Dopfiles and xmp/propperties if autosync is active.
i don’t know from which version you stepped in but many of us have seen the birth of dxoDAM including al the childdeceases with it. v7.2 is rather grown to puberty but not to a adult level.
That’s why many of us still uses workarounds and external DAM’s.
true
True again and i always try to motivate DXOdevelopementstaf to make things better.
I am not an expert in any way so i look at it as a plane user.
And the easiest way to cut out 50% of the trouble is make autosync simplex. only in, in my honest opinion.(edit: As checkbox option ofcaorse so full duplex is possible for those who wants it. )
This two advantages:
1 any screwup inside DxOpl’s DAM doesn’t hurt the users library (of external DAM’s) but we can report it.
2 because of the read only more people are probably using it for simple searching which can reveal those quirks and bugs.
So DxO’s DAM can take some time to grow without people turning away from it and shutdown any syncronisation besides DOPfiles
i am not negative about DxO only carefull and rather busy to repair my xmp and file propperties keyword like. ( found a lot of “problems” old and dxo new like when i was searching for hicups.) and now i am re tagging all my exported jpegs.
This cost me a few days to repair.
And then i have to check my source files too…
And when i am done that i probably re-edit all rawfiles in v7.2 which are done in Silkypix and rename the export folders xxxx v7.2 so i know that they are up to date…
i think i don’t have time for rebuilding the kitchen this year…
Firstly thank you to you both for all your valuable contributions to the forums - all very helpful.
In response to both you recent posts in this thread, and perhaps I am “late to the party”, in my quest to find the perfect DxPL compatible DAM (which doesn’t exist) I noticed a subtle distinction creeping into how various software packages are being described and realised that Excire describes “itself” as used for “Photo Management” - so clearly no intention to be a DAM.
At this stage, I am leaning towards digiKam as it seems on balance to do most of what I need for DAM albeit no automatic keywording from what I can tell. The journey continues and all part of the fun!
) because of the buckload of new images every day on that device a propper DAM should be helpfull.
