@uncoy thank you for your comments! The photos came from a day of granddaughter “sitting” over in Hastings while their Mum and Dad put the final touches to a piece for Channel Four News! My step counter showed over 12,000 steps that day, not bad for a 4 year old and a seven year old, and a (nearly) 75 and a 74 year old!
The granddaughters got their first funicular ride, I could lie and say that the attached photo was of that “train” but that is actually the East cliff funicular and we used the West cliff funicular, which mostly runs in a tunnel!?
Lunch and then a visit to the fairground but not on this ride!
I then left my wife child minding while I went off for all of 10 minutes to take some photos of fishing boats etc. at the Stade (at the base of the East cliff) (it made a change from plants, most of ours are fighting for their lives in the drought!) and returned to find the old trolley bus taking on passengers!
Sorry wandering off topic (again), I hope that DxO are not quite as “cynical” as you suggest, although …
I have given up testing for the time being and given that I haven’t coded since 2009, and the vast majority of my coding was in COBOL, I have now started coding again but in Python!
Initially I am developing a program to identify the situation that DxO appear to have decided to ignore with “Conflict Resolution”, i.e. where the user has updated keywords etc. in DxPL but these changes have not been written back to the image (embedded or sidecar). The current coding recognises the opposite situation and flags it with an ‘S’ icon i.e. DOP < Image metadata.
With the PL5.3.0 change in the “discovery” rule when AS(OFF) or whatever that option is now called (MS(OFF) would be a better acronym for me to use)
the PL5 DOP is now the “ruling force”, i.e. with the above option OFF then the metadata will be taken from the DOP NOT from the image but the product does not warn about (potential) synchronisation issues going that way (DOP > Image metadata) and I am not sure that there are any plans to complete the Conflict Resolution, i.e. I consider it unfinished!!?
Arguably, if no changes have been made to the image metadata externally, after the updates to the DOP (and database) were made, then the situation is no different between
- The system that has had the metadata updated in DxPL so that DOP > image metadata
and
- The system that has had the database destroyed (as some users do regularly) and the data is re-introduced, which, post PL5.3.0, will restore it to the same state as item 1 taking the metadata from the DOP mandatorily. Pre PL5.3.0 the new discovery would have taken the metadata from the image and the DOP was ignored except for Virtual Copy metadata.
but what if
- In the meantime the user has used an external product to update the metadata of some of the photos in a directory, i.e. DOP < Image (signalled by the ‘S’ icon) but potentially applied externally with or without the DOP (database) changes being applied to the image before the external change and yes I have read the many texts/forum entries on the subject of changing metadata in more than one program and understand the implications!
In some ways the new scheme restores the status quo better than the pre-PL5.3.0 release but without a complete set of flags for DOP < Image and DOP > Image it becomes difficult to work out when to ‘Write to Image’ or ‘Read from Image’ or neither, the user is supposed to remember, according to one DxO response that I received, best of luck with that!!
I repeated a test I have done previously,
- Add a keyword to a photo, the “scary” ride photo!
- Copy the photo (a jpg) and the DOP to a new directory
- Add a keyword to the image, so that there are now two keywords, the one in the DOP, never committed to the image, and the one added to the image after the original DxPL addition to the database and DOP!
- “Discover” the “new” directory in PL5.4.0
- Result - no S icon indicating any mismatch anywhere, even though the ‘Date modified’ timestamp for the image was > than the DOP.
It could be argued that the current “ambivalence” is the safest course of action and the user is left to sort out the mess and any mistakes are theirs and nothing to do with DxPL but … I would like to be able to detect any such situation and “flag” it up!?
Effectively it is a < and > situation and one set of metadata or the other, either the database/DOP or image metadata will be lost. This would not be the case for keywords if there was an ‘Append keywords’ function with the ‘Read from Image’ or ‘Write to Image’ as there is with the ‘Paste metadata’.
However, it would only be the keywords that could benefit from this, ‘Rating’, and ‘Rotation’ and the IPTC data could not benefit from this and it would be either/or!
You would need to include a feature of the current export option to help with the other metadata fields as import and export options between DxPL and the image
All the elements are in DxPL, just not joined up for this purpose but alternative software doesn’t come close (I think) so no real challenge for DxO to change the product to compete @Musashi !?