Now that PhotoLab has IPTC data, I’d very much like to use PhotoLab as one-stop finishing of headline/title, caption/description fields as well as keywords and location data.
PhotoMechanic is not yet optimised for M1 architecture (and it may still be awhile) and PhotoMechanic is more than I need for my simple titling and captioning needs. On the other hand, if DxO does not safely store metadata in sidecards (either .dop or .xmp, I’d prefer .xmp), I won’t be able to use the PhotoLab metadata features and more or less no one else who values their time and the metadata enough to enter it, should either.
Very sad. The metadata feature is surprisingly well executed. To be let down on a structural flaw like this is deeply disappointing.
The observations here from @John-M would suggest another test. I find the PL5 wrapper/fresh DB create especially provocative. In this test, I would apply corrections in PL5; quit; make the database somehow unavailable or inaccessible; and then restart PL5.
In theory then, in the absence of a DB object from which to obtain image corrections, PL5 would be forced to ingest the associated sidecar file. This has been the problem all along – PL5 not importing corrections when needed.
I really wish someone from DxO development would speak up on this. I feel like I am describing an elephant to a blind man.
My request for help to them regarding moving PL5 and my library to a new PC was finally answered. The support person was confused about the issue and asked if I was losing edits. I had linked this thread and my earlier post in it. Hopefully my reply to the support person was more clear and I will get some kind of an answer as to how DXO recommends I do the move. I still haven’t done it.
I can’t help you with this question as I don’t use keywords - or any other DAM attribute.
I only proposed copying your file structure from one PC to the other because that would be the simplest thing to do. Change of drive-letter and/or folder-names would not be a problem. The only proviso is that you keep your RAW/image files AND their related sidecar/.dop files together at all times.
The .cmd file I attached above had only a limited purpose; to delete the database (and cache).
This is the one I actually use (compiled to an executable): Invoke_PL50(ClrDB+Cache).zip (401 Bytes)
You can store and run it from anywhere - it uses a system parameter as reference to your UserName. Caution: It will delete your database and cache files.
“Forced” is not quite the correct term - but, it would do as you describe …
PL would find a sidecar/.dop file - and determine that the correction info does not exist in the database
– since the database does not exist it would create an empty one
– it would add the sidecar/.dop details to the database.
I can be very confident in asserting this - because that’s how PL works for me every time I use it.
Note, however, that I don’t use ratings, keywords or projects (so, I don’t care that none of these are stored in sidecar files).
Can we please establish some concrete facts amongst the comments that has been written in this Topic. The only reason that I looked at this topic was a conversation I had on another post with @nwboater he become concerned about going near PL5 after he has seen what has been written here in this topic!
The first fact is that I don’t work for DxO, nor am I an “apologist” for DxO (I have written enough critical posts that should be clear by now), neither do I have access to any of the code.
All my opinions and “facts” come from empirical analysis (testing) and it is always possible to get the tests wrong, to interpret the test results incorrectly or to make a final judgement that is either wrong, partly wrong/right or spot on but DxO rarely acknowledge any of that!!
In truth although DxO ask for additional evidence they don’t always acknowledge that a fault has been detected and as for details when the fix is finally available or why a new release of PL5.2.0 has appeared who knows. That may be written down somewhere but I haven’t stumbled across it yet, and there should be no need to stumble across it, it should be writ large whenever any release is made!
But neither do I like gossip which propagates half truths or even truths where the reason has not been investigated, but in a “fact” vacuum rumours start and spread with no real information to quash them.
Lastly even the introduction to one of my posts is long and the post itself is typically really LONG - sorry!
Personally I have been “destroying” PL5 databases since I started beta testing PL5 at the beginning of 2021 but would prefer to have a strategy that leaves me free to use all the features of PL5 should I so choose and that includes Projects, keywords, Ratings, Rotation, Tags (except there is a bug in Tag handling which I believe is still present in PL5.2.0) and that requires either the careful use of database and/or careful husbanding of the metadata WHICH FOR THE [M]ASTER COPY OF THE IMAGE IS NO LONGER AVAILABLE FROM ANY DOP BEYOND PL4 (Currently) (Please see the explanation below)!
But @John-M has made one point that others in this topic have hinted is not true, namely the veracity of the data in the DOP. The DOP is reliable, almost, the almost refers to the fact that there is a bug with respect to ‘The Tag’, a “DxO only” piece of metadata, that only resides in the DOP and which is currently not being read back from PL5 DOPs or at least it wasn’t the last time I tested!
Is the PL5 database particularly fragile:-
The database product used by nearly all the DAM software and much other software besides is SQLlite with ACDSee being the most notable exception which uses either DBASE or a variant thereof and that is potentially the reason it can handle huge databases where there might be “horror” stories about the others when the number of images rises!
Having made my living as a Mainframe database specialist for 36 years I can say that my “only” concern about the DxPL database is that some of the structures are a bit “light” and most of the other DAM databases are somewhat “heavier”, i.e. the structures are carrying more data, potentially because they offer more organisational features, perhaps because they have more self checking features built in!
Please see this (rather sternly worded) post which I made in response to a post made by @platypus, whose proposals for PL5 database features I agree with and with whom I have discussed enhanced file management features that should be added to PL5 (sooner rather than later), but not with the comments that @platypus made in this case PL5 Tag Field not read from .dop file - #106 by BHAYT
The Lightroom Catalog falls into this same category (and can be opened with the normal SQLlite utilities after the extension has been changed to .db) and the main thing that these other systems offer that DxPL does not offer is the ability to manage multiple databases (albeit when I started PL5 Beta testing I discovered LightRoom forums like this one full of arguments about one database or many)!?
Sadly that is not an argument for this forum because PL5 does not offer such a capability (and yes I would like DxPL to be multiple database capable).
If you want many databases then use the backup feature naming the database you are backing up appropriately and open an old backup, even one from a previous release (certainly PL5 can open a PL4 database!) Is it as elegant as Lightroom, absolutely not, is it useful, potentially but the user is responsible for the management and DxPL is not going to lend a hand (certainly not at the moment)!
An investigation of the database by one of the posts above seemed to indicate multiple copies of the same data and potentially disused copies with the possible risk of PL5 becoming confused!
I believe the following statement is correct
If data is removed via PL5 then the entries in the database will be expunged immediately but sadly that command will also remove the image from disk! There is currently no way of removing items from the database only. One of the features I (March 2021) and others (@platypus - Dec 2020) would most like to be added to DxPL to allow elements of the database to be cleared but the data to be available for re-discovery by PL5!
If data is removed from disk “behind PL5’s back” how is PL5 to determine what has actually happened (without what I want added in item 1 above to avoid the need for such deletions!). Having purchased IMatch at Christmas it does appear to be scanning directories in the background for imported directories and warning that ‘Files are offline’. It is a dedicated DAM with more features than I will …, PL5 is a very good raw editor with the possibility to be a good metadata handler, when certain features have been added etc. etc.
The advantage of the current “discovery” mechanism in PL5 is the ease of use, testing other products which need an explicit import process is tedious in the extreme.
So when a database (and they all have one) purports to represent an image of the directory structure and users start renaming files, directories or deleting them wholesale from the actual directory structure then there will be problems.
Singling PL5 out for special criticism is simply cynical and an unfair representation of the issues that all such systems “suffer” and must be built to endure!?
At least PL5 provides the DOP as a backup mechanism, providing it is used correctly and with the right expectations.
The problem does not necessarily lie with having a database or having a DOP but with the coding that supports the operations that rely on and update those storage mechanisms.
I object to statements like this (but respect the author and his right to make them):-
Sadly the above statements and others like it have been made since DxO first indicated its intention to strengthen its metadata handling and are understandable when it comes to the risk of DxO transferring resources from further developing the editor to the “frivolous” activity of developing a DAM!
But I do object to the part of the statement that makes the somewhat “elitist” suggestion that I might not be a “serious PhotoLab user” because I welcome the improved metadata handling or definitely will when it is finished and all the things I want are in it (PL5.2.0.4730 Conflict Resolution only detects externally generated conflicts)!
Before I continue I want to point out two other posts that I have made which might be useful (with all the standard disclaimers and caveats)!
Synchronizing data between system:-
Do not simply move images and DOPs between DxPL databases on multiple systems or you are likely to encounter ‘Unwanted Virtual Copies’, I developed this procedure to allow this to be accomplished without Virtual copies or using the alternative of removing the database! Synchronise PhotoLab - #26 by BHAYT
In another situation data was being moved from one system to another via an external hard drive and I tested the process and finally found that it could be made to work successfully (when the database and the data are both on the same drive) even when the drive letters on the different system were actually mapped to different drives but in spite of requesting a reason that it worked no-one from DxO has had the courteousy to contact me and actually describe why it works!! Cache file - #21 by John-M and other posts after that one.
What is the cause of the Apparent Data Loss?:-
So what about the loss of data in the DOPs, well I have written about that so many times over the last few months that I am surprised that the issue is not yet better understood.
First please note that the documentation about the changes in this release (PL5) are lamentable, i.e. essentially non-existent!
So here goes:
The PL4 DOP:-
The PL4 DOP can still be used to carry ‘Rating’, ‘Rotation’ and ‘The Tag’ successfully into PL5 and nothing should be lost in that “migration”. This also goes for DOPs from even earlier releases!
This data was stored in and read from the DOP because of the “immutability” constraint that DxO placed upon the image data. Either good, safe practice or an “excuse” for not engaging with all the standards surrounding metadata handling or a bit of both, until PL5!?
What happened in the move to PL5:-
All this changed with PL5 which now stores metadata where it arguably belongs, i.e. in the embedded xmp metadata or in the xmp sidecar data of the image and two of the pieces of “missing data” are now written to the appropriate xmp metadata along with keywords which previously only existed in the DxPL database and would have been lost if the database was destroyed, deliberately, accidentally or corrupted by a bug!
I have written an experimental procedure to recover keywords locked in a PL4 database if anyone is interested. There is currently no post and it is part of a very very very long document that I consider to be the missing PL5 FAQ but it still needs yet more work and I may abandon it anyway. If anyone wants the procedure than I can extract the relevant instructions - all normal discla, etc.etc.
But the data is also in the PL5 DOP!?:-
But the data is also in the PL5 DOP! Indeed it is and the DOP now contains the extended metadata for the [M[aster copy and any Virtual Copies which now includes keyword data as well. BUT the data for the [M]aster copy (often the only copy the user has) is effectively there for consistency with previous releases, consistency between the storage for all copies contained in the DOP (the [M]aster, VC[1] …) and it can be used again as it used to be pre-PL5 iff (if and only if) DxO relents and allows that data to be used routinely or on request (in a recovery situation)!
Currently the [M]aster copy of the metadata held in the PL5 DOP is WOM (Write Only Memory) and PL5 will NOT (currently) read that data back UNDER ANY CIRCUMSTANCES!!!
So you cannot secure the metadata just by securing the DOP!
You must :-
Write any metadata set in PL5 back to the image either as embedded xmp data (JPG, TIFF or DNG) or to the xmp sidecar file for RAW.
Secure the necessary elements along with the DOP, the image file with updated metadata for JPG, TIFF and DNG or the sidecar files and the image file in the case of RAW. If there is no metadata added in PL5 then it will not be necessary to force any metadata from PL5 to the xmp data!
It is potentially both these steps not being executed that have led to a spate of lost data and ‘Ratings’ returning to 0 etc… This isn’t some weird data loss, this as a result of the the changes DxO deliberately made to the handling of the ‘Rating’ and ‘Rotation’ fields in particular.
Sadly the implications of these changes have never been properly broadcast to the users by DxO, arguably this lack of communication is the real bug!!
So where does PL5 Expect the metadata to exist?:-
So while the metadata for the ‘Virtual Copies’ is still retrieved from the DOP, PL5 expects the metadata for the image to come from the image, i.e. embedded xmp metadata (JPG, TIFF, DNG and RAW if other software has put it there) or sidecar xmp metadata for RAW files if present, along with the IPTC and Exif data, including GPS data!!
But how can the image acquire that metadata set in PL5? :-
The answer to that one is not at all if the appropriate settings and/or operations are not made by the user, e.g. AS(ON) and/or ‘Files’/‘Metadata’/‘Write to Image’ and/or ‘Files’/‘Metadata’/‘Read from Image’ or AS(OFF) and ‘Files’/‘Metadata’/‘Write to Image’ and ‘Files’/‘Metadata’/‘Read from Image’.
If neither of these is set or executed then the metadata will not be read from or written to the image metadata and will remain in the PL5 database, with the original metadata (if any) still intact in the image file. Please note that the initial discovery will perform the equivalent of a ‘Read from Image’ to acquire the image metadata. (Except when a PL4 DOP is encountered and I will write that up in another post!)
But I have been told not to have AS(ON)!:-
By cautious users probably and that potentially includes me!
AS(ON) (Always Synchronize) makes PL5 watch for metadata changes that may occur to an image externally and update the database accordingly, storing certain elements in the DOP. But the other part of the ‘auto’ is that PL5 will also write back any metadata to the image if it changes in PL5 or PL5 decides that it is not in the format that it thinks is correct and changes it!!
The reason for the caution is what happens if PL5 gets things wrong and writes back the metadata and corrupts the image! The only reason for being cautious with PL5 and less so with other DAM software is simply age. PL5 is comparatively new and this particular release has had a way more chequered “career” thus far than previous releases
@uncoy would point to the metadata “distraction” for this “buggy” release and there might be more than an element of truth in that. Personally I would point to DxO simply not publishing the information users needed to verify their current workflow and make amendments (if any) as necessary.
The other reason is that the DAM users in particular do not want PL5 changing their carefully crafted (by their DAM) metadata and writing it back to the image. Even if the image metadata is protected, AS(OFF) and only use ‘Read from Image’ or the new ‘Conflict Resolution’ ‘S’ icon there is still the issue that PL5 will apply its “rules” to the metadata in the images exported from PL5.
But I would rather have the metadata features and suffer the issues that we have suffered than not have the features at all.
But DxO must do better with testing, listening to its users even more and use that userbase to undertake joint testing to improve the standing of DxPL with other metadata handling software and communicate more about the changes that they have made and the implications on the users workflow, which they cannot begin to judge if they haven’t consulted with their users in the first place!!
What AS(ON) does well is effectively “merge” metadata changes from the image (potentially put there by a DAM) or made by the user in PL5. It is not a real merge but PL5 flip flops between reading new data from the image and writing new data to the image whenever there is a change in PL5 or detected in the image!
What are the alternatives if AS(ON) worries me?:-
The answer to that is AS(OFF) but the user is then responsible for instructing PL5 to write to the image file or read from the image file. That is now being helped by the recent ‘Conflict Resolution’ additions by these need to go further.
What problems need resolving;
An option to stop PL5 changing the image metadata format and changing it on the way to an export:-
There needs to be a way that users can insist that PL5 leaves the metadata untouched, i.e. no potential write back and no change to the data output in the export phase.
A Compare option:-
A 'Compare ’ function is really needed because I have encountered situations where PL5 failed to detect an external metadata change! I was unable to isolate the circumstances and could not predictably reproduce the error. This mean that PL5 could miss a change made to the metadata made by the DAM. If all the DAM work is done before presenting to PL5 then there should be no issue but …
The alternative is to execute a ‘Read from Image’ on a selection of images before closing the database etc. but the 'Read from ’ is a “destructive” command, i.e. any (if there are any) changes made in PL5 will be obliterated by the data “coming in” from the image!
Add the missing ‘Conflict Resolution’ icon when changing metadata in PL5 results in a mismatch with the external image data (AS(OFF)):-
Without the missing icon and the icon to show the direction of the mismatch the product is simply incomplete!
…longish post indeed. Having managed IT projects for years, I’d say that you need a summary that fits on one slide…
Give it a try: What are the 5 most important things DxO needs to do, to bring asset management quality up to a reasonable level? Two lines max per item, no reasons to be given.
Without going into all your extensive detail - - I can confirm (with confidence from long-time dependence ONLY on sidecar/.dop files - instead of the database) that ALL correction details are held in the sidecar file associated with each RAW/Image file, and that PL correctly reads and applies all of it.
PL does NOT restore metadata (projects, keywords, ratings) from sidecars - because this information is not stored in sidecar files … but, personally, I don’t care about that because I don’t use those features.
In another post somewhere in the forums I complained that when a PL4 DOP is present then PL5 will only take the metadata from that source when it first discovers an image with a PL4 DOP!
This statement was correct with respect to the data I was testing at the time, namely ‘Rating’ and ‘Rotation’ but was actually incorrect when other metadata is factored into the equation as I finally discovered.
I have run a series of tests adjusting timestamps to see where PL5 will take the metadata from and whether timestamps have any impact.
I have done a number of tests and then decided “to get a life” but the situations tested were essentially
Image with a PL4 DOP introduced to PL5
Image with a PL4 DOP + xmp sidecar introduced to PL5
Image with a PL4 DOP + embedded xmp data introduced to PL5
Image with a PL4 DOP + xmp sidecar + embedded xmp data introduced to PL5
Image with a PL5 DOP introduced to PL5
Image with a PL5 DOP + xmp sidecar introduced to PL5
Image with a PL5 DOP + embedded xmp data introduced to PL5
Image with a PL5 DOP + xmp sidecar + embedded xmp data introduced to PL5
However, with the PL4 DOP in particular my original results changed when ‘Keyword’ and ‘GPS’ data was available in the xmp sidecar and/or the embedded xmp data.
So briefly, PL5 takes the data that used to be saved in the PL4 and earlier DOPs from the “older” DOPs but takes the keyword and GPS data from the xmp sidecar or the embedded data!
I believe in all cases that PL5 takes the sidecar in preference to the embedded data, this is common amongst most of the other DAMs etc. with the exception of Bridge I believe and I am not sure about LR, which favours the embedded data (or so it seemed in my tests!)
Timestamps appeared to be ignored by all the software I tested I believe (again needs verifying). Believe because contriving such a test is mind numbing in the extreme and a simple slip means going back to the beginning re-evaluating the apparent results and going back to the beginning again.
The main takeaway is that if you have an image with ‘Rating’ or ‘Rotation’ data that has been added after you last used PL4 and discover it in PL5 then, for these items of metadata, PL5 will (probably) take the data from the DOP but
If your database was taken over successfully from PL4 into PL5 that data will already be in the database anyway.
I need to verify what happens if there is a PL4 DOP with ‘Rating’ set to 0, i.e. does that “block” a value in the sidecar or the embedded xmp data (I suspect that it will).
Thank you John.
Do you really think I like going into such excruciating detail! My first job after graduating was teaching students the same age as me and older, first as a Research Assistant and then as a full time lecturer, they were one of the harshest audiences ever! I then left to see what computing was like in the “real world”!?
@platypus as you will know from other posts I have made my speciality was Mainframe Database design and support but involved being a Project Manager, Projects Manager, pre-sales analyst, finally ending as a Systems Architect for the last 16 years working on what was then the Orange Voice Mail system for the manufacture/supplier of the product.
I have been adding summaries to my posts recently but wrote this some days ago and finally decided to post it as is! I will create the summary you suggest in the next few days.
The truth is that PL5 is certainly not perfect, simply that it is not necessarily suffering some of the ills documented in this topic.
In truth some of its failings are also present in other products but PL5 should have sought to go beyond what they do not just try to emulate them and fall short in some areas because of the size of the task.
It has such promise but it is falling short and tests like the ones I was trying to run in the list above should be unnecessary!
It should be easy to ask the question and receive a response from DxO, not necessarily immediately (they have a job to do after all) but with some certainty that there will eventually be an answer forthcoming! The FAQ promised has never materialised!
Testing certain scenarios is truly a nightmare but when they have the code to hand!?
This is a sample of the test Directories I was setting up
PL5 Reads ‘Rotation’ & ‘Ratings’ (and the Tag) from PL4 DOP, ‘keywords’ & ‘GPS’ from xmp sidecar or xmp embedded when first discovering a “new” image.
PL5 never reads ‘Rating’ and ‘Rotation’ from PL5 DOP only from xmp sidecar or embedded xmp image metadata. The details are stored in the DOP but not read back!
Tag also not read from PL5 DOP - a bug!
PL5 not much changed from PL4 database so why should we suddenly be concerned that the database is “not fit for purpose”. Not much more fragile (possibly no more fragile) that the competition. All (except ACDSee use SQLlite as the database system of choice).
The role of the PL4 DOP for ‘Rating’ and ‘Rotation’ now taken by the image metadata so that must be written and secured and retained as part of the DOP + xmp sidecar(where appropriate) + image package for “back-up” purposes! If it is never written back to the image any PL5 entered metadata will be “lost” (i.e. in the database only).
This stance is quite rude. Bryan went to a lot of trouble to run a lot of real world tests on this data and to even more trouble to share them with us. The reason both @John-M and especially @BHAYT posts are so long is that PhotoLab’s handling of metadata is too complicated.
John seems to be right (in my experience) that image processing data does travel reliably in .dop sidecars. On the other hand, where the metadata is stored and whether it is all stored there is extremely unclear. While Bryan seeks to shed some light via his tests, his findings are far more positive than my own. My own experience with PhotoLab 5 metadata is extremely worrying. Moving images with the .dop and without the database most of it disappears.
I’d love to see someone like @Stenis who really deeply understands image metadata standards and has substantial experience managing said metadata at scale in the real world test metadata portability and cross-application compatibility rigorously.
What PhotoLab 5.x or PhotoLab 6 should do is clear:
keep image processing data in a .dop
share image metadata (IPTC, ratings) in a .xmp
Why?
Image processing data is more or less proprietary (crop could usefully be shared with PhotoMechanic but that’s another more complex topic, what would be most useful here is if PhotoLab would read the PhotoMechanic crop data if it doesn’t have its own crop data, i.e. one-way sync) hence no need to share.
On the other hand, metadata includes a number of open standards and is very usefully shared among photo applications in .xmp format.
DxO’s mad rush to a database only world is a real step backwards and erodes a substantial competitive advantage. The kind of photographers who will invest in an expensive tool¹ like DxO PhotoLab treasure image portability. It’s time for us as the people who fund PhotoLab and DxO to step up and demand that DxO maintain and improve image portability.
Mailer’s limitation is that it does not work on multidomain and it’s old enough to be finicky and obsolete.
Footnotes
1. If DxO seriously hopes to chase the Adobe Lightroom masses, the first step would be to cut prices in half. That won’t (and probably shouldn’t) happen. Even at half-price, the “I’ve heard of Adobe, it’s really pro, everyone uses Lightroom” crowd won’t come. Thirty percent new users with three times as many support tickets (complex tools in the hands of less expert users enough generate many times more support tickets than expert users, we are a software publisher as well, this is first hand field experience) will not even start to make up for a 50% decline in revenues. Plus with DxO showing a stiff finger to smart phone owners for the last five years, thinking of mass adoption of PhotoLab is risible. The lack of reliable support for my iPhone DNG sometimes makes even me regret my choice of RAW developer.
@uncoy Thank you for your response and support, I hope you have recovered from reading my post!
The points that both @platypus and @Wolfgang made are valid and the risk is that without a summary and with a long post the potential audience may simply ignore the post as “too much” and the post will then fail to get the point(s) across and to impart any potentially useful information because it will not be read.
Is that my “fault” for writing a long post or the audiences “fault” for not reading it?
The answer is neither and both!! It takes way too long to write up the test results and the conclusions (with all the buts, maybes, caveats, disclaimers etc.) than it does to execute the tests even though it might take many attempts to actually get the test data into the correct format and to actually capture the moment that things go "wrong " etc…
My conscience is clear. I can only do my best to “torture” test the software until it breaks or, preferably, does not and publish what I have “discovered” along the way!
My biggest concern is that the software is within striking distance of being a useful product for handling metadata (not a full blown DAM, but I bought one of those at Christmas - IMatch) but I am seriously afraid that those who I really want to listen (DxO) are actually not taking any notice of the concerns expressed by me and others and are not engaging with us in any meaningful way.
I really only want a product that allows me to handle my limited metadata easily and reliably and continues to allow me to make the modest “fixes” that I apply to my photos.
I had expected to see the same screen as after step 1,
but as you can see, it did not happen.
I then renamed the sidecars with the Finder and let DPL export settings again and compared the old and new .dop files with BBEdit. Apart from different creation dates, the files were identical.
Observation 1:
DPL 5.2 imports settings and metadata, but does not apply them.
I then copied the .dop sidecars from the original folder to the new folder and renamed the sidecars so that they matched the filenames again.
On manual import of the .dop sidecars, DPL changed the previews to match the original (modified) images.
Observation 2:
It needed extra effort to convince DPL to actually apply the settings stored in the sidecars.
Even under these conditions, DPL did NOT show the following
a) Star rating
b) GPS coordinates
c) IPTC fields
Thank you for your efforts, Platypus, systematically testing metadata portability. My own real world field experience supports exactly these results, although occasionally and mysteriously star ratings will change when modified in an external application, even while PhotoLab is open.
I repeated the test, but this time, I renamed the sidecars at a different time than the raw files. When I imported sidecars manually this time, the settings were applied. Nevertheless and again, Stars, GPS and IPTC were not read.
A quick question @platypus, did you also copy xmp files? Non-PL data is stored in xmp files - data like IPTC, etc that you say is not copied.
It seems to me that DxO are seperating metadata and edit data into seperate sidecar files. Metadata goes into xmp files and edit data goes into dop files. Those is what I suggested way back before EA for v5.
The test was done without any xmp sidecars. As you can see in the text file screenshot above, dop sidecars contain the IPTC, GPS and rating metadata, but they seem to get lost when DPL reads the dop files.
